Thoughts on Algolia (vs Solr & Elasticsearch)
June 1, 2016 Doug Turnbull Category: Lucene
Dopo essermi innervosito su un post del blog di Algolia, e aver avuto un episodio di Search Disco con Julien Lemoine CTO di Algolia, sono rimasto affascinato dalla soluzione.
Algolia, così caldo in questo momento!
Algolia presuppone che tutti noi vogliamo la ricerca istantanea (aka search-as-you-type). Così hanno costruito una ricerca istantanea estremamente buona, ospitata. Tutto ciò che vorresti fare con la ricerca istantanea è lì. Basta leggere questo fantastico post sulla comprensione delle query
- Tolleranza ai refusi, “Doug Trunbull”
- Ricerca di prefissi “Doug Turn”
- Prefisso con tolleranza ai refusi “Doug Trun”
- Decompounding (a volte questo può essere tolleranza ai refusi) DougTrun
- Un lemmatizzatore di query-time, e altro…
È come se al posto della ricerca ci fosse il completamento automatico sotto steroidi. Accoppiate questo con una classificazione di default più sana di Elasticsearch o Solr, e vi troverete con un prodotto piuttosto convincente.
Dico tutto questo come un Lucenista piuttosto accanito. Ho scritto un libro sulla rilevanza in Lucene. Sono molto prevenuto verso Lucene, dato che ho visto molte soluzioni convincenti costruite anche con Solr ed Elasticsearch.
Una cosa però che ho imparato sulla ricerca basata su Lucene è che si può, con un buon team, costruire praticamente qualsiasi cosa di ricerca con esso. Tuttavia ci vuole una squadra. La ricerca basata su Lucene non è davvero destinata a funzionare bene “out of the box” per la vostra soluzione. Indipendentemente da quanto Elasticsearch l’abbia reso facile, la ricerca basata su Lucene è un framework, non una soluzione. È un insieme di strutture di dati davvero sorprendenti focalizzate sulla ricerca che puoi mettere insieme in modo relativamente facile per fare la tua cosa. Anche se la tua cosa significa alterare dettagli di basso livello come il modo in cui l’indice viene memorizzato su disco!
Un altro modo per dirlo è che potresti costruire Algolia in Elasticsearch (o andarci abbastanza vicino). Non si può costruire Elasticsearch in Algolia. Si guadagna dal focus di Algolia su un problema specifico. Si sacrifica la profonda personalizzazione e l’estendibilità dell’open source. Un altro modo per dirlo è paragonare le soluzioni di ricerca alle applicazioni web. In molti modi Algolia è come costruire un sito con un costruttore di siti come Wix. Lucene è più come costruire la propria web app con gli sviluppatori dietro, e tutte le considerazioni di basso livello associate, i fastidi, ma anche la potenza.
Un esempio è il confronto delle prestazioni di Algolia con Elasticsearch. Nei test di Algolia, Algolia dichiara un miglioramento delle prestazioni fino a 200x. In media, c’è più un miglioramento delle prestazioni di 10-20x (ancora impressionante). Tuttavia, Algolia ha scelto il minimo comune denominatore nella ricerca istantanea in Elasticsearch: query fuzzy e query con prefisso. Come è scritto in Elasticsearch: The Definitive Guide un altro approccio comune che migliora enormemente la velocità è quello di utilizzare gli ngrammi. Fondamentalmente si evita il lavoro fuzzy della query-time e si costruisce una struttura dati gigante che può gestirlo.
Ora gli ngram hanno i loro problemi. Fanno crescere il tuo indice. Tuttavia, nel caso di 2 milioni di documenti con un sacco di testo breve, potrebbe non gonfiare l’indice così tanto. E sospetto che avrebbe miglioramenti di ordini di grandezza nelle prestazioni. Se un indice gonfio diventasse un problema, potremmo produrre meno ngrammi di dimensioni maggiori. C’è anche da considerare il caching: Scommetto che entrambe le soluzioni memorizzano nella cache i risultati per ogni interrogazione di tasti. Quindi mi chiedo come questo colori la considerazione Algolia vs ES.
Potremmo anche invertire i termini messi nell’indice per ottenere query di suffisso per catturare gli errori di battitura precedenti. O fare cose esotiche con query fuzzy e ngram contemporaneamente. Potremmo anche scrivere una query Lucene che si concentra sui refusi. Guarda quanta potenza c’è qui!
Il punto però è che ti ho fatto iniziare a pensare a come risolvere il problema. Algolia ha già costruito una soluzione! Perché non usare la loro? Beh, ci sono un paio di riserve che avrei se entrassi completamente nel campo di Algolia:
- Turn-key può spesso trasformarsi in lock-in. Ci sono esempi di soluzioni di ricerca ospitate (e database che sono stati acquisiti e il nuovo proprietario (nel caso di FoundationDB, Apple) non è interessato a sostenere il business esistente.
- Ti interessano le “cose non le stringhe”. La soluzione di Algolia si concentra fortemente sulla corrispondenza di stringhe specifiche. L’approccio di Lucene alla rilevanza si concentra più astrattamente sui termini come caratteristiche del contenuto, usando TF*IDF come sistema di somiglianza delle caratteristiche (il nostro libro discute ampiamente la rilevanza in questi termini).
- Si sta facendo qualcosa di non tradizionale. Hai un linguaggio di query specifico da implementare. Avete bisogno di mappare esplicitamente i vernacoli tra esperti e profani. Vuoi fare learning-to-rank. Volete usare vocabolari controllati, costruire una ricerca semantica. Avete specifiche preoccupazioni Geo. Tutte queste sono caratteristiche che puoi costruire in Solr/ES e sei bloccato in quello che Algolia ti dà.
- Vuoi manipolare profondamente il comportamento del motore di ricerca. Questa è una parte enorme dello sweet spot di Lucene.
Ma ci sono un paio di ragioni per cui prenderei fortemente in considerazione Algolia
- Hai un piccolo team, ma una buona ricerca è importante. Algolia funziona abbastanza bene fuori dalla scatola. Ha un buon livello di configurabilità del ranking che può includere sia valori testuali che numerici come la popolarità con un certo supporto geografico.
- Hai bisogno principalmente di supportare la ricerca di singoli elementi. L’approccio di Algolia è ideale per casi come la necessità di cercare “banana” e la corrispondenza sulle banane. Algolia potrebbe non avere senso per gli utenti che digitano “minion fruit” e si aspettano banane.
- È necessario supportare i refusi. Le soluzioni di Lucene per questo sono imbarazzanti. Spero che migliorino e siano più veloci, ma la ricerca fuzzy non è il punto forte di Lucene.
Ecco un paio di pezzi del marketing di Algolia con cui non sono d’accordo:
- Algolia ama sottolineare che ospitare Elasticsearch sarà difficile. Penso che con opzioni come Bonsai ed Elastic Cloud, questo non è affatto il caso. Con un buon host ES, si ha fondamentalmente una buona “API nel cloud” che è altrettanto facile da lavorare come qualsiasi altro servizio.
- Algolia vuole farvi credere che Elasticsearch non è un buon motore di ricerca. È buono solo per l’analisi di grandi dati e la “ricerca di grandi dati” (non so cosa significhi). Nello spirito di trovare “cose non stringhe” non sarei d’accordo. Ci vuole solo lavoro e capire cosa c’è di speciale nella tua soluzione di ricerca.
- Algolia spera che tutto diventi ricerca istantanea. Eppure, nella mia esperienza, la preponderanza delle esperienze di ricerca (anche molte guidate da Algolia) sono prima il completamento automatico per selezionare le parole chiave, e poi la ricerca per parole chiave. Questo è ancora nello sweet spot di Lucene per la ricerca.
- Credo ai benchmark che Algolia fornisce, ma si nota che non provano strategie di ricerca istantanea più veloci su Elasticsearch. Non possiamo ricreare i loro benchmark da soli. Algolia sembra affidabile, ma vorrei poterlo testare in modo indipendente. Mi piacerebbe anche vederli rieseguire contro le nuove versioni di Elasticsearch.
Ma Algolia sottolinea importanti debolezze nel modello di rilevanza di Lucene
- Typos e fuzzy matching: nella misura in cui il mondo vuole una ricerca istantanea con tolleranza ai refusi, la ricerca basata su Lucene è difficile da far funzionare. Credo anche che sia più lenta della soluzione focalizzata di Algolia (anche se non posso ricreare i benchmark).
- Le impostazioni predefinite di Elasticsearch/Solr per la rilevanza sono difficili da sintonizzare. Come sottolinea giustamente Algolia, la funzione di classificazione dismax produce risultati abbastanza confusi. Scriviamo di questo fenomeno qui. Si può e si deve rinunciare a queste impostazioni predefinite, ma vorrei che la ricerca avesse più senso fuori dalla scatola.
- Le primitive di Elasticsearch e Solr per la rilevanza sembrano di basso livello. Quelle di Algolia sembrano di livello superiore e più focalizzate sulla creazione di una comprensione comune tra il business e gli sviluppatori. Questa è una grande ragione per cui abbiamo costruito Quepid. Anche se, con tutte le opzioni di Solr/ES, otterrete ancora sguardi vuoti dal business quando inizierete a parlare in termini di query booleane, query di funzioni e quant’altro.
Il mio grande risultato è che sono abbastanza entusiasta di Algolia per i giusti casi d’uso. Ma dovete essere certi che soddisferà le vostre esigenze. Spero che questo ti abbia reso un acquirente più informato.