Forum » Programiranje » [Projekt] ThisSearchSux
[Projekt] ThisSearchSux

HotBurek ::
Dobro jutro.
Evo, nov dan, nov projekt.
Da prvo opišem situacijo. V preteklosti, ko sem delal spletne iskalnike izdelkov, sem skoraj vedno šel v "širino" z vsemi možnimi funkcijami. Search funkcijo sem prvo naredil v typesense, nakar sem ugotovil, da ne podpira cirilice (konkretno je šlo za bulgarske črke). Nato sem šel na meilisearch, kjer so se pojavile dve druge reči. Prvo, vnos v bazo je asinhronski z webhook klicom nazaj, ko je dokument vnešen. Kar mi ni vščeč. Drugo je pa performance, ki full pade s količino podatkov. Predvidevam da zato, ker je ta meilisearch bolj namenjen autocomplete funkciji, kot pa search. Do uporabe manticore search pa še nisem prišel.
Spet svoja zgodba je autocomplete. Že dosti časa imam napisan JS, zadeva na client strani dela v nulo in je rešeno. Na strežniku je pa druga reč. Re-buildat autocomplete je spet problem za cpu, pa tudi zadevo postavit do te mere, da bo vračalo bolj "relevantne" podatke, je težko. Vsaj meni.
Potem so tu slike izdelkov, ki vzamejo dosti cpu-ja za download in resize. Plus, na disku gre veliko podatkov za shranjevanje.
Potem re-buildanje sitemap xml.
Potem prevod spletne strani v... 25 jezikov.
Potem search cache rebuild.
In vse to se nabere in je potrebno potem vzdrževat.
Posledično sem se odločil, da vse te dodatne funkcije prestavim v prihodnost, ter da se v prvi vrsti posvetim samo zbiranju podatkov. In, še to, kot "podatke" sem omejil zgolj na product name in url.
Za search sem postavil full-text index, potem pa se za vnost izvede MATCH AGAINST IN NATURAL LANGUAGE MODE. Tak search vrača rezultate pač tako, kot jih. Algoritem BM25/TF-IDF ( Okapi BM25 ) ima pač take zakonitosti, kot jih ima. Ampak, taka implementacija je fuuuul preprosta (en index, en query).
Posledično search sux. In takšno je tudi ime spletnega iskalnika... Zaenkart.
Skratka, plan je prvo dodati mnogo mnogo produktov, in šele kasneje delat na slikah, product page-u, boljšem search-u, autocomplete-u, product refresh (tu pride price history not), itn.
Plan novih funkcij (stolpec special) je predstavljen na domači strani, vključno z trenutnom stanjem, kako daleč je do naslednje funkcije.
ThisSearchSux
Evo, nov dan, nov projekt.
Da prvo opišem situacijo. V preteklosti, ko sem delal spletne iskalnike izdelkov, sem skoraj vedno šel v "širino" z vsemi možnimi funkcijami. Search funkcijo sem prvo naredil v typesense, nakar sem ugotovil, da ne podpira cirilice (konkretno je šlo za bulgarske črke). Nato sem šel na meilisearch, kjer so se pojavile dve druge reči. Prvo, vnos v bazo je asinhronski z webhook klicom nazaj, ko je dokument vnešen. Kar mi ni vščeč. Drugo je pa performance, ki full pade s količino podatkov. Predvidevam da zato, ker je ta meilisearch bolj namenjen autocomplete funkciji, kot pa search. Do uporabe manticore search pa še nisem prišel.
Spet svoja zgodba je autocomplete. Že dosti časa imam napisan JS, zadeva na client strani dela v nulo in je rešeno. Na strežniku je pa druga reč. Re-buildat autocomplete je spet problem za cpu, pa tudi zadevo postavit do te mere, da bo vračalo bolj "relevantne" podatke, je težko. Vsaj meni.
Potem so tu slike izdelkov, ki vzamejo dosti cpu-ja za download in resize. Plus, na disku gre veliko podatkov za shranjevanje.
Potem re-buildanje sitemap xml.
Potem prevod spletne strani v... 25 jezikov.
Potem search cache rebuild.
In vse to se nabere in je potrebno potem vzdrževat.
Posledično sem se odločil, da vse te dodatne funkcije prestavim v prihodnost, ter da se v prvi vrsti posvetim samo zbiranju podatkov. In, še to, kot "podatke" sem omejil zgolj na product name in url.
Za search sem postavil full-text index, potem pa se za vnost izvede MATCH AGAINST IN NATURAL LANGUAGE MODE. Tak search vrača rezultate pač tako, kot jih. Algoritem BM25/TF-IDF ( Okapi BM25 ) ima pač take zakonitosti, kot jih ima. Ampak, taka implementacija je fuuuul preprosta (en index, en query).
Posledično search sux. In takšno je tudi ime spletnega iskalnika... Zaenkart.
Skratka, plan je prvo dodati mnogo mnogo produktov, in šele kasneje delat na slikah, product page-u, boljšem search-u, autocomplete-u, product refresh (tu pride price history not), itn.
Plan novih funkcij (stolpec special) je predstavljen na domači strani, vključno z trenutnom stanjem, kako daleč je do naslednje funkcije.
ThisSearchSux
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
- spremenilo: HotBurek ()
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Iskalnik produktov po spletnih trgovinahOddelek: Programiranje | 6741 (345) | HotBurek |
» | Spletni NEMARNEži (strani: 1 2 )Oddelek: Programiranje | 3895 (660) | HotBurek |
» | Kako pohitrit build-anje index za autocomplete?Oddelek: Programiranje | 1208 (740) | DamijanD |
» | [SQL] Ali je možno postavit UNIQUE index po grupah?Oddelek: Programiranje | 1739 (1140) | Spura |
» | Opera 10 prihaja (strani: 1 2 3 )Oddelek: Novice / Brskalniki | 13485 (9611) | hamax |