Ajatuksia Algoliasta (vs. Solr & Elasticsearch)
June 1, 2016 Doug Turnbull Category: Lucene
Kun olen kärttyisä yhdestä Algolia-blogipostauksesta ja kun minulla on Search Disco -jakso Julien Lemoine CTO Algolian kanssa, olen jäänyt kiehtovaksi ratkaisusta.
Algolia, so hot right now!
Algolia olettaa, että me kaikki aiomme haluta välitöntä etsintää (aka haku niin kuin kirjoitat). Joten he ovat rakentaneet erittäin hyvän, isännöidyn pikahaun. Kaikki mitä haluat tehdä pikahaun kanssa on olemassa. Lue vain tämä hämmästyttävä viesti kyselyjen ymmärtämisestä
- Tyyppivirheiden sieto, ”Doug Trunbull”
- Prefiksin haku ”Doug Turn”
- Prefiksi, jossa on tyyppivirheiden sieto ”Doug Trun”
- Decompounding (toisinaan tämä voi olla myös tyyppivirheiden sieto) DougTrun
- Kyselyn aikainen lemmatizer, ja paljon muuta…
Se on kuin haun sijaan sinulla olisi autocomplete steroideilla. Kun tähän yhdistetään Elasticsearchia tai Solria järkevämpi oletusarvoinen ranking, jää jäljelle melko vakuuttava tuote.
Sanon tämän kaiken melko raivokkaana Lucenistina. Kirjoitin kirjan Relevance in Lucene. Olen hyvin puolueellinen Lucenea kohtaan, koska olen nähnyt monia vakuuttavia ratkaisuja, jotka on rakennettu Solrilla ja Elasticsearchilla.
Yksi asia, jonka olen oppinut Lucene-pohjaisesta hausta, on se, että hyvällä tiimillä voit rakentaa sillä melkein mitä tahansa hakutyyppistä asiaa. Siihen tarvitaan kuitenkin tiimi. Lucene-pohjaisen haun ei todellakaan ole tarkoitus toimia hyvin ”out of the box” omaan ratkaisuun. Riippumatta siitä, miten helpoksi Elasticsearch on sen tehnyt, Lucene-pohjainen haku on kehys, ei ratkaisu. Se on joukko todella hämmästyttäviä hakuun keskittyviä tietorakenteita, jotka voit koota suhteellisen helposti tekemään Your Thing™ -tehtäväsi. Vaikka Your Thing™ tarkoittaisikin niinkin matalan tason yksityiskohtien muuttamista kuin se, miten indeksi tallennetaan levylle!
Toinen tapa sanoa tämä on, että voisit rakentaa Algolian Elasticsearchiin (tai päästä tarpeeksi lähelle sitä). Elasticsearchia ei voi rakentaa Algoliaan. Saat Algoliasta keskittyä tiettyyn ongelmaan. Uhraat avoimen lähdekoodin syvällisen muokattavuuden ja laajennettavuuden. Vielä toinen tapa sanoa se on verrata hakuratkaisuja verkkosovelluksiin. Algolia on monella tapaa kuin rakentaisi sivuston Wixin kaltaisella sivustonrakentajalla. Lucene on enemmänkin kuin oman web-sovelluksen rakentaminen, jonka takana on kehittäjiä, ja kaikki siihen liittyvät matalan tason näkökohdat, harmit, mutta myös teho.
Tapauksena on Algolian suorituskykyvertailu Elasticsearchiin. Algolian testeissä Algolia väittää jopa 200-kertaista suorituskykyparannusta. Keskimäärin on enemmänkin 10-20x suorituskykyparannus (silti vaikuttavaa). Algolia valitsi kuitenkin Elasticsearchin pikahaun pienimmän yhteisen nimittäjän: sumeat kyselyt ja etuliitekyselyt. Kuten Elasticsearchissa kirjoitetaan: The Definitive Guide toinen yleinen lähestymistapa, joka parantaa nopeutta valtavasti, on käyttää ngrammeja. Periaatteessa vältetään kyselyaikaisen sumean työn tekeminen ja rakennetaan jättimäinen tietorakenne, joka pystyy hoitamaan sen.
Nyt ngrammeissa on omat ongelmansa. Ne kasvattavat indeksiäsi. Kuitenkin, jos kyseessä on 2 miljoonaa dokumenttia, joissa on paljon lyhyttä tekstiä, se ei välttämättä paisuta indeksiä niin paljon. Ja epäilen, että se parantaisi suorituskykyä kertaluokkaa. Jos paisuneesta indeksistä tulisi ongelma, voisimme tuottaa vähemmän suurempia ngrammeja. Myös välimuistiin tallentaminen on otettava huomioon: Veikkaan, että molemmat ratkaisut tallentavat tulokset välimuistiin jokaista näppäinkyselyä varten. Ihmettelen siis, miten tämä värittää Algolia vs. ES -pohdintaa.
Voisimme jopa kääntää indeksiin sijoitetut termit päinvastaisiksi, jotta saisimme suffiksikyselyillä aikaisemmat kirjoitusvirheet kiinni. Tai tehdä eksoottisia asioita sumeilla kyselyillä ja ngrammeilla samanaikaisesti. Voisimme jopa kirjoittaa Lucene-kyselyn, joka keskittyy kirjoitusvirheisiin.
Pointtina on kuitenkin se, että sain sinut miettimään, miten voisit ratkaista ongelman. Algolia on jo rakentanut ratkaisun! Miksi et vain ajaisi heidän mukanaan? No, on pari varausta, joita minulla olisi, jos menisin täysin Algolian leiriin:
- Turn-key voi usein muuttua lukkiutumiseksi. On esimerkkejä siitä, että isännöityjä hakuratkaisuja (ja tietokantoja on ostettu ja uusi omistaja (FoundationDB:n tapauksessa Apple) ei ole kiinnostunut tukemaan olemassa olevaa liiketoimintaa.
- Sinä välität ”asioista, et merkkijonoista”. Algolian ratkaisu keskittyy vahvasti tiettyyn merkkijonojen täsmäytykseen. Lucenen lähestymistapa relevanssiin keskittyy abstraktimmin termeihin sisällön ominaisuuksina, käyttäen TF*IDF:ää ominaisuuksien samankaltaisuusjärjestelmänä (kirjassamme käsitellään relevanssia pitkälti näillä termeillä).
- Sinä teet jotakin lähellekään ei-perinteistä. Sinulla on erityinen kyselykieli toteutettavana. Sinun on eksplisiittisesti kartoitettava asiantuntijoiden ja maallikoiden väliset puhekielet. Haluat tehdä learning-to-rank. Haluat käyttää kontrolloituja sanastoja, rakentaa semanttisen haun. Sinulla on erityisiä Geo-kysymyksiä. Kaikki nämä ominaisuudet voit rakentaa Solr/ES:ään, ja olet sidottu siihen, mitä Algolia antaa sinulle.
- Haluat manipuloida hakukoneen käyttäytymistä syvällisesti. Tämä on suuri osa Lucenen sweet spotista.
Mutta on pari syytä, miksi harkitsisin vahvasti Algolia
- Sinulla on pieni tiimi, mutta hyvä haku on tärkeää. Algolia toimii aika hyvin suoraan laatikosta. Se on hyvin konfiguroitavissa paremmuusjärjestykseen, joka voi sisältää sekä tekstiä että numeerisia arvoja, kuten suosio, ja jossa on jonkin verran geotukea.
- Tarpeesi on ensisijaisesti tukea yhden kohteen hakuja. Algolian lähestymistapa on ihanteellinen esimerkiksi tapauksissa, joissa on etsittävä ”banaani” ja etsittävä banaaneja. Algolia ei ehkä ole järkevä käyttäjille, jotka kirjoittavat ”minion fruit” ja odottavat banaaneja.
- Sinun täytyy tukea kirjoitusvirheitä. Lucenen ratkaisut tähän ovat hankalia. Toivon, että ne paranevat ja nopeutuvat, mutta sumea haku ei ole Lucenen herkkua.
Tässä on pari Algolian markkinoinnin kohtaa, joista olisin eri mieltä:
- Algolia tykkää huomauttaa, että Elasticsearchin isännöinti tulee olemaan vaikeaa. Mielestäni Bonsain ja Elastic Cloudin kaltaisilla vaihtoehdoilla tämä tuskin pitää paikkaansa. Hyvän ES-isännän kanssa sinulla on periaatteessa hyvä ”API pilvessä”, jonka kanssa on yhtä helppo työskennellä kuin minkä tahansa muun palvelun kanssa.
- Algolia haluaa uskotella, että Elasticsearch ei ole hyvä hakukone. Se on hyvä vain big data -analytiikassa ja ”big data -haussa” (en ole varma mitä se tarkoittaa). ”Things not stringien” löytämisen hengessä olisin eri mieltä. Se vain vaatii työtä ja sen ymmärtämistä, mikä hakuratkaisussa on erityistä.
- Algolia toivoo, että kaikesta tulee pikahaku. Silti kokemukseni mukaan valtaosa hakukokemuksista (jopa monet Algolian ajamat) ovat autocompletea ensin avainsanojen valitsemiseksi ja sitten avainsanahaku. Tämä on edelleen Lucenen makeassa pisteessä hakua varten.
- Uskon Algolian tarjoamiin vertailuarvoihin, mutta on huomattu, että he eivät kokeile nopeampia pikahakustrategioita Elasticsearchilla. Emme voi itse luoda heidän benchmarkkejaan uudelleen. Algolia vaikuttaa luotettavalta, mutta voisinpa testata tätä itsenäisesti. Toivoisin myös, että ne ajettaisiin uudestaan uudempia Elasticsearch-versioita vastaan.
Mutta Algolia huomauttaa tärkeistä heikkouksista Lucenen relevanssimallissa
- Tyypittelyt ja sumea täsmäytys: Siinä määrin kuin maailma haluaa pikahakua, jossa on kirjoitusvirheiden sieto, Luceneen perustuvaa hakua on vaikea saada toimimaan. Uskon myös, että se on hitaampi kuin Algolian fokusoitu ratkaisu (en tosin pysty luomaan benchmarkkeja uudelleen).
- Elasticsearch/Solrin oletusarvot relevanssille ovat vaikeasti viritettävissä. Kuten Algolia aivan oikein huomauttaa, dismax-ranking-funktio tuottaa melko sekavia tuloksia. Kirjoitamme tästä ilmiöstä täällä. Näistä oletusarvoista voi ja pitääkin päästä eroon, mutta toivoisin, että haku olisi järkevämpää suoraan laatikosta.
- Elasticsearchin ja Solrin alkeisarvot relevanssille tuntuvat matalalta. Algolian ominaisuudet tuntuvat korkeammalta tasolta ja keskittyvät enemmän yhteisen ymmärryksen luomiseen liiketoiminnan ja kehittäjien välille. Tämä on yksi iso syy, miksi rakensimme Quepidin. Kaikista Solr/ES:n vaihtoehdoista huolimatta saat silti tyhjiä katseita liiketoimintaosapuolelta, kun alat puhua boolean-kyselyistä, funktiokyselyistä ja muusta vastaavasta.
Minulle jäi mieleen, että olen itse asiassa aika innostunut Algoliasta oikeissa käyttötapauksissa. Mutta sinun täytyy olla varma, että se täyttää tarpeesi. Toivottavasti tämä on tehnyt sinusta tietoisemman ostajan.