Gânduri despre Algolia (vs Solr & Elasticsearch)
1 iunie 2016 Doug Turnbull Categorie: Algolia (vs Solr & Elasticsearch): Lucene
După ce am devenit irascibil la o postare de pe blogul Algolia și am avut un episod Search Disco cu Julien Lemoine CTO al Algolia, am rămas fascinat de soluție.
Algolia, atât de fierbinte în acest moment!
Algolia presupune că toți vom dori o căutare instantanee (aka search-as-you-type). Așa că au construit o căutare instantanee extrem de bună, găzduită. Tot ceea ce ai vrea să faci cu căutarea instantanee este acolo. Citiți această postare uimitoare despre înțelegerea interogărilor
- Toleranță la greșeli de tipar, „Doug Trunbull”
- Cercetare de prefix „Doug Turn”
- Prefix cu toleranță la greșeli de tipar „Doug Trun”
- Decompunere (uneori aceasta poate fi toleranță la greșeli de tipar) DougTrun
- Un lematizator în timp de interogare și multe altele…
Este ca și cum, în loc de căutare, ai autocompletare pe steroizi. Cuplați acest lucru cu o clasificare implicită mai sănătoasă decât Elasticsearch sau Solr, și rămâneți cu un produs destul de convingător.
Declarăm toate astea ca un Lucenist destul de înfocat. Am scris o carte despre Relevanță în Lucene. Sunt foarte părtinitor față de Lucene, deoarece am văzut multe soluții convingătoare construite și cu Solr și Elasticsearch.
Un lucru pe care l-am învățat totuși despre căutarea bazată pe Lucene este că poți, cu o echipă bună, să construiești aproape orice lucru de căutare cu el. Cu toate acestea, este nevoie de o echipă. Căutarea bazată pe Lucene nu este cu adevărat menită să funcționeze bine „out of the box” pentru soluția dumneavoastră. Indiferent de cât de ușor a făcut-o Elasticsearch, căutarea bazată pe Lucene este un cadru, nu o soluție. Este un set de structuri de date cu adevărat uimitoare axate pe căutare, pe care le puteți asambla relativ ușor pentru a face Your Thing™. Chiar dacă Your Thing™ înseamnă modificarea unor detalii de nivel scăzut, cum ar fi modul în care indexul este stocat pe disc!
Un alt mod de a spune asta este că ați putea construi Algolia în Elasticsearch (sau să vă apropiați suficient de mult). Nu poți construi Elasticsearch în Algolia. Câștigi din Algolia concentrarea pe o problemă specifică. Sacrifici personalizarea profundă și capacitatea de extindere a sursei deschise. Încă un alt mod de a spune acest lucru este de a compara soluțiile de căutare cu aplicațiile web. În multe privințe, Algolia este ca și cum ai construi un site cu un constructor de site-uri precum Wix. Lucene se aseamănă mai mult cu construirea propriei aplicații web cu dezvoltatori în spate și cu toate considerațiile de nivel inferior asociate, neplăcerile, dar și puterea.
Cazul concret este compararea performanței Algolia cu Elasticsearch. În testele Algolia, Algolia pretinde o îmbunătățire a performanței de până la 200 de ori. În medie, există mai degrabă o îmbunătățire a performanței de 10-20x (totuși impresionantă). Cu toate acestea, Algolia a ales cel mai mic numitor comun în căutarea instantanee în Elasticsearch: interogări fuzzy și interogări cu prefix. Așa cum este scris în Elasticsearch: The Definitive Guide, o altă abordare comună care îmbunătățește enorm viteza este utilizarea ngrams. Practic, evitați munca fuzzy din timpul interogării și construiți o structură de date uriașă care se poate descurca.
Acum, ngramele au propriile lor probleme. Ele vă cresc indexul. Cu toate acestea, în cazul a 2 milioane de documente cu o mulțime de texte scurte, s-ar putea să nu umfle indexul atât de mult. Și bănuiesc că ar avea îmbunătățiri de ordine de mărime în ceea ce privește performanța. Dacă un index umflat ar deveni o problemă, am putea produce mai puține ngrame de dimensiuni mai mari. De asemenea, trebuie luată în considerare și memoria cache: Pun pariu că ambele soluții stochează rezultatele pentru fiecare interogare prin apăsarea tastelor. Așa că mă întreb cum influențează acest lucru considerația Algolia vs. ES.
Am putea chiar să inversăm termenii plasați în index pentru a obține interogări de sufix pentru a prinde greșelile de scriere anterioare. Sau să facem lucruri exotice cu interogări fuzzy și ngrame simultan. Am putea chiar să scriem o interogare Lucene care să se concentreze pe greșeli de scriere. Uitați-vă la toată puterea de aici!
Ideea este că v-am făcut să începeți să vă gândiți cum ați rezolva problema. Algolia a construit deja o soluție! De ce să nu mergeți cu a lor? Ei bine, există câteva rezerve pe care le-aș avea dacă aș merge cu totul în tabăra Algolia:
- Turn-key se poate transforma adesea în blocare. Există exemple de soluții de căutare găzduite (și baze de date) care au fost achiziționate, iar noul proprietar (în cazul FoundationDB, Apple) nu este interesat să susțină afacerea existentă.
- Vă pasă de „lucruri, nu de sfori”. Soluția Algolia se concentrează puternic pe potrivirea specifică a șirurilor de caractere. Abordarea relevanței de către Lucene se concentrează mai abstract pe termeni ca caracteristici ale conținutului, folosind TF*IDF ca sistem de similaritate a caracteristicilor (cartea noastră discută în mare parte relevanța în acești termeni).
- Vă faceți ceva apropiat de netradițional. Aveți de implementat un limbaj de interogare specific. Trebuie să mapezi în mod explicit vernacularele dintre experți și profani. Vreți să faceți learning-to-rank. Vrei să folosești vocabulare controlate, să construiești căutare semantică. Aveți preocupări specifice legate de Geo. Toate acestea sunt caracteristici pe care le puteți construi în Solr/ES și sunteți blocat în ceea ce vă oferă Algolia.
- Vreți să manipulați profund comportamentul motorului de căutare. Aceasta este o mare parte din punctul dulce al lui Lucene.
Dar există câteva motive pentru care aș lua în considerare cu tărie Algolia
- Aveți o echipă mică, dar o căutare bună este importantă. Algolia funcționează destul de bine din start. Are un nivel bun de configurabilitate a clasamentului care poate include atât text, cât și valori numerice, cum ar fi popularitatea, cu un anumit suport geo.
- Trebuie să sprijiniți în primul rând căutările cu un singur element. Abordarea Algolia este ideală pentru cazuri cum ar fi necesitatea de a căuta „banană” și de a se potrivi cu bananele. Algolia ar putea să nu aibă sens pentru utilizatorii care tastează „minion fruit” și se așteaptă la banane.
- Trebuie să suportați greșelile de scriere. Soluțiile Lucene pentru acest lucru sunt ciudate. Sper că vor deveni mai bune și mai rapide, dar căutarea fuzzy nu este punctul forte al lui Lucene.
Iată câteva elemente de marketing Algolia cu care nu sunt de acord:
- Algolia îi place să sublinieze că găzduirea Elasticsearch va fi dificilă. Cred că, cu opțiuni precum Bonsai și Elastic Cloud, acesta nu prea este cazul. Cu o gazdă bună pentru ES, aveți practic un bun „API în cloud” cu care este la fel de ușor să lucrați ca cu orice alt serviciu.
- Algolia vrea să vă facă să credeți că Elasticsearch nu este un motor de căutare bun. Este bun doar la analize de date mari și la „căutare de date mari” (nu sunt sigur ce înseamnă asta). În spiritul găsirii „lucrurilor care nu sunt șiruri”, nu aș fi de acord. Este nevoie doar de muncă și de înțelegerea a ceea ce este special la soluția de căutare.
- Algolia speră că totul va deveni căutare instantanee. Cu toate acestea, din experiența mea, preponderența experiențelor de căutare (chiar și multe conduse de Algolia) sunt mai întâi autocompletare pentru a selecta cuvintele cheie și apoi căutare prin cuvinte cheie. Acest lucru se află încă în zona dulce a lui Lucene pentru căutare.
- Cred în valorile de referință furnizate de Algolia, dar se observă că nu încearcă strategii de căutare instantanee mai rapide pe Elasticsearch. Nu putem recrea noi înșine reperele lor. Algolia pare demn de încredere, dar mi-aș dori să pot testa acest lucru în mod independent. Aș dori, de asemenea, să le văd rulate din nou pe versiuni mai noi de Elasticsearch.
Dar Algolia semnalează slăbiciuni importante în modelul de relevanță al lui Lucene
- Tipuri și potrivire fuzzy: În măsura în care lumea dorește o căutare instantanee cu toleranță la greșeli de scriere, căutarea bazată pe Lucene este greu de făcut să funcționeze. Voi crede, de asemenea, că este mai lentă decât soluția axată pe focalizare a Algolia (deși nu pot să recreez punctele de referință).
- Elasticsearch/Solr defaults for relevance are hard to tune. Așa cum Algolia subliniază pe bună dreptate, funcția de clasificare dismax produce rezultate destul de confuze. Am scris despre acest fenomen aici. Puteți și ar trebui să vă îndepărtați de aceste valori implicite, dar mi-aș dori ca căutarea să aibă mai mult sens din start.
- Primiitivele Elasticsearch și Solr pentru relevanță se simt la nivel scăzut. Cele de la Algolia se simt la un nivel mai înalt și se concentrează mai mult pe crearea unei înțelegeri comune între business și dezvoltatori. Acesta este un motiv important pentru care am construit Quepid. Chiar și așa, cu toate opțiunile din Solr/ES, tot veți primi priviri goale din partea oamenilor de afaceri atunci când începeți să vorbiți în termeni de interogări booleene, interogări de funcții și altele.
Cu toate acestea, sunt de fapt destul de entuziasmat de Algolia pentru cazurile de utilizare corecte. Dar trebuie să fiți siguri că vă va satisface nevoile. Sper că acest lucru v-a făcut un cumpărător mai informat.