Cachovanie tabulky o 20 milionoch riadkov a spustanie vyhladavacich dotazov nad touto cachou
- frees
- Člen | 25
Dobry den,
v nette som naprogramoval aplikaciu, v ktorej uzivatel zada string ktory sa nasledne bude prehladavat v db tabulke, ktora ma 20 milionov riadkov(staticke data, ktore sa nebudu vobec menit). Predpokladany napor na stranku moze byt v case najvacsej spicky okolo 5000 zadanych stringov v priebehu 2 sekund. Potreboval by som teda zabezpecit, aby nedoslo k vypadkom. Uzivatel okamzite potrebuje dostat informaciu o tom, ci sa dany string v db nachadza alebo nenachadza, preto nie je mozne davkove spracovanie. Webhoster mi poradil, aby som tuto tabulku nacachoval do pameti(memcache) a prehladaval tieto nacachovane data. Mohli by ste mi prosim poradit ako na to? Ako databazovy framework vyuzivam dibi. Pouzita databaza je mysql.
- frees
- Člen | 25
Riadok obsahuje dva stlpce prvy je numericke ID, a druhy je 10 miestny string. Bude sa robit porovnanie ci sa uzivatelom zadany retazec presne zhoduje s tymto 10 miestnym stringom. Po tomto porovnani sa uz len do databaze vlozi novy riadok do dvoch tabuliek o tom ci tento string sedi alebo nie.
Co sa tyka elastic searchu, pozeral som sa na to a vyzera to zaujimavo, bohuzial aplikacia musi byt od 1. jula v produkcnej verzii a nakolko s elastic searchom doteraz nemam ziadnu skusenost a neviem ci by som nenarazil na nejake uskalia, rad by som to vyriesil pomocou php a mysql, kedze aplikacia je uz na tom cela postavena a funkcna. Inak to bude bezat na dedikovanom serveri onebitu xeon 6 core(+HT) a 64GB ram, ziadna ina aplikacia okrem tejto tam bezat nebude.
Editoval frees (13. 6. 2015 10:26)
- ales.kafka
- Člen | 34
Tady si plně vystačíš s MySQL. Není třeba řešit ElasticSearch, tam by byla akorát režie navíc. Tabulku podobných rozměrů máme normálně v produkci a není problém vykonávat stovky dotazů se stovkami tokenů pro hledání (ty mají 22 znaků) – navíc to tvoří jen <5% dotazů. U tebe bude jen vyšší režie pro tisíce dotazů, ale nic co by MySQL neměla zvládnout.
Máme tam standardní index (dalo by se navíc uvažovat nad Hash místo BTree) nad prvními 4 znaky, tedy 644 možností a ve většině případů tyhle 4 znaky dají maximálně dva kandidáty, které už si MySQL ověří na přesnou shodu. Mít jen id+string, tak ta tabulka+index nemá víc než 1GB. Ty to navíc můžeš udělat přes Innodb + primární klíč, celé to zrychlit a ušetřit pamět pro index.
Záleží na pravděpodobnosti, s jakou se jednotlivé znaky v tom stringu objevují. Pokud jsou to slova nějakého jazyka, tak si do PHP můžeš nagenerovat pole, kde dáš všechny unikátní dvouznakové prefixy. Nejprve zkusíš najít klíč v tomto poli a až poté dotaz na MySQL.
U těch 2500 zadaných stringů se mnohem víc zapotí Apache, disk a PHP než 2 dotazy na databázi. Pokud navíc výsledek chceš ukládat do MySQL, tak nemá smysl uvažovat o jiné databázi. Připojený musíš být stejně a SELECT na primární klíč je skoro zadarmo.
Jen musíš změnit výchozí nastavení MySQL, protože ta má nízké
limity pro využívání paměti. U tebe ale vystačí zvýšit
innodb_buffer_pool_size na několik GB a povolit více
připojení.
- frees
- Člen | 25
Dakujem za odpovede, Vase rady mi velmi pomohli. Este by som sa chcel spytat, ci nemate napad ako taketo zatazenie otestovat. Samozrejme mi napadlo napisat bota ktory bude postupne tieto stringy zadavat, no 2500 krat za sekundu ho bohuzial nespustim.
Editoval frees (23. 6. 2015 16:58)
