Gedanken zu Algolia (vs. Solr & Elasticsearch)
Juni 1, 2016 Doug Turnbull Kategorie: Lucene
Nachdem ich mich über einen Algolia-Blogpost aufgeregt habe und eine Search-Disco-Episode mit Julien Lemoine, dem CTO von Algolia, hatte, bin ich von der Lösung fasziniert.
Algolia, so hot right now!
Algolia geht davon aus, dass wir alle eine sofortige Suche (aka search-as-you-type) wollen werden. Also haben sie eine extrem gute, gehostete Sofortsuche entwickelt. Alles, was man mit der Sofortsuche machen möchte, ist vorhanden. Lesen Sie einfach diesen erstaunlichen Beitrag über das Verstehen von Suchanfragen
- Typo-Toleranz, „Doug Trunbull“
- Präfix-Suche „Doug Turn“
- Präfix mit Typo-Toleranz „Doug Trun“
- Decompounding (manchmal kann dies Typo-Toleranz sein) DougTrun
- Ein Lemmatisierer für die Suchzeit und mehr…
Es ist, als ob man anstelle der Suche eine Autovervollständigung auf Steroiden hätte. Kombiniert mit einem vernünftigeren Standard-Ranking als bei Elasticsearch oder Solr bleibt ein ziemlich überzeugendes Produkt übrig.
Ich sage das alles als ein ziemlich fanatischer Lucenist. Ich habe ein Buch über Relevanz in Lucene geschrieben. Ich bin Lucene gegenüber sehr voreingenommen, da ich viele überzeugende Lösungen gesehen habe, die mit Solr und Elasticsearch gebaut wurden.
Eine Sache, die ich jedoch über die Lucene-basierte Suche gelernt habe, ist, dass man mit einem guten Team so ziemlich jede Art von Suche damit bauen kann. Allerdings braucht man dafür ein Team. Die Lucene-basierte Suche ist nicht wirklich dafür gedacht, dass sie „out of the box“ für Ihre Lösung gut funktioniert. Unabhängig davon, wie einfach Elasticsearch es gemacht hat, ist die Lucene-basierte Suche ein Framework, keine Lösung. Es handelt sich um eine Reihe von wirklich erstaunlichen, auf die Suche fokussierten Datenstrukturen, die Sie relativ einfach zusammenschustern können, um Ihr Thing™ zu erledigen. Selbst wenn Ihr Ding™ bedeutet, dass man Details auf so niedriger Ebene wie die Art und Weise, wie der Index auf der Festplatte gespeichert wird, ändern muss!
Eine andere Art, das zu sagen, ist, dass man Algolia in Elasticsearch bauen könnte (oder nahe genug herankommt). Man kann Elasticsearch nicht in Algolia bauen. Der Vorteil von Algolia ist die Konzentration auf ein bestimmtes Problem. Sie opfern die tiefe Anpassungsfähigkeit und Erweiterbarkeit von Open Source. Eine andere Art, dies zu sagen, ist der Vergleich von Suchlösungen mit Webanwendungen. In vielerlei Hinsicht ist Algolia wie der Aufbau einer Website mit einem Website-Builder wie Wix. Lucene ist eher wie der Aufbau einer eigenen Web-App mit Entwicklern dahinter und all den damit verbundenen Überlegungen, Ärgernissen, aber auch Möglichkeiten.
Ein Beispiel dafür ist der Leistungsvergleich von Algolia mit Elasticsearch. In den Tests von Algolia behauptet Algolia eine bis zu 200-fache Leistungssteigerung. Im Durchschnitt ergibt sich eher eine 10-20fache Leistungsverbesserung (immer noch beeindruckend). Algolia hat sich jedoch für den kleinsten gemeinsamen Nenner bei der Sofortsuche in Elasticsearch entschieden: Fuzzy-Abfragen und Präfix-Abfragen. Wie in Elasticsearch: The Definitive Guide steht, ist ein weiterer gängiger Ansatz, der die Geschwindigkeit enorm verbessert, die Verwendung von Ngrammen. Im Grunde vermeidet man die Fuzzy-Arbeit zur Abfragezeit und baut eine riesige Datenstruktur auf, die damit umgehen kann.
Nun haben Ngramme ihre eigenen Probleme. Sie lassen den Index wachsen. Im Falle von 2 Millionen Dokumenten mit vielen kurzen Texten wird der Index jedoch nicht so stark aufgebläht. Und ich vermute, dass sich dadurch die Leistung um Größenordnungen verbessern würde. Wenn ein aufgeblähter Index zu einem Problem wird, könnten wir weniger Ngramme mit größerem Umfang erstellen. Auch die Zwischenspeicherung ist zu berücksichtigen: Ich wette, beide Lösungen zwischenspeichern die Ergebnisse für jede Tastenanschlagabfrage. Ich frage mich also, wie sich das auf die Abwägung zwischen Algolia und ES auswirkt.
Wir könnten sogar Begriffe im Index umkehren, um Suffix-Abfragen zu erhalten, die frühere Tippfehler abfangen. Oder exotische Dinge mit Fuzzy-Abfragen und Ngrammen gleichzeitig machen. Wir könnten sogar eine Lucene-Abfrage schreiben, die sich auf Tippfehler konzentriert. Schauen Sie sich die ganze Macht hier an!
Der Punkt ist jedoch, dass ich Sie dazu gebracht habe, darüber nachzudenken, wie Sie das Problem lösen könnten. Algolia hat bereits eine Lösung entwickelt! Warum nicht einfach deren Lösung übernehmen? Nun, es gibt ein paar Vorbehalte, die ich hätte, wenn ich mich voll und ganz in das Algolia-Lager begeben würde:
- Der Schlüssel kann oft zu einem Lock-in werden. Es gibt Beispiele dafür, dass gehostete Suchlösungen (und Datenbanken) aufgekauft werden und der neue Eigentümer (im Fall von FoundationDB Apple) nicht daran interessiert ist, das bestehende Geschäft zu unterstützen.
- Sie interessieren sich für „Dinge, nicht Strings“. Die Lösung von Algolia konzentriert sich stark auf den Abgleich spezifischer Strings. Der Relevanzansatz von Lucene konzentriert sich abstrakter auf Begriffe als Merkmale von Inhalten und verwendet TF*IDF als Ähnlichkeitssystem für Merkmale (in unserem Buch wird Relevanz größtenteils mit diesen Begriffen diskutiert).
- Sie tun etwas, das fast nicht traditionell ist. Sie haben eine spezifische Abfragesprache zu implementieren. Sie müssen die Fachsprache von Experten und Laien explizit abbilden. Sie wollen Learning-to-Rank anwenden. Sie wollen kontrollierte Vokabulare verwenden und eine semantische Suche aufbauen. Sie haben spezifische Geo-Anliegen. All dies sind Funktionen, die Sie in Solr/ES einbauen können, und Sie sind an das gebunden, was Algolia Ihnen bietet.
- Sie wollen das Verhalten der Suchmaschine tiefgreifend manipulieren. Das ist ein großer Teil von Lucene’s Sweet Spot.
Aber es gibt ein paar Gründe, warum ich Algolia in Betracht ziehen würde
- Sie haben ein kleines Team, aber gute Suche ist wichtig. Algolia funktioniert von Haus aus ziemlich gut. Es bietet eine gute Konfigurierbarkeit des Rankings, das sowohl Text- als auch numerische Werte wie die Popularität mit einer gewissen geografischen Unterstützung enthalten kann.
- Sie müssen vor allem die Suche nach einzelnen Artikeln unterstützen. Der Ansatz von Algolia ist ideal für Fälle wie die Suche nach „Banane“ und die Suche nach Bananen. Algolia ist vielleicht nicht sinnvoll für Benutzer, die „Zwergfrucht“ eingeben und Bananen erwarten.
- Sie müssen Tippfehler unterstützen. Die Lösungen von Lucene sind in dieser Hinsicht umständlich. Ich hoffe, dass sie besser und schneller werden, aber unscharfe Suche ist nicht Lucene’s Spezialgebiet.
Hier sind ein paar Teile des Algolia Marketings, denen ich nicht zustimmen würde:
- Algolia weist gerne darauf hin, dass das Hosten von Elasticsearch schwierig sein wird. Ich denke, mit Optionen wie Bonsai und Elastic Cloud ist das kaum der Fall. Mit einem guten ES-Hoster hat man im Grunde eine gute „API in der Cloud“, mit der man genauso einfach arbeiten kann wie mit jedem anderen Dienst.
- Algolia möchte Ihnen weismachen, dass Elasticsearch keine gute Suchmaschine ist. Sie ist nur gut in der Big-Data-Analyse und „Big-Data-Suche“ (keine Ahnung, was das bedeutet). Im Sinne der Suche nach „Dingen, die keine Strings sind“ würde ich dem nicht zustimmen. Es erfordert einfach Arbeit und ein Verständnis dafür, was das Besondere an Ihrer Suchlösung ist.
- Algolia hofft, dass alles zur Sofortsuche wird. Meiner Erfahrung nach sind jedoch die meisten Sucherfahrungen (sogar viele, die von Algolia stammen) so, dass zuerst eine Autovervollständigung erfolgt, um Schlüsselwörter auszuwählen, und dann eine Schlüsselwortsuche. Das ist immer noch Lucene’s Sweet Spot für die Suche.
- Ich glaube den Benchmarks, die Algolia anbietet, aber es wird angemerkt, dass sie keine schnelleren Instant-Search-Strategien auf Elasticsearch ausprobieren. Wir können ihre Benchmarks nicht selbst nachstellen. Algolia scheint vertrauenswürdig zu sein, aber ich wünschte, ich könnte das unabhängig testen. Ich würde auch gerne sehen, dass sie mit neueren Elasticsearch-Versionen durchgeführt werden.
Aber Algolia weist auf wichtige Schwächen in Lucene’s Relevanzmodell hin
- Typos und Fuzzy-Matching: In dem Ausmaß, in dem die Welt eine Sofortsuche mit Tippfehler-Toleranz wünscht, ist Lucene-basierte Suche schwer zum Laufen zu bringen. Ich glaube auch, dass sie langsamer ist als die fokussierte Lösung von Algolia (obwohl ich die Benchmarks nicht nachvollziehen kann).
- Elasticsearch/Solr-Standardwerte für Relevanz sind schwer zu optimieren. Wie Algolia zu Recht anmerkt, liefert die dismax-Rankingfunktion ziemlich verwirrende Ergebnisse. Wir schreiben über dieses Phänomen hier. Man kann und sollte von diesen Voreinstellungen wegkommen, aber ich wünschte, die Suche würde von Anfang an mehr Sinn machen.
- Elasticsearch und Solr Primitive für Relevanz fühlen sich niedrig an. Die von Algolia fühlen sich auf einer höheren Ebene an und sind mehr darauf ausgerichtet, ein gemeinsames Verständnis zwischen dem Unternehmen und den Entwicklern zu schaffen. Das ist ein wichtiger Grund, warum wir Quepid entwickelt haben. Selbst mit all den Optionen in Solr/ES werden Sie immer noch leere Blicke von den Fachabteilungen ernten, wenn Sie anfangen, von booleschen Abfragen, Funktionsabfragen und so weiter zu sprechen.
Meine wichtigste Erkenntnis ist, dass ich von Algolia für die richtigen Anwendungsfälle ziemlich begeistert bin. Aber Sie müssen sicher sein, dass es Ihre Bedürfnisse befriedigen wird. Ich hoffe, dass Sie jetzt besser informiert sind.