Tankar om Algolia (vs Solr & Elasticsearch)
1 juni 2016 Doug Turnbull Kategori: Efter att ha blivit sur på ett blogginlägg om Algolia, och efter att ha haft ett Search Disco-avsnitt med Julien Lemoine, CTO för Algolia, är jag fortfarande fascinerad av lösningen.
Algolia, så hett just nu!
Algolia förutsätter att vi alla vill ha omedelbar sökning (även kallad ”search-as-you-type”). Därför har de byggt extremt bra, värdbaserad direktsökning. Allt man vill göra med omedelbar sökning finns där. Läs bara det här fantastiska inlägget om förståelse av frågor
- Typo tolerans, ”Doug Trunbull”
- Prefixsökning ”Doug Turn”
- Prefix med typo tolerans ”Doug Trun”
- Decompounding (ibland kan detta vara typo tolerans) DougTrun
- En lemmatisering av frågor, och mer…
Det är som om man istället för sökning har autokomplettering på steroider. Kombinera detta med en sundare standardklassificering än Elasticsearch eller Solr och du får en ganska övertygande produkt.
Jag säger allt detta som en ganska rabiat Lucenist. Jag skrev en bok om Relevance in Lucene. Jag är mycket partisk mot Lucene, eftersom jag har sett många övertygande lösningar byggda med Solr och Elasticsearch också.
En sak som jag dock har lärt mig om Lucene-baserad sökning är att du, med ett bra team, kan bygga nästan vilken sökande sak som helst med det. Men det krävs ett team. Lucene-baserad sökning är egentligen inte tänkt att fungera bra ”out of the box” för din lösning. Oavsett hur enkelt Elasticsearch har gjort det, är Lucene-baserad sökning ett ramverk, inte en lösning. Det är en uppsättning riktigt fantastiska sökfokuserade datastrukturer som du relativt enkelt kan pussla ihop för att göra Your Thing™. Även om din sak™ innebär att du måste ändra detaljer på så låg nivå som hur indexet lagras på disk!
Ett annat sätt att säga det är att du kan bygga Algolia i Elasticsearch (eller komma tillräckligt nära). Du kan inte bygga Elasticsearch i Algolia. Du vinner på att Algolia fokuserar på ett specifikt problem. Du offrar den djupa anpassningsbarheten och utbyggbarheten hos öppen källkod. Ett annat sätt att säga det är att jämföra söklösningar med webbapplikationer. På många sätt är Algolia som att bygga en webbplats med en webbplatsbyggare som Wix. Lucene är mer som att bygga en egen webbapp med utvecklare bakom sig, och alla tillhörande överväganden på låg nivå, irritationsmoment, men också kraft.
Ett exempel är Algolias jämförelse av prestanda med Elasticsearch. I Algolias tester hävdar Algolia upp till 200 gånger bättre prestanda. I genomsnitt är det snarare en 10-20x prestandaförbättring (fortfarande imponerande). Algolia valde dock den minsta gemensamma nämnaren i omedelbar sökning i Elasticsearch: fuzzy queries och prefix queries. Som det står skrivet i Elasticsearch: The Definitive Guide är ett annat vanligt tillvägagångssätt som förbättrar hastigheten enormt att använda ngrams. I grund och botten undviker man det fuzzy arbetet vid förfrågan och bygger en gigantisk datastruktur som kan hantera det.
Nu har ngrams sina egna problem. De ökar ditt index. I fallet med 2 miljoner dokument med mycket kort text kanske det dock inte sväller indexet så mycket. Och jag misstänker att det skulle ge förbättringar i storleksordning när det gäller prestanda. Om ett uppblåst index skulle bli ett problem skulle vi kunna producera färre ngrams av större storlek. Det finns också caching att ta hänsyn till: Jag slår vad om att båda lösningarna cachelagrar resultaten för varje knapptryckningsfråga. Så jag undrar hur det färgar Algolia vs ES-övervägandet.
Vi skulle till och med kunna vända termer som placeras i indexet för att få suffixförfrågningar för att fånga upp tidigare skrivfel. Eller göra exotiska saker med fuzzy queries och ngrams samtidigt. Vi kan till och med skriva en Lucene-förfrågan som fokuserar på stavfel. Titta på all kraft här!
Punkten är dock att jag har fått dig att börja tänka på hur du skulle lösa problemet. Algolia har redan byggt en lösning! Varför inte bara köra med deras? Det finns ett par reservationer som jag skulle ha om jag gick helt och hållet in i Algolia-lägret:
- Turn-key kan ofta bli till en inlåsning. Det finns exempel på att värdbaserade söklösningar (och databaser) har förvärvats och att den nya ägaren (i FoundationDB:s fall Apple) inte är intresserad av att stödja den befintliga verksamheten.
- Du bryr dig om ”saker som inte är strängar”. Algolias lösning fokuserar starkt på specifik strängmatchning. Lucene’s strategi för relevans fokuserar mer abstrakt på termer som innehållsfunktioner, och använder TF*IDF som ett system för likhet mellan funktioner (vår bok diskuterar till stor del relevans i dessa termer).
- Du gör något som är i närheten av icke-traditionellt. Ni har ett särskilt frågespråk att implementera. Du måste uttryckligen kartlägga språkbruk mellan experter och lekmän. Du vill göra inlärning för att rangordna. Du vill använda kontrollerade vokabulärer och bygga upp semantiska sökningar. Du har särskilda Geofrågor. Alla dessa funktioner kan byggas in i Solr/ES och du är låst till vad Algolia ger dig.
- Du vill manipulera sökmotorns beteende på djupet. Detta är en stor del av Lucene’s sweet spot.
Men det finns ett par anledningar till att jag starkt skulle överväga Algolia
- Du har ett litet team, men bra sökning är viktigt. Algolia fungerar ganska bra direkt ur lådan. Det har en bra nivå av konfigurerbarhet av ranking som kan inkludera både text och numeriska värden som popularitet med visst geostöd.
- Du behöver i första hand ha stöd för sökningar av enstaka objekt. Algolias tillvägagångssätt är idealiskt för fall som att behöva söka upp ”banan” och matcha på bananer. Algolia är kanske inte så bra för användare som skriver ”minion fruit” och förväntar sig bananer.
- Du behöver stöd för stavfel. Lucene-lösningarna för detta är besvärliga. Jag hoppas att de blir bättre och snabbare, men fuzzy searching är inte Lucene’s sweet spot.
Här är ett par delar av Algolias marknadsföring som jag inte håller med om:
- Algolia gillar att påpeka att hosting av Elasticsearch kommer att vara svårt. Jag tror att med alternativ som Bonsai och Elastic Cloud är detta knappast fallet. Med ett bra ES-värd har du i princip ett bra ”API i molnet” som är lika lätt att arbeta med som vilken annan tjänst som helst.
- Algolia vill få dig att tro att Elasticsearch inte är en bra sökmotor. Den är bara bra på big data-analyser och ”big data-sökning” (vet inte riktigt vad det betyder). I andan av att hitta ”saker som inte är strängar” håller jag inte med. Det krävs bara arbete och förståelse för vad som är speciellt med din söklösning.
- Algolia hoppas att allt ska bli omedelbar sökning. Men enligt min erfarenhet är den övervägande delen av sökupplevelser (även många som drivs av Algolia) först autokomplettering för att välja nyckelord och sedan nyckelordssökning. Detta ligger fortfarande i Lucene’s sweet spot för sökning.
- Jag tror på de riktmärken som Algolia tillhandahåller, men det noteras att de inte prövar snabbare strategier för omedelbar sökning på Elasticsearch. Vi kan inte återskapa deras riktmärken själva. Algolia verkar trovärdig, men jag önskar att jag kunde testa detta oberoende. Jag skulle också vilja se dem köra om mot nyare Elasticsearch-versioner.
Men Algolia pekar på viktiga svagheter i Lucene’s relevansmodell
- Typos och fuzzy matchning: I den utsträckning som världen vill ha omedelbar sökning med typo-tolerans är Lucene-baserad sökning svår att få att fungera. Jag tror också att den är långsammare än Algolias fokuserade lösning (även om jag inte kan återskapa riktmärkena).
- Elasticsearch/Solr:s standardinställningar för relevans är svåra att ställa in. Som Algolia med rätta påpekar ger rangordningsfunktionen dismax ganska förvirrande resultat. Vi skriver om det fenomenet här. Du kan och bör komma bort från dessa standardinställningar, men jag önskar att sökning var mer meningsfullt utifrån boxen.
- Elasticsearch och Solr primitiv för relevans känns på låg nivå. Algolias känns på högre nivå och mer inriktade på att skapa en gemensam förståelse mellan verksamheten och utvecklarna. Detta är en stor anledning till att vi byggde Quepid. Även med alla alternativ i Solr/ES kommer du fortfarande att få tomma blickar från verksamheten när du börjar tala i termer av booleska frågor, funktionsfrågor och vad som helst.
Min stora behållning är att jag faktiskt är ganska entusiastisk över Algolia för rätt användningsfall. Men du måste vara säker på att det kommer att tillfredsställa dina behov. Jag hoppas att detta har gjort dig till en mer informerad köpare.