Myšlenky o Algolii (vs Solr & Elasticsearch)
1. června 2016 Doug Turnbull Kategorie:
Algolia, so hot right now!
Algolia předpokládá, že všichni budeme chtít okamžité vyhledávání (aka search-as-you-type). Proto vytvořili extrémně dobré, hostované okamžité vyhledávání. Je tam všechno, co byste chtěli s okamžitým vyhledáváním dělat. Stačí si přečíst tento úžasný příspěvek o porozumění dotazu
- Typová tolerance, „Doug Trunbull“
- Prefixové vyhledávání „Doug Turn“
- Prefix s typo tolerancí „Doug Trun“
- Dekompozice (někdy to může být typo tolerance) DougTrun
- Lemmatizátor dotazu v čase a další…
Je to jako byste místo vyhledávání měli automatické doplňování na steroidech. Když to spojíte s rozumnějším výchozím řazením než u Elasticsearch nebo Solr, získáte docela přesvědčivý produkt.
To všechno říkám jako docela zarytý lucenista. O relevanci v Lucene jsem napsal knihu. Jsem velmi zaujatý vůči Lucene, protože jsem viděl mnoho přesvědčivých řešení postavených také pomocí Solr a Elasticsearch.
Jedna věc, kterou jsem se však o vyhledávání založeném na Lucene naučil, je, že s dobrým týmem s ním můžete postavit téměř jakoukoli vyhledávací věc. Přesto to vyžaduje tým. Vyhledávání na bázi Lucene opravdu není určeno k tomu, aby dobře fungovalo „out of the box“ pro vaše řešení. Bez ohledu na to, jak to Elasticsearch usnadnil, je vyhledávání na bázi Lucene framework, nikoliv řešení. Je to sada opravdu úžasných datových struktur zaměřených na vyhledávání, které můžete relativně snadno poskládat tak, abyste mohli dělat svou věc (Your Thing™). I kdyby to mělo znamenat změnu tak nízkoúrovňových detailů, jako je způsob ukládání indexu na disk!“
Jinak by se to dalo říct tak, že byste v Elasticsearch mohli vytvořit Algolii (nebo se jí dostatečně přiblížit). Elasticsearch v Algolii postavit nemůžete. Z Algolie získáte zaměření na konkrétní problém. Obětujete hlubokou přizpůsobitelnost a rozšiřitelnost open source. Ještě jiný způsob, jak to říci, je přirovnat vyhledávací řešení k webovým aplikacím. V mnoha ohledech je Algolia jako budování webu pomocí nástroje pro tvorbu stránek, jako je Wix. Lucene je spíše jako budování vlastní webové aplikace s vývojáři za zády a se všemi souvisejícími nízkoúrovňovými úvahami, nepříjemnostmi, ale také výkonem.
Příkladem je srovnání výkonu Algolia s Elasticsearch. V testech společnosti Algolia uvádí Algolia až 200násobné zlepšení výkonu. V průměru dochází spíše k 10-20x zlepšení výkonu (což je stále působivé). Algolia však zvolila nejmenší společný jmenovatel okamžitého vyhledávání v Elasticsearch: fuzzy dotazy a prefixové dotazy. Jak se píše v Elasticsearch: The Definitive Guide, dalším běžným přístupem, který výrazně zvyšuje rychlost, je použití ngramů. V podstatě se vyhnete práci s fuzzy dotazy a vytvoříte obří datovou strukturu, která to zvládne.
Nyní mají ngramy své vlastní problémy. Zvětšují váš index. V případě 2 milionů dokumentů se spoustou krátkých textů však nemusí index tolik nafouknout. A mám podezření, že by to mělo řádové zlepšení výkonu. Pokud by se nafouklý index stal problémem, mohli bychom vytvářet méně ngramů o větší velikosti. Je třeba také zvážit ukládání do mezipaměti: Vsadím se, že obě řešení cachují výsledky pro každý dotaz na stisknutí klávesy. Takže by mě zajímalo, jak to podbarvuje úvahy Algolia vs. ES.
Mohli bychom dokonce obrátit termíny umístěné v indexu, aby dotazy na příponu zachytily dřívější překlepy. Nebo dělat exotické věci s fuzzy dotazy a ngramy současně. Mohli bychom dokonce napsat dotaz Lucene, který se zaměří na překlepy. Podívejte se na tu sílu!“
Jde však o to, že jsem vás přiměl začít přemýšlet o tom, jak byste tento problém vyřešili. Algolia už řešení vytvořila! Proč prostě nepoběžíš s jejich řešením? No, je tu pár výhrad, které bych měl, kdybych šel celý do tábora Algolie:
- Turn-key se často může změnit v lock-in. Existují příklady, kdy byla hostovaná vyhledávací řešení (a databáze) koupena a nový vlastník (V případě FoundationDB Apple) neměl zájem o podporu stávajícího podnikání.
- Záleží vám na „věcech, ne na řetězcích“. Řešení společnosti Algolia se silně zaměřuje na porovnávání konkrétních řetězců. Přístup Lucene k relevanci se zaměřuje abstraktněji na termíny jako rysy obsahu a používá TF*IDF jako systém podobnosti rysů (naše kniha do značné míry pojednává o relevanci v těchto termínech).
- Děláte něco, co se blíží netradičnímu. Musíte implementovat specifický dotazovací jazyk. Potřebujete explicitně zmapovat slovní zásobu mezi odborníky a laiky. Chcete provádět learning-to-rank. Chcete používat řízené slovníky, vytvořit sémantické vyhledávání. Máte specifické geoinformační problémy. To všechno jsou funkce, které můžete zabudovat do Solr/ES a jste vázáni na to, co vám dává Algolia.
- Chcete hluboce manipulovat s chováním vyhledávače. To je velká část sladké stránky Lucene.
Je ale několik důvodů, proč bych rozhodně uvažoval o Algolii
- Máte malý tým, ale dobré vyhledávání je důležité. Algolia funguje docela dobře po vybalení z krabice. Má dobrou úroveň konfigurovatelnosti řazení, které může zahrnovat jak textové, tak číselné hodnoty, jako je popularita, s určitou geografickou podporou.
- Potřebujete především podporovat vyhledávání jednotlivých položek. Přístup společnosti Algolia je ideální pro případy, jako je potřeba vyhledat „banán“ a porovnat na banány. Algolia nemusí mít smysl pro uživatele, kteří zadají „minion fruit“ a očekávají banány.
- Potřebujete podporovat překlepy. Řešení Lucene je v tomto ohledu nešikovné. Doufám, že se zlepší a zrychlí, ale fuzzy vyhledávání není sladkou stránkou Lucene.
Tady je několik částí marketingu Algolia, se kterými bych nesouhlasil:
- Algolia ráda zdůrazňuje, že hostování Elasticsearch bude těžké. Myslím, že s možnostmi, jako jsou Bonsai a Elastic Cloud, tomu tak téměř není. S dobrým hostitelem ES máte v podstatě dobré „API v cloudu“, se kterým se pracuje stejně snadno jako s jakoukoli jinou službou.
- Algolia chce, abyste věřili, že Elasticsearch není dobrý vyhledávač. Je dobrý pouze na analýzu velkých dat a „vyhledávání velkých dat“ (nevím, co to znamená). V duchu hledání „věcí, které nejsou řetězci“ bych s tím nesouhlasil. Chce to jen práci a pochopení toho, čím je vaše vyhledávací řešení výjimečné.
- Algolia doufá, že se vše stane okamžitým vyhledáváním. Přesto podle mých zkušeností převážná část vyhledávacích zkušeností (dokonce i mnohé řízené Algolií) je nejprve automatické doplňování pro výběr klíčových slov a pak vyhledávání podle klíčových slov. To je stále ve sladkém místě vyhledávání Lucene.
- Věřím srovnávacím testům, které poskytuje Algolia, ale je uvedeno, že nezkouší rychlejší strategie okamžitého vyhledávání na Elasticsearch. Jejich benchmarky nemůžeme sami znovu vytvořit. Algolia se zdá být důvěryhodná, ale rád bych to mohl otestovat nezávisle. Také bych rád viděl, kdyby je znovu provedli proti novějším verzím Elasticsearch.
Algolia poukazuje na důležité nedostatky v modelu relevance Lucene
- Typy a fuzzy matching: Do té míry, že svět chce okamžité vyhledávání s tolerancí překlepů, je vyhledávání založené na Lucene těžké zprovoznit. Budu také věřit, že je pomalejší než fokusované řešení Algolia (i když nemohu znovu vytvořit benchmarky).
- Elasticsearch/Solr: Výchozí nastavení relevance se těžko ladí. Jak správně upozorňuje Algolia, funkce dismax ranking dává poměrně matoucí výsledky. O tomto jevu píšeme zde. Od těchto výchozích nastavení se můžete a měli byste oprostit, ale přál bych si, aby vyhledávání dávalo větší smysl hned po vybalení z krabice.
- Primitiva Elasticsearch a Solr pro relevanci působí nízkoúrovňově. Ty v Algolii působí na vyšší úrovni a jsou více zaměřené na vytvoření společného porozumění mezi obchodem a vývojáři. To je jeden z hlavních důvodů, proč jsme vytvořili Quepid. I přesto se při všech možnostech Solr/ES setkáte s nechápavým pohledem obchodníků, když začnete mluvit v termínech logických dotazů, funkčních dotazů a kdovíčeho ještě.
Můj hlavní poznatek je, že jsem vlastně Algolia docela nadšený pro správné případy použití. Ale musíte si být jisti, že uspokojí vaše potřeby. Doufám, že jsem z vás udělal informovanějšího zákazníka.