UPDATE: 2014-11-19: jotkut ihmiset kysyivät minulta, kuinka paljon indeksin luominen event(channel,id) auttaa. Vastaus:ei paljon.

Ircbrowsen käyttöönoton aikana huomasin, että Postgresin sisäänrakennettu offset ei ole kovin nopea.

tässä ovat tietoni ominaisuudet:

ja koko:

ircbrowse=> select count(*) from event; count---------- 28673917

kanava 1 on suurin:

ircbrowse=> select count(*) from event where channel = 1; count---------- 19340467

kun työskentelet tämän mittakaavan datan kanssa (suuri, mutta ei ”iso data”), PostgreSQL käsittelee sitä kauniisti. Mutta vauhti OFFSET / LIMIT ei ole suuri:

minusta tämä indeksiskannaus on yksinkertaisesti liian kallis. Huomaa, että olen tilaus id joka on ainutlaatuinen btree indeksi sitä. Tarkista nopeus:

ircbrowse=> select * from event where channel = 1 order by id offset 1000 limit 30;Time: 0.721 msircbrowse=> select * from event where channel = 1 order by id offset 500000 limit 30;Time: 191.926 ms

voisi ajatella, että alle sekunti seuloa 500 000 riviä 28 miljoonan rivin pöydästä on aika hyvä, mutta minusta se on syvältä. Se on myös petollista. Nostetaan se 1000000 riviä (of 19,000,00):

ircbrowse=> select * from event where channel = 1 order by id offset 1000000 limit 30;Time: 35022.464 ms

tämä vain pahenee! Se lienee Heikossa suorituskyvyssään lineaarinen.

on kuitenkin olemassa ratkaisu. Käytä indeksitaulukkoa. Erillinen taulukko, joka sisältää tähän taulukkoon viittaavia ulkomaisia avaimia:

nyt kanavalle voi saada sivutusindeksin 1:

ircbrowse=> select * from event_order_index where idx = 1000 limit 1; id | origin | idx----+--------+------ 1 | 1 | 1000

(käytin idx=1000 kanava 1, 2000 kanava 2, jne. jotta minulla olisi tilaa muille numerohakemistoille samalle kanavalle.)

Nyt voit tehdä hyvin tehokkaan kyselyn samoista tiedoista kuin yllä:

tämä on enemmän tai vähemmän vakioaika.

ja näet tämän toiminnassa sivustolla. Kestää noin 30ms ladata ja tehdä sivun, jos suoritan tämän palvelimella:

$ time curl 'http://ircbrowse.net/browse/haskell?events_page=234'real0m0.031suser0m0.000ssys 0m0.004s

tietysti pyynnön lähettäminen selaimessa kestää kauemmin yhteyden ylimenokauden ja varojen vuoksi, mutta yleensä tavoitteena oli, että se olisi hyvin reipasta. Vanha ircbrowse.com (eräs toinen henkilö, joka ystävällisesti antoi minulle nimen) oli todella hidas. Näet sivun lataamassa tietoja vähitellen tietokannasta.

Anyhoo, piti sitä asiallisena, käytännöllisenä PostgreSQL-spesifisenä optimointina sivutuksen suhteen. Toivottavasti se kannatti kirjoittaa ylös.