Fórum Root.cz
Hlavní témata => Server => Téma založeno: vesterna12 22. 12. 2021, 10:59:32
-
Pro fulltextové vyhledávání v článcích, popisu produktů, recenzích aj. na eshopu aktuálně používáme MariaDB cluster.
Nefunguje to špatně, ale mohlo by to být klidně rychlejší.
Zdá se že Elasticsearch by pro tento účel mohl být správným kandidátem.
Aktuální databáze zůstane tak jak je.
Data se budou synchronizovat mezi DB<>ES.
Funke vyhledávání pro relevantní objekty bude obsloužena pouze pomocí ES.
Dále je tu parametrické vyhledávání produktů.
V ES je rovněž možné takové vyhledávání použít, ale nevím jestli je ES pro tento účel vhodný.
Je tu někdo kdo řešil podobnou migraci a byl by ochotný sdílet zkušenosti před/po?
Měla taková migrace smysl?
Zaznamenali jste lepší odezvy svých vyhledávačů?
Duplikace dat a nutnost reindexace v určitých případech neřeším...
-
Je to drahé, špatně se to škáluje, neeee... Já mám zkušenosti s aplikací, kde to bylo podobně - Postgres + ES. Byla to noční můra a ty ES instance pak začnou hodně lézt do peněz, jak narůstají data - navíc manuální sharding, atd...
-
nepíšeš nic o velikosti eshopu, počtu vývojářů a ani návštěvnosti. Prakticky pro malá nasazení to bývá poměrně tritní, jako dodavatel se málokdy vlezeme do 1mio.
Hlavní problém pro běžné eshopy je synchronizace dat, není často jednoduchý způsob jak se napojit na "změnový feed" nebo jak nasadit CDC (change data capture), bez toho to je jen boj s tím, že máš pak v indexu neaktuální data. Filtrování se přes to dá dělat dobře, dnes třeba slevomat, rohlík nebo jiní běží komplet na elasticu.
Na elastic potřebuješ další server, je to žrava bestie, občas to spadne, občas potřebuješ změnit indexy, občas to potřebuješ otočit kvůli nastavení, takže máš výpadky nebo musíš nasadit cluster a to máš o dva problémy víc.
Jakou latency máš teď? Co vše ti na současném vyhledávání nevyhovuje? Kolik prostoru/času/peněz do zlepšení chceš investovat?
-
To mi připomnělo projekt, kde se ElasticSearch používal. Cluster stál v AWSku raketu, naplnit to daty trvalo týden (beze srandy) a navíc v té aplikaci to bylo použité na úplně nevyhovující účel, takže to vůbec ničemu nepomohlo. Nechci tě od toho odrazovat, ale je podle mě docela těžké integrovat Elastic dobře.
-
Používáme Elastic na fulltext - tam je to asi bezkonkurenční oproti MySQL.
A také hlavně na parametrické filtrování. Máme kategorie hodně postavané na parametrech a při MySQL (správně optimalizované!) se to nedalo - při cca 100k produktech trvalo vyfiltrování + vyhodnocení dostupných a zaškrtnutelných hodnot filtru až 30s.
Ale spokojený nejsem - na Stackoverflow se chlubí, jak hledají v desítkách milionech záznamů, a mě je při 100k občas některý dotaz nesmyslně pomalý, až kolem 500ms. Zatím jsem nedokázal přijít na to, proč. Paměti máme dost a shard jen 1.
-
Tak to bude asi nedostatek výkonu.
-
casto se pouziva jako nelnpohodnotna nahrada sloupcove databaze
-
V cem je lepsi elastic nez udelat si fulltext index v postgres?
-
V cem je lepsi elastic nez udelat si fulltext index v postgres?
V tom, že Elastic Search je na fulltexty specializovaný, takže má podstatně víc možností.
-
V cem je lepsi elastic nez udelat si fulltext index v postgres?
V tom, že Elastic Search je na fulltexty specializovaný, takže má podstatně víc možností.
A je potřeba podstatně více možností? Naposledy jsem slysel od kolegy, ze se mu data v Elastic indexovaly nekolik dni.
-
V tom, že Elastic Search je na fulltexty specializovaný, takže má podstatně víc možností.
To je odpověď jak od chytré horákyně. Jaké konkrétní usecase/postupy atd... se Vám podařilo vylepšit nasazením ES?
-
Taky máme mariadb cluster a ES jen na fulltext našeptávač. 150 000 produktů. Naplnění/aktualizace trvá 1 minutu. Nic lepšího jsem zatím nenašel a ani nemám potřebu hledat. Zatím bohatě stačí free verze 1 instance s 5GB ram (je v to v ramdisku).
-
Dále je tu parametrické vyhledávání produktů.
V ES je rovněž možné takové vyhledávání použít, ale nevím jestli je ES pro tento účel vhodný.
Áno, ES je pre tento účel vhodný, má na to špecializované indexy.
Je tu někdo kdo řešil podobnou migraci a byl by ochotný sdílet zkušenosti před/po?
Měla taková migrace smysl?
Zaznamenali jste lepší odezvy svých vyhledávačů?
Špecializované fulltextové vyhľadávače spravidla prinášajú nasledovné výhody:
- podpora skloňovania (stemming alebo lematizácia) - pri dátach, kde je dôležité hľadať podľa obsahu neštruktúrovaného textu (napr. články) je dôležité, aby vyhľadávač našiel aj skloňované tvary hľadaných výrazov (niektoré relačné databázy už na to majú podporu, neviem, či aj MariaDB)
- podpora zvýrazňovania nájdených slov v texte - uľahčuje používateľom posúdenie, či ponúkané výsledky vyhľadávania naozaj zodpovedajú tomu, čo chcel nájsť
- podpora generovania krátkych sumárov z textu pre potreby zobrazenia ukážky vo výsledkoch vyhľadávania, ideálne z tej časti textu, kde sa našli hľadané výrazy (a so zvýraznením nájdených výrazov)
- možnosť automaticky ponúknuť používateľom obsahovo podobné dokumenty
- vyššia rýchlosť vyhľadávania v porovnaní s fulltextovým vyhľadávaním v relačných db
V závislosti od konkrétneho usecase-u odporúčam zvážiť aj použitie fulltextového engine-u Solr - pokiaľ nepotrebujete špecializované výpočty nad dátami, tak je IMHO jednoduchší na implementáciu, pričom má rovnaké jadro ako ES.
-
Dále je tu parametrické vyhledávání produktů.
V ES je rovněž možné takové vyhledávání použít, ale nevím jestli je ES pro tento účel vhodný.
Áno, ES je pre tento účel vhodný, má na to špecializované indexy.
Je tu někdo kdo řešil podobnou migraci a byl by ochotný sdílet zkušenosti před/po?
Měla taková migrace smysl?
Zaznamenali jste lepší odezvy svých vyhledávačů?
Špecializované fulltextové vyhľadávače spravidla prinášajú nasledovné výhody:
- podpora skloňovania (stemming alebo lematizácia) - pri dátach, kde je dôležité hľadať podľa obsahu neštruktúrovaného textu (napr. články) je dôležité, aby vyhľadávač našiel aj skloňované tvary hľadaných výrazov (niektoré relačné databázy už na to majú podporu, neviem, či aj MariaDB)
- podpora zvýrazňovania nájdených slov v texte - uľahčuje používateľom posúdenie, či ponúkané výsledky vyhľadávania naozaj zodpovedajú tomu, čo chcel nájsť
- podpora generovania krátkych sumárov z textu pre potreby zobrazenia ukážky vo výsledkoch vyhľadávania, ideálne z tej časti textu, kde sa našli hľadané výrazy (a so zvýraznením nájdených výrazov)
- možnosť automaticky ponúknuť používateľom obsahovo podobné dokumenty
- vyššia rýchlosť vyhľadávania v porovnaní s fulltextovým vyhľadávaním v relačných db
V závislosti od konkrétneho usecase-u odporúčam zvážiť aj použitie fulltextového engine-u Solr - pokiaľ nepotrebujete špecializované výpočty nad dátami, tak je IMHO jednoduchší na implementáciu, pričom má rovnaké jadro ako ES.
Dost ze zde uvedeného seznamu mají dnešní fulltexty v databázích (třeba i ten z Postgresu). Co je potřeba říct, je že Elastic je inmemory databáze, a inmemory indexy z podstaty mají jinou strukturu než klasické indexy, a operace nad nimi jsou rychlejší. U vyšší zátěže - nad 1000 req. za sec to svůj význam má. U méně zatížených systémů to může být zbytečný a drahý kanón na vrabce. V GD na údržbě elasticku, který běžel jako podvozek splunku dělal jeden člověk na fulltime, aby to udržel při životě. A v případě identifikace problémů byl splunk extra užitečný.
-
Díky Všem za příspěvky.
Produktů je v databázi kolem 20 000.
Import jednoho produktu do testovacího serveru ES trvá v průměru 0.023s při dávkovém importu.
x20 000 = 460s.
1m = 23000s
+/- 10 minut na import by tak mohlo teoreticky stačit.
Milion 7 hodin cca.
Zatím jde o samostatnou instanci v testu.
Hostování je na vlastním HW co máme v "baráku".
Plánujeme pro začátek 3 servery a 3 shardy.
Rozšíření proběhne vždy o další 3 servery kvůli replikaci.
Import a aktualizace dostanou uživatele s oprávněním čtení/zápis.
Vyhledávací moduly pak pouze přístup pro čtení.
Spojení by mělo používat TLS.
Pokud jsem se dobře díval je tohle se souladem s volnou licencí.
Je tomu tak?
-
Produktů je v databázi kolem 20 000.
Z 20K položek musí libovolná sql databáze našeptávat realtime :)
Od 1mio jsem přecházel na sphinx a funguje i teď s cca 12mio (realtime našeptávač). Implementace mnohem snadnější, než elastic, (nej)lepší výkon ve fulltextu a snadná práce díky SphinxQL
-
Z 20K položek musí libovolná sql databáze našeptávat realtime :)
Jde o to, zda chcete jenom hloupě našeptávat přesně ty položky, které v databázi jsou, nebo jestli chcete řešit překlepy, psaní bez diakritiky, synonyma apod.
-
Z 20K položek musí libovolná sql databáze našeptávat realtime :)
Jde o to, zda chcete jenom hloupě našeptávat přesně ty položky, které v databázi jsou, nebo jestli chcete řešit překlepy, psaní bez diakritiky, synonyma apod.
Tohle všechno umí fulltext v pg (MySQL neznám, takže tam nevím).
-
Já bych taky šel radši do PG - problém je, že ti co tu píšou o elasticu vůbec neví, co PG všechno umí.
20k záznamů, s tím se musí dát pracovat realtime i bez indexu LOL