Rychlost fulltext hledání, cache

30. 3. 2015 10:19:11

Ahoj všichni,

pro projekt dělám fulltext hledání a vrtá mi hlavou, jak je schopen Bazos.cz poskytovat výsledky hledání tak rychle. I když zadám nesmyslnou frázi, tudíž musí projít všechny záznamy v DB, výsledky poskytne okamžitě. Máte názor, jakou technikou/nástrojem toho docílili?

Nabízí se možnost:

Data mají uložené v MEMORY tabulkách, tudíž vše v RAM.

30. 3. 2015 10:19:11

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102386

(22 hodnocení)

30. 3. 2015 10:24:03

memory tabulky tezko.. jestli neco, tak obsah db maji v ramdisku

30. 3. 2015 10:24:03

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102385

node

(5 hodnocení)

30. 3. 2015 10:33:13

elasticsearch, apache solr...skratka specificke riesenia. snad si naozaj nemyslis ze pouziva fulltext v myslq :D :D :D

30. 3. 2015 10:33:13

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102384

Martin

(7 hodnocení)

30. 3. 2015 11:15:57

napr. http://sphinxsearch.com/about/sphinx/ (Groupon, Craigslist, ...)

30. 3. 2015 11:15:57

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102383

azka

(2 hodnocení)

30. 3. 2015 11:58:00

Lucene or Mysql Full text search - Stack Overflow

30. 3. 2015 11:58:00

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102382

lidoop

(7 hodnocení)

30. 3. 2015 13:54:55

Zajímavé je, že bazoš byl takto rychlý hodně let zpět, než elastic a pod. byli obecně na scéně a použitelné. To mně přivádí k myšlence, že využívají primivnější mechanismus, než těžkotonážné nástroje ala solr.

30. 3. 2015 13:54:55

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102381

azka

(2 hodnocení)

2. 4. 2015 14:24:23

Jadro Lucene je tu z nejakyho ~2001 roku, takze kdo rika, ze musi mit elastic nebo vzdy musel mit. Od kdy je bazos? Podle whois je domena z 2003, tak pochybuju, ze by meli v ty dobe statisice produktu, aby to mysql neutahlo, kdyz internet mela kazda 10. rodina a bazos nikdo tehdy jeste neznal. Nasadili mysql a pote to potichu pretahli na lucene nebo XY jinou technologii. Co je tezkotonazniho na solru? Prvni seznameni trva par hodin, jednou implementujes a uz jen indexujes, za ten mega performance boost tech par hodin stoji... A kdyz maj profiky v tymu, tak ti to urcite znaj a max jim staci projit si kus dokumentace hezky o nedelni pulnoci a rano implementuji.

2. 4. 2015 14:24:23

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102380

Smazany ucet 253

(3 hodnocení)

22. 4. 2015 20:17:09

To jsi nikdy neslyšel o cachování obsahu nebo předvídání uživatelských akcí? :-)

22. 4. 2015 20:17:09

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102379

smickar

29. 4. 2015 21:19:55

Asi tomu nebudete věřit, ale je to opravdu primitivní like '%%' na myisam tabulce. 1 mil řádků to zvládá asi za 0,6 sekundy, nic až tak speciálního tam není. (kompletní aktualizace 1x za deset minut, cache může být zapnutá, ale i vypnutá, rozdíl max 10-15%) Pravda je, že o Sphinx jsem již několikrát uvažoval, ale like je o třídu jednodušší :).

29. 4. 2015 21:19:55

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102378

carlos

(19 hodnocení)

29. 4. 2015 23:03:08

Napsal lidoop;1181601
Ahoj všichni,
pro projekt dělám fulltext hledání a vrtá mi hlavou, jak je schopen Bazos.cz poskytovat výsledky hledání tak rychle. I když zadám nesmyslnou frázi, tudíž musí projít všechny záznamy v DB, výsledky poskytne okamžitě. Máte názor, jakou technikou/nástrojem toho docílili?
Nabízí se možnost:
Data mají uložené v MEMORY tabulkách, tudíž vše v RAM.

Odpovedel sis sam... Data v tuto chvili ale znamena indexy a ty je potreba mit vzdycky v RAM... Takze dokud delas dotazy nad tim co je v RAM je to realne spocitat relativne rychle. V extremu se vetsina operaci da paralelizovat, pokud to chces spocitat opravdu rychle nebo nad obrovskym mnozstvim dat. Jinak musis ubrat data anebo je predpocitat.

---------- Post added 29.4.2015 at 23:05 ----------

Napsal rapemer;1188950
To jsi nikdy neslyšel o cachování obsahu nebo předvídání uživatelských akcí? :-)

Haha, chces cachovat hledani? :) To se da predikovat prosimte jak presne?

29. 4. 2015 23:03:08

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102377

smickar

30. 4. 2015 09:16:24

Predikovat hledání se samozřejmě dá. Od čeho je našeptávač, chvíli dopředu tedy víte samotný dotaz, víte jak je četný a tedy i pravděpodobnost zasáhnutí cache.

30. 4. 2015 09:16:24

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102376

azka

(2 hodnocení)

30. 4. 2015 09:56:08

Naseptavac neni zadna predikce. Naseptavac pouze vyhleda v necem a pote zobrazi podobnost, co by se uzivateli mohlo hodit. Opet ale musi prohledat vsechno, co uzivatel hleda. A nejhorsi na tom je, ze vetsinou to funguje tak, ze s kazdym dalsim pismenkem zase prochazi tabulku. To ze ti to na chvili nacachuje vysledek na konkretni dotaz, po chvili se to zase ztrati a tak pri kazdym dotazu vyhledavaciho typu prohledavas pokazdy necachovany obsah. Pokud se tedy bavime o mysql. Nemyslim, ze to jde nejak nacachovat, kdyby to slo, neexistoval by sphinx, elastic, ani cely lucene (solr...)

30. 4. 2015 09:56:08

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102375

Martin

(7 hodnocení)

30. 4. 2015 10:06:55

To si nemyslim. Samozrejme, da sa to realizovat aj neefektivne, ale na suggestions sa vacsinou pouzivaju prefixove stromy a od nich odvodene datove struktury (trie, radix tree)...

Casova zlozitost vyhladavania v prefixovom strome je O(m), kde m je dlzka retazca. Orezat prvych n vysledkov podla vyhladavanosti v danej vetve tiez nieje problem, navyse tu uz je mozne vysledky cache-ovat.

V konecnom dosledku je to teda kazdym dalsim pismenkom rychlejsie (mnozina na zoradenie sa zmensuje).

30. 4. 2015 10:06:55

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102374

azka

(2 hodnocení)

30. 4. 2015 13:34:46

a proto aby se s tim nikdo nemusel srat, jsou na to technologie, ktere mysql v zakladu neumi, vcetne slozitejsich dotazu. mysql docela zvlada zakladni veci, ale pak pri psani slozitejsich suggestions na tom tece, sam jsem se s tim setkal, potreboval jsem o trochu lepsi suggestions list a casova slozitost se znasobila; opet ale rikam, nez to delas mismas, investovat tyden cas a osahat si jinou technologii a pak je spojit, ta casova investice vyjde lepe, protoze bude stejne dlouho a prinosnejsi, nez tweakovat mysql a upravovat scripty a pomocne se snazit neco vytvorit, co uz davno je

30. 4. 2015 13:34:46

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102373

Smazany ucet 253

(3 hodnocení)

3. 5. 2015 10:34:27

Zrovna Bazoš bude mít velmi jednoduchou databázovou strukturu ve které je jakékoli vyhledávání velmi rychlé (třeba 0.0004 s.). Je důležité mít databázový dotaz postaven dobře, prošpikovaný hodně indexy. Pak se nevyhledává v databázi samotné, ale pouze v indexech (což je extrémně výkonné). A cachování obsahu může být jak databázové (například query cache) nebo serverové (třeba APC pro PHP) nebo také proxy cache na síti. Těch systémů může být hodně a správnou kombinací dosáhnete vysokého výkonu, protože ve skutečnosti se do databáze dostane třeba jen 30% (těch unikátních) dotazů. Další věc, pokud máte kvalitní síť dedikovaných serverů, tak je výkon poněkud jinde než VPS či sdílený webhosting :-)

BTW: predikce vyhledávaní je velmi jednoduchá záležitost. Stačí si ukládat nejčastěji vyhledávané výrazy, pro které si vytvoříte query cache v mysql. Samozřejmě zní to složitě, ale ve výsledku - když víte co děláte, je to jednoduché a velmi efektivní.

Nehledejte v tom žádné složitosti. Databáze, která obsahuje odhadem tak milion aktivních záznamů (určitě vyprší platnost inzerátu a je následně přesunut do archivu) tak je vyhledávání otázkou milisekund i bez jakéhokoli cachování. Samozřejmě je nutné správně postavit indexy (a vyhledávat jen nad sloupci s indexy) a používat kvalitní železo.

3. 5. 2015 10:34:27

https://webtrh.cz/diskuse/rychlost-fulltext-hledani-cache/#reply1102372