Tanker om Algolia (vs Solr & Elasticsearch)
1. juni 2016 Doug Turnbull Kategori: Lucene
Efter at være blevet sur på et Algolia blogindlæg, og efter at have haft en Search Disco episode med Julien Lemoine CTO for Algolia, er jeg efterladt fascineret af løsningen.
Algolia, så hot lige nu!
Algolia forudsætter, at vi alle vil have instant search (aka search-as-you-type). Så de har bygget ekstremt god, hosted instant search. Alt, hvad du ønsker at gøre med øjeblikkelig søgning, er der. Læs blot dette fantastiske indlæg om forespørgselsforståelse
- Typo-tolerance, “Doug Trunbull”
- Prefix-søgning “Doug Turn”
- Prefix med typo-tolerance “Doug Trun”
- Decompounding (nogle gange kan dette være typo-tolerance) DougTrun
- A query-time lemmatizer, og meget mere…
Det er som om, at man i stedet for søgning har autokomplettering på steroider. Kombiner dette med en mere fornuftig standardklassificering end Elasticsearch eller Solr, og du står tilbage med et ret overbevisende produkt.
Jeg siger alt dette som en ret rabiat Lucenist. Jeg skrev en bog om Relevance i Lucene. Jeg er meget forudindtaget over for Lucene, da jeg også har set mange overbevisende løsninger bygget med Solr og Elasticsearch.
En ting, som jeg dog har lært om Lucene-baseret søgning, er, at du med et godt team kan bygge stort set enhver søgemæssig ting med det. Men det kræver dog et team. Lucene-baseret søgning er ikke rigtig beregnet til at fungere godt “out of the box” for din løsning. Uanset hvor let Elasticsearch har gjort det, så er Lucene-baseret søgning en ramme, ikke en løsning. Det er et sæt virkelig fantastiske søgefokuserede datastrukturer, som du relativt nemt kan sammensætte til at gøre Your Thing™. Selv om Your Thing™ betyder at ændre detaljer på så lavt niveau som hvordan indekset bliver gemt på disken!
En anden måde at sige det på er, at du kan bygge Algolia i Elasticsearch (eller komme tæt nok på). Du kan ikke bygge Elasticsearch i Algolia. Du vinder ved at Algolia fokuserer på et specifikt problem. Du ofrer dybe tilpasningsmuligheder og udvidelsesmuligheder ved open source. Endnu en anden måde at sige det på er at sammenligne søgeløsninger med webapps. På mange måder er Algolia som at bygge et websted med en webside builder som Wix. Lucene er mere som at bygge sin egen web-app med udviklere bag sig og alle de tilhørende overvejelser på lavt niveau, irritationsmomenter, men også magt.
Et eksempel er Algolias sammenligning af ydeevne med Elasticsearch. I Algolias tests hævder Algolia op til 200x forbedret ydelse. I gennemsnit er der snarere tale om en 10-20x ydelsesforbedring (stadig imponerende). Algolia valgte dog den laveste fællesnævner inden for øjeblikkelig søgning i Elasticsearch: fuzzy queries og prefix queries. Som der står skrevet i Elasticsearch: The Definitive Guide er en anden almindelig tilgang, der forbedrer hastigheden enormt, at bruge ngrams. Grundlæggende undgår man det fuzzy arbejde i forespørgselstiden og bygger en gigantisk datastruktur, der kan håndtere det.
Nu har ngrams deres egne problemer. De øger dit indeks. Men i tilfælde af 2 millioner dokumenter med masser af kort tekst, vil det måske ikke opblæse indekset så meget. Og jeg formoder, at det ville have forbedringer af størrelsesordener i ydeevne. Hvis et oppustet indeks blev et problem, kunne vi producere færre ngrammer af større størrelse. Der er også caching at overveje: Jeg vil vædde med, at begge løsninger cacher resultaterne for hver tastetrykforespørgsel. Så jeg spekulerer på, hvordan det farver Algolia vs. ES-overvejelsen.
Vi kunne endda vende termer, der er placeret i indekset, for at få suffixforespørgsler til at fange tidligere skrivefejl. Eller gøre eksotiske ting med fuzzy queries og ngrams samtidig. Vi kunne måske endda skrive en Lucene-forespørgsel, der fokuserer på stavefejl. Se al den magt, der er her!
Punktet er dog, at jeg har fået dig til at begynde at tænke over, hvordan du vil løse problemet. Algolia har allerede bygget en løsning! Hvorfor ikke bare køre med deres? Der er et par forbehold, som jeg ville have, hvis jeg gik helt ind i Algolia-lejren:
- Turn-key kan ofte blive til lock-in. Der er eksempler på at hostede søgeløsninger (og databaser) er blevet opkøbt, og at den nye ejer (I FoundationDB’s tilfælde Apple) ikke er interesseret i at støtte den eksisterende forretning.
- Du bekymrer dig om “ting og ikke strenge”. Algolia’s løsning fokuserer stærkt på specifik strengmatchning. Lucene’s tilgang til relevans fokuserer mere abstrakt på termer som features af indhold, og bruger TF*IDF som et feature similarity system (vores bog diskuterer i høj grad relevans i disse termer).
- Du gør noget nær utraditionelt. Du har et specifikt forespørgselssprog, der skal implementeres. Du er nødt til eksplicit at kortlægge sprogbrug mellem eksperter og lægfolk. Du ønsker at foretage learning-to-rank. Du ønsker at bruge kontrollerede ordforråd og opbygge semantisk søgning. Der er specifikke Geo-problemer. Alle disse funktioner kan du bygge ind i Solr/ES, og du er låst fast til det, Algolia giver dig.
- Du ønsker at manipulere søgemaskinens adfærd i dybden. Dette er en stor del af Lucene’s sweet spot.
Men der er et par grunde til at jeg kraftigt vil overveje Algolia
- Du har et lille team, men god søgning er vigtig. Algolia fungerer ret godt out of the box. Det har en god grad af konfigurerbarhed af rangering, der kan omfatte både tekst og numeriske værdier som popularitet med en vis geo-understøttelse.
- Du har primært brug for at understøtte opslag af enkeltemner. Algolia’s tilgang er ideel til tilfælde som f.eks. at have brug for at slå op på “banan” og matche på bananer. Algolia giver måske ikke mening for brugere, der skriver “minionfrugt” og forventer bananer.
- Du har brug for at understøtte stavefejl. Lucene-løsninger til dette er besværlige. Jeg håber, at de bliver bedre og hurtigere, men fuzzy searching er ikke Lucene’s sweet spot.
Her er et par stykker af Algolia-markedsføringen, som jeg ville være uenig med:
- Algolia kan lide at påpege, at det bliver svært at hoste Elasticsearch. Jeg tror, at med muligheder som Bonsai og Elastic Cloud er dette næppe tilfældet. Med en god ES-vært har du i princippet et godt “API i skyen”, som er lige så nemt at arbejde med som enhver anden tjeneste.
- Algolia vil have dig til at tro, at Elasticsearch ikke er en god søgemaskine. Den er kun god til big data analytics og “big data search” (er ikke sikker på hvad det betyder). I ånden af at finde “ting der ikke er strenge” vil jeg være uenig. Det kræver bare arbejde og forståelse for, hvad der er specielt ved din søgeløsning.
- Algolia håber, at alting bliver instant search. Alligevel er det min erfaring, at den overvejende del af søgeoplevelser (selv mange drevet af Algolia) er autocomplete først for at vælge søgeord, og derefter søgeord søgning. Dette er stadig i Lucene’s sweet spot for søgning.
- Jeg tror på de benchmarks Algolia giver, men det er noteret, at de ikke prøver hurtigere instant search strategier på Elasticsearch. Vi kan ikke selv genskabe deres benchmarks. Algolia virker troværdig, men jeg ville ønske, at jeg kunne teste dette uafhængigt. Jeg kunne også godt tænke mig at se dem køre igen mod nyere Elasticsearch-versioner.
Men Algolia påpeger vigtige svagheder i Lucene’s relevansmodel
- Typos og fuzzy matching: I det omfang verden ønsker instant search med typografitolerance, er Lucene-baseret søgning svær at få til at fungere. Jeg vil også tro, at den er langsommere end Algolias fokuserede løsning (selvom jeg ikke kan genskabe benchmarks).
- Elasticsearch/Solr-defaults for relevans er svære at indstille. Som Algolia med rette påpeger, giver dismax-rangeringsfunktionen ret forvirrende resultater. Vi skriver om det fænomen her. Du kan og bør komme væk fra disse standardindstillinger, men jeg ville ønske, at søgning gav mere mening out of the box.
- Elasticsearch og Solr primitives for relevans føles lavt niveau. Algolia’s føles højere niveau og mere fokuseret på at skabe en fælles forståelse mellem forretning og udviklere. Dette er en stor grund til, at vi byggede Quepid. Selv med alle mulighederne i Solr/ES vil du stadig få tomme blikke fra forretningen, når du begynder at tale i termer af boolske forespørgsler, funktionsforespørgsler og hvad ved jeg.
Min store læreproces er, at jeg faktisk er ret begejstret for Algolia i de rigtige anvendelsestilfælde. Men du skal være sikker på, at det vil opfylde dine behov. Jeg håber, at dette har gjort dig til en mere informeret shopper.