Gondolatok az Algolia (vs Solr & Elasticsearch)
június 1, 2016 Doug Turnbull Kategória: Algolia (vs Solr & Elasticsearch): Lucene
Az Algolia egyik blogbejegyzésén való nyűgösködés, és egy Search Disco epizód Julien Lemoine CTO-val az Algolia részéről, utána lenyűgözött a megoldás.
Algolia, so hot right now!
Az Algolia feltételezi, hogy mindannyian azonnali keresést (aka search-as-you-type) akarunk majd. Ezért rendkívül jó, hosztolt azonnali keresőt építettek. Minden, amit az azonnali kereséssel akarsz csinálni, ott van. Csak olvassa el ezt a lenyűgöző bejegyzést a lekérdezések megértéséről
- Tipo tolerance, “Doug Trunbull”
- Prefix search “Doug Turn”
- Prefix with typo tolerance “Doug Trun”
- Decompounding (néha ez lehet tipo tolerance) DougTrun
- A query-time lemmatizer, and more…
Ez olyan, mintha a keresés helyett az automatikus kitöltés lenne szteroidokon. Párosítsa ezt az Elasticsearch vagy a Solr-nál józanabb alapértelmezett rangsorolással, és máris egy elég meggyőző termékkel van dolga.
Mindezt úgy mondom, mint egy eléggé fanatikus Lucenista. Írtam egy könyvet a Relevance in Lucene-ről. Nagyon elfogult vagyok a Lucene felé, mivel sok meggyőző megoldást láttam már Solr és Elasticsearch segítségével is.
Az egyik dolog, amit megtanultam a Lucene alapú keresésről, az az, hogy egy jó csapattal szinte bármilyen keresős dolgot lehet vele építeni. Mégis kell hozzá egy csapat. A Lucene-alapú keresés nem igazán arra való, hogy jól működjön “out of the box” a megoldásodhoz. Függetlenül attól, hogy az Elasticsearch mennyire megkönnyítette, a Lucene-alapú keresés egy keretrendszer, nem pedig megoldás. Ez egy sor igazán csodálatos, keresésre fókuszáló adatszerkezet, amelyet viszonylag könnyen össze lehet rakni a Your Thing™ megvalósításához. Még akkor is, ha a Your Thing™ olyan alacsony szintű részletek megváltoztatását jelenti, mint például az index lemezre való tárolása!
Egy másik módja annak, hogy ezt úgy mondjam, hogy az Elasticsearchben megépítheted az Algolia-t (vagy elég közel kerülhetsz hozzá). Nem tudsz Elasticsearch-et építeni az Algolia-ban. Az Algolia fókuszából egy konkrét problémára való összpontosítást nyersz. Feláldozod a nyílt forráskód mély testreszabhatóságát és bővíthetőségét. Még egy másik módja annak, hogy ezt úgy mondjam, hogy a keresési megoldásokat a webes alkalmazásokhoz hasonlítom. Az Algolia sok szempontból olyan, mintha egy webhelyet építenénk egy olyan webhelyépítővel, mint a Wix. A Lucene inkább olyan, mintha saját webalkalmazást építenél, fejlesztőkkel a hátad mögött, és az összes kapcsolódó alacsony szintű megfontolással, bosszúsággal, de a hatalommal is.
Az Algolia teljesítményét például az Elasticsearch-hez hasonlítjuk. Az Algolia tesztjeiben az Algolia akár 200-szoros teljesítményjavulást is állít. Átlagosan inkább 10-20x-os teljesítményjavulás van (még mindig lenyűgöző). Az Algolia azonban az Elasticsearch azonnali keresésében a legkisebb közös nevezőt választotta: a fuzzy lekérdezéseket és a prefix lekérdezéseket. Ahogy az Elasticsearchben meg van írva: The Definitive Guide egy másik gyakori megközelítés, amely óriási mértékben javítja a sebességet, az ngramok használata. Alapvetően elkerüljük a lekérdezéskori fuzzy munkát, és építünk egy óriási adatstruktúrát, amely képes kezelni azt.
Az ngramoknak azonban megvannak a maguk problémái. Növelik az indexedet. Azonban 2 millió dokumentum esetén, ahol sok rövid szöveg van, nem biztos, hogy annyira felduzzasztják az indexet. És gyanítom, hogy nagyságrendekkel javulna a teljesítmény. Ha a felduzzadt index problémává válna, akkor kevesebb, nagyobb méretű ngramot készíthetnénk. A gyorsítótárazást is figyelembe kell venni: Fogadok, hogy mindkét megoldás gyorsítótárazza az eredményeket minden egyes billentyűlekérdezéshez. Kíváncsi vagyok, hogy ez hogyan színezi az Algolia vs. ES megfontolást.
Az indexben elhelyezett kifejezéseket akár meg is fordíthatnánk, hogy a szuffix-lekérdezések a korábbi elgépeléseket elkapják. Vagy egzotikus dolgokat csinálni fuzzy lekérdezésekkel és ngramokkal egyszerre. Akár olyan Lucene-lekérdezést is írhatnánk, amely a gépelési hibákra fókuszál. Nézd meg, mennyi hatalom van itt!
A lényeg azonban az, hogy rávettem, hogy kezdj el gondolkodni azon, hogyan oldanád meg a problémát. Az Algolia már kiépített egy megoldást! Miért ne lehetne az övékkel futni? Nos, van néhány fenntartásom, ami miatt teljes mértékben az Algolia táborába mennék:
- A kulcsfordítás gyakran zártságba fordulhat. Van példa arra, hogy a hosztolt keresési megoldásokat (és adatbázisokat felvásárolták, és az új tulajdonos (A FoundationDB esetében az Apple) nem érdekelt a meglévő üzletág támogatásában.
- Téged a “dolgok, nem a húrok” érdekelnek. Az Algolia megoldása erősen koncentrál a konkrét karakterlánc-illesztésre. A Lucene relevancia-megközelítése absztraktabb módon a kifejezésekre, mint a tartalom jellemzőire összpontosít, a TF*IDF-et mint jellemző-hasonlósági rendszert használva (a könyvünk nagyrészt ilyen értelemben tárgyalja a relevanciát).
- Mindent csinálsz, ami közel sem hagyományos. Egy sajátos lekérdezési nyelvet kell implementálnod. Explicit módon le kell képezned a szakértők és a laikusok közötti nyelvezetet. Tanulást akarsz végezni a rangsoroláshoz. Ellenőrzött szókincset akarsz használni, szemantikus keresést akarsz létrehozni. Konkrét Geo-kérdések merülnek fel. Mindezeket a funkciókat beépítheti a Solr/ES-be, és az Algolia által nyújtott lehetőségekhez van kötve.
- Mélyen manipulálni akarja a keresőmotor viselkedését. Ez egy hatalmas része a Lucene édes pontjának.
De van néhány ok, amiért erősen fontolóra venném az Algolia
- Kicsi a csapatod, de fontos a jó keresés. Az Algolia elég jól működik a dobozból. Jól konfigurálható a rangsorolás, amely szöveges és numerikus értékeket, például népszerűséget is tartalmazhat, némi földrajzi támogatással.
- Neked elsősorban az egyelemű keresést kell támogatnod. Az Algolia megközelítése ideális az olyan esetekre, mint például a “banán” keresése és a banánokra való megfeleltetés. Az Algoliának nem biztos, hogy van értelme olyan felhasználók számára, akik beírják, hogy “minion fruit”, és banánt várnak.
- Szükséged van a gépelési hibák támogatására. A Lucene megoldásai erre kínosak. Remélem, hogy egyre jobbak és gyorsabbak lesznek, de a homályos keresés nem a Lucene specialitása.
Itt van néhány darab az Algolia marketingjéből, amivel nem értenék egyet:
- Az Algolia szereti hangsúlyozni, hogy az Elasticsearch hostingolása nehéz lesz. Szerintem az olyan lehetőségekkel, mint a Bonsai és az Elastic Cloud, ez aligha igaz. Egy jó ES tárhelyen alapvetően egy jó “API a felhőben” van, amivel ugyanolyan könnyű dolgozni, mint bármely más szolgáltatással.
- Az Algolia azt akarja elhitetni, hogy az Elasticsearch nem jó keresőmotor. Csak a big data analitikában és a “big data search”-ben jó (nem biztos, hogy ez mit jelent). A “things not strings” keresés szellemében nem értenék egyet. Csak munkát és megértést igényel, hogy mi a különleges a keresési megoldásodban.
- Az Algolia reméli, hogy minden azonnali keresés lesz. Mégis a tapasztalatom szerint a keresési tapasztalatok túlnyomó része (még sok Algolia által vezérelt is) először a kulcsszavak kiválasztására szolgáló automatikus kitöltés, majd a kulcsszavas keresés. Ez még mindig a Lucene édes pontján van a keresés szempontjából.
- Az Algolia által megadott benchmarkoknak hiszek, de megjegyzem, hogy az Elasticsearch-en nem próbálnak ki gyorsabb azonnali keresési stratégiákat. Mi magunk nem tudjuk újraalkotni a benchmarkjaikat. Az Algolia megbízhatónak tűnik, de bárcsak tudnám ezt függetlenül tesztelni. Azt is szeretném látni, hogy újabb Elasticsearch verziókkal szemben is újra lefuttatják őket.
Az Algolia azonban rámutat a Lucene relevancia modelljének fontos gyengeségeire
- Typoszok és fuzzy matching: Amennyiben a világ azonnali keresést akar tipustűréssel, a Lucene alapú keresést nehéz működésre bírni. Azt is elhiszem, hogy lassabb, mint az Algolia fókuszált megoldása (bár nem tudom újraalkotni a benchmarkokat).
- Elasticsearch/Solr relevancia alapértelmezett értékeit nehéz hangolni. Amint arra az Algolia helyesen rámutat, a dismax rangsoroló függvény meglehetősen zavaros eredményeket ad. Erről a jelenségről itt írunk. Ezektől az alapértelmezett értékektől el lehet és el is kell térni, de bárcsak a keresésnek több értelme lenne a dobozból.
- A relevanciára vonatkozó Elasticsearch és Solr primitívek alacsony szintűnek tűnnek. Az Algolia magasabb szintűnek tűnik, és jobban összpontosít az üzlet és a fejlesztők közötti közös megértésre. Ez az egyik fő oka annak, hogy megépítettük a Quepidet. Még így is, a Solr/ES összes lehetőségével együtt is üres tekinteteket fogsz kapni az üzletágtól, amikor bólusos lekérdezésekről, függvénylekérdezésekről és miegymásról kezdesz beszélni.
A nagy tanulságom az, hogy a megfelelő felhasználási esetekben eléggé lelkes vagyok az Algolia iránt. De biztosnak kell lenned benne, hogy kielégíti az igényeidet. Remélem, hogy ezzel tájékozottabb vásárlóvá vált.