Dachten over Algolia (vs Solr & Elasticsearch)
1 juni 2016 Doug Turnbull Category: Lucene
Na chagrijnig te zijn geworden op één Algolia blogpost, en een Search Disco aflevering te hebben met Julien Lemoine CTO van Algolia, ben ik gefascineerd achtergelaten door de oplossing.
Algolia, so hot right now!
Algolia veronderstelt dat we allemaal instant search (aka search-as-you-type) gaan willen. Dus hebben ze een extreem goede, gehoste instant zoekmachine gebouwd. Alles wat je zou willen doen met direct zoeken is er. Lees deze geweldige post over query understanding
- Typo tolerance, “Doug Trunbull”
- Prefix search “Doug Turn”
- Prefix met typo tolerance “Doug Trun”
- Decompounding (soms kan dit typo tolerance zijn) DougTrun
- Een query-time lemmatizer, en meer…
Het is alsof je in plaats van zoeken, autocomplete op steroïden hebt. Koppel dit aan een gezondere standaard ranking dan Elasticsearch of Solr, en je hebt een behoorlijk overtuigend product.
Ik zeg dit alles als een vrij rabiate Lucenist. Ik schreef een boek over Relevantie in Lucene. Ik ben erg bevooroordeeld ten opzichte van Lucene, omdat ik ook veel overtuigende oplossingen heb gezien die zijn gebouwd met Solr en Elasticsearch.
Een ding dat ik echter heb geleerd over Lucene-gebaseerd zoeken is dat je er, met een goed team, zo ongeveer elk zoekachtig ding mee kunt bouwen. Maar je hebt er wel een team voor nodig. Zoeken op basis van Lucene is niet echt bedoeld om goed “out of the box” te werken voor je oplossing. Ongeacht hoe gemakkelijk Elasticsearch het heeft gemaakt, Lucene-gebaseerd zoeken is een framework, geen oplossing. Het is een set van werkelijk verbazingwekkende zoek-gerichte datastructuren die je relatief eenvoudig in elkaar kunt knutselen om jouw ding™ te doen. Zelfs als Your Thing™ betekent dat je details op een zo laag niveau moet veranderen als hoe de index op schijf wordt opgeslagen!
Een andere manier om dat te zeggen is dat je Algolia in Elasticsearch zou kunnen bouwen (of er dicht genoeg bij in de buurt komt). Je kunt Elasticsearch niet in Algolia bouwen. Je wint met Algolia aan focus op een specifiek probleem. U offert de diepe aanpasbaarheid en uitbreidbaarheid van open source op. Nog een andere manier om het te zeggen is door zoekoplossingen te vergelijken met webapps. In veel opzichten is Algolia als het bouwen van een site met een site builder zoals Wix. Lucene is meer als het bouwen van je eigen web app met ontwikkelaars erachter, en alle bijbehorende low-level overwegingen, ergernissen, maar ook kracht.
Voorbeeld is de prestatievergelijking van Algolia met Elasticsearch. In Algolia’s tests claimt Algolia tot 200x prestatieverbetering. Gemiddeld is er meer van een 10-20x prestatieverbetering (nog steeds indrukwekkend). Algolia heeft echter gekozen voor de kleinste gemene deler in instant search in Elasticsearch: fuzzy queries en prefix queries. Zoals geschreven staat in Elasticsearch: The Definitive Guide een andere veelgebruikte aanpak die de snelheid enorm verbetert is het gebruik van ngrammen. In principe vermijd je het query-time fuzzy werk en bouw je een gigantische datastructuur die het aankan.
Nou ngrams hebben hun eigen problemen. Ze laten je index groeien. Maar in het geval van 2 miljoen documenten met veel korte tekst, zou het de index niet zo veel doen toenemen. En ik vermoed dat het de prestaties met ordes van grootte zou verbeteren. Als een opgeblazen index een probleem zou worden, zouden we minder ngrammen van grotere omvang kunnen produceren. Er is ook caching om te overwegen: Ik wed dat beide oplossingen resultaten cachen voor elke toets query. Dus ik vraag me af hoe dat de Algolia vs ES afweging kleurt.
We zouden zelfs termen die in de index staan kunnen omkeren om suffix queries te krijgen om eerdere typefouten op te sporen. Of exotische dingen doen met fuzzy queries en ngrammen tegelijk. We zouden zelfs een Lucene query kunnen schrijven die zich richt op typefouten. Kijk eens naar al die kracht hier!
Het punt is echter dat ik je aan het denken heb gezet over hoe je het probleem zou oplossen. Algolia heeft al een oplossing! Waarom niet gewoon die van hen gebruiken? Er zijn een paar bedenkingen die ik zou hebben als ik helemaal in het Algolia-kamp zou gaan:
- Turn-key kan vaak omslaan in lock-in. Er zijn voorbeelden van gehoste zoekoplossingen (en databases die worden overgenomen en waarbij de nieuwe eigenaar (in FoundationDB’s geval Apple) niet geïnteresseerd is in het ondersteunen van de bestaande business.
- Je geeft om “things not strings”. Algolia’s oplossing richt zich sterk op specifieke string matching. Lucene’s benadering van relevantie richt zich abstracter op termen als kenmerken van inhoud, met behulp van TF*IDF als een kenmerk similariteitssysteem (ons boek bespreekt relevantie grotendeels in deze termen).
- U doet iets dat dicht bij niet-traditioneel komt. Je hebt een specifieke query taal te implementeren. U moet expliciet in kaart brengen volkstaal tussen deskundigen en leken. Je wilt leren ranken. Je wilt gecontroleerde vocabulaires gebruiken, semantisch zoeken opbouwen. U hebt specifieke geo-problemen. Dit zijn allemaal mogelijkheden die je in Solr/ES kunt inbouwen en je zit vast aan wat Algolia je geeft.
- Je wilt het gedrag van de zoekmachine diepgaand manipuleren. Dit is een groot deel van Lucene’s sweet spot.
Maar er zijn een paar redenen waarom ik Algolia sterk zou overwegen
- Je hebt een klein team, maar goed zoeken is belangrijk. Algolia werkt vrij goed uit de doos. Het heeft een goed niveau van configureerbaarheid van rangschikking die zowel tekst als numerieke waarden zoals populariteit met enige geo-ondersteuning kan bevatten.
- U moet primair single-item lookups ondersteunen. Algolia’s aanpak is ideaal voor gevallen zoals het zoeken naar “banaan” en overeenkomen met bananen. Algolia is wellicht niet zinvol voor gebruikers die “minion fruit” intypen en bananen verwachten.
- U moet typefouten ondersteunen. Lucene oplossingen voor dit zijn onhandig. Ik hoop dat ze beter en sneller worden, maar fuzzy searching is niet Lucene’s sweet spot.
Hier zijn een paar stukken marketing van Algolia waar ik het niet mee eens ben:
- Algolia wijst er graag op dat het hosten van Elasticsearch moeilijk zal zijn. Ik denk dat dit met opties als Bonsai en Elastic Cloud nauwelijks het geval is. Met een goede ES-host heb je in feite een goede “API in de cloud”, waarmee net zo gemakkelijk te werken is als met elke andere service.
- Algolia wil je doen geloven dat Elasticsearch geen goede zoekmachine is. Het is alleen goed in big data analytics en “big data search” (niet zeker wat dat betekent). In de geest van het vinden van “things not strings” zou ik het daar niet mee eens zijn. Het vergt gewoon werk en inzicht in wat er zo bijzonder is aan je zoekoplossing.
- Algolia hoopt dat alles direct zoeken wordt. Maar mijn ervaring is dat het overgrote deel van de zoekervaringen (zelfs veel die door Algolia worden aangestuurd) eerst autocomplete zijn om trefwoorden te selecteren, en dan pas trefwoord-zoeken. Dit is nog steeds in Lucene’s sweet spot voor zoeken.
- Ik geloof de benchmarks die Algolia geeft, maar er wordt opgemerkt dat ze geen snellere instant search strategieën op Elasticsearch uitproberen. We kunnen hun benchmarks zelf niet namaken. Algolia lijkt betrouwbaar, maar ik wou dat ik dit onafhankelijk kon testen. Ik zou ook graag zien dat ze het opnieuw doen met nieuwere Elasticsearch versies.
Maar Algolia wijst op belangrijke zwakheden in Lucene’s relevantie model
- Typos en fuzzy matching: Voor zover de wereld instant search met typo tolerantie wil, is Lucene-gebaseerd zoeken moeilijk aan de praat te krijgen. Ik geloof ook dat het langzamer is dan de gerichte oplossing van Algolia (hoewel ik de benchmarks niet kan reconstrueren).
- Elasticsearch/Solr standaardwaarden voor relevantie zijn moeilijk af te stellen. Zoals Algolia terecht opmerkt, levert de dismax rangschikkingsfunctie tamelijk verwarrende resultaten op. We schrijven hier over dat fenomeen. Je kunt en moet van deze standaardinstellingen af, maar ik zou willen dat zoeken direct zinvoller was.
- Elasticsearch- en Solr-primitieven voor relevantie voelen low-level aan. Algolia’s voelen hoger niveau en meer gericht op het creëren van een gemeenschappelijk begrip tussen de business en ontwikkelaars. Dit is een belangrijke reden waarom we Quepid hebben gebouwd. Maar toch, met alle opties in Solr/ES krijg je nog steeds blinde blikken van de business als je begint te praten in termen van booleaanse queries, functie queries, en wat al niet meer.
Mijn grote les is dat ik eigenlijk best enthousiast ben over Algolia voor de juiste use cases. Maar je moet er zeker van zijn dat het aan je behoeften voldoet. Ik hoop dat dit u een beter geïnformeerde koper heeft gemaakt.