aktualizace: 2014-11-19: někteří lidé se mě ptali, jak moc pomáhá vytváření indexu na event(channel,id). Odpověď: nic moc.

během implementace IRCBrowse jsem zjistil, že vestavěný offset Postgres není příliš rychlý.

zde jsou vlastnosti mých údajů:

a velikost:

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

kanál 1 je největší:

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

když pracujete s daty v tomto měřítku (velké, ale ne „velké údaje“), PostgreSQL to zvládá krásně. Ale rychlost OFFSET / LIMIT není velká:

myslím, že toto skenování indexu je prostě příliš drahé. Všimněte si, že objednávám podle id, které má na sobě jedinečný index btree. Podívejte se na rychlost:

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

možná si myslíte, že méně než sekundu prosít přes 500,000 řádků tabulky 28million řádek je docela dobré, ale myslím, že to naštve. Je to také klamné. Zvýšíme ji na 1 000 000 řádků (z 19,000,00):

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

je to čím dál horší! Je to pravděpodobně lineární ve svém špatném výkonu.

Existuje však řešení. Použijte tabulku indexů. Samostatná tabulka, která obsahuje cizí klíče směřující k této tabulce:

nyní můžete mít stránkovací index pro kanál 1:

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

(použil jsem idx=1000 pro kanál 1, 2000 pro kanál 2 atd. takže bych měl prostor pro další číselné indexy pro stejný kanál.)

nyní můžete vytvořit velmi efektivní dotaz pro stejná data jako výše:

Toto je víceméně konstantní čas.

a můžete to vidět v akci na webu. Trvá asi 30ms načíst a vykreslit stránku, pokud jsem spustit na serveru:

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

odeslání požadavku ve Vašem prohlížeči bude samozřejmě trvat déle kvůli režii připojení a aktivům, ale obecně bylo cílem, aby byl velmi pohotový. Starý ircbrowse.com (jiným jedincem, který mi laskavě dal jméno) byl opravdu velmi pomalý. Viděli byste stránku, která postupně načítá data z databáze.

Anyhoo, myslel, že to byla slušná, praktická PostgreSQL specifická optimalizace týkající se stránkování. Doufám, že to stálo za to sepsat.