frissítés: 2014-11-19: néhányan azt kérdezték tőlem, hogy mennyire segít egy index létrehozása a event(channel,id) – en. Válasz: nem sok.

az IRCBrowse megvalósítása során rájöttem, hogy a Postgres beépített eltolása nem túl gyors.

itt vannak az adataim jellemzői:

és a méret:

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

az 1. csatorna a legnagyobb:

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

ha ilyen méretű adatokkal dolgozik (nagy, de nem “nagy adat”), a PostgreSQL gyönyörűen kezeli. De a OFFSET/LIMIT sebessége nem nagy:

úgy gondolom, hogy ez az indexvizsgálat egyszerűen túl drága. Figyeljük meg, hogy én rendelési azonosító, amely egy egyedi btree index rajta. Nézze meg a sebességet:

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

azt gondolhatja, hogy kevesebb, mint egy másodperc alatt át kell szitálni az 500,000 sorokat egy 28million soros asztalról, nagyon jó, de azt hiszem, hogy szar. Ez is megtévesztő. Növeljük 1 000 000 sorra (nak, – nek 19,000,00):

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

ez egyre rosszabb! Valószínűleg lineáris a gyenge teljesítményében.

van azonban megoldás. Használjon index táblázatot. Külön táblázat, amely idegen kulcsokat tartalmaz, amelyek erre a táblázatra mutatnak:

most már rendelkezhet a csatorna lapszámozási indexével 1:

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

(idx=1000-et használtam az 1.csatornához, 2000-et a 2. csatornához stb. annak érdekében, hogy helyem legyen más numerikus indexek számára ugyanazon a csatornán.)

most nagyon hatékony lekérdezést készíthet ugyanazokra az adatokra, mint fent:

ez többé-kevésbé állandó idő.

és ezt láthatja az oldalon. Körülbelül 30 ms-ot vesz igénybe az oldal betöltése és renderelése, ha ezt a szerveren futtatom:

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

természetesen a kérés elküldése a böngésződben hosszabb időt vesz igénybe a kapcsolat költségei és eszközei miatt, de általában a cél az volt, hogy nagyon gyors legyen. A régi ircbrowse.com (egy másik személy által, aki kedvesen megadta nekem a nevet) valóban nagyon lassú volt. Látni fogja, hogy az oldal fokozatosan tölti be az adatokat az adatbázisból.

Anyhoo, úgy gondolta, hogy ez egy tisztességes, praktikus PostgreSQL-specifikus optimalizálás a lapozás tekintetében. Remélem megérte megírni.