Thoughts on Algolia (vs Solr & Elasticsearch)
June 1, 2016 Doug Turnbull Category: Lucene
Po uzyskaniu cranky na jednym poście na blogu Algolia, i mając odcinek Search Disco z Julien Lemoine CTO of Algolia, pozostaję zafascynowany rozwiązaniem.
Algolia, tak gorąca teraz!
Algolia zakłada, że wszyscy będziemy chcieli natychmiastowego wyszukiwania (aka search-as-you-type). Zbudowali więc bardzo dobre, hostowane wyszukiwanie natychmiastowe. Wszystko co chciałbyś zrobić z natychmiastowym wyszukiwaniem jest tam. Wystarczy przeczytać ten niesamowity post o zrozumieniu zapytań
- Tolerancja na literówki, „Doug Trunbull”
- Wyszukiwanie przedrostków „Doug Turn”
- Przedrostek z tolerancją na literówki „Doug Trun”
- Dekomponowanie (czasami może to być tolerancja na literówki) DougTrun
- Lematyzator zapytań, i więcej…
To tak jakby zamiast wyszukiwania, mieć autocomplete na sterydach. W połączeniu z bardziej rozsądnym domyślnym rankingiem niż Elasticsearch czy Solr, otrzymujemy całkiem atrakcyjny produkt.
Mówię to wszystko jako wściekły Lucenista. Napisałem książkę o Relevance w Lucene. Jestem bardzo stronniczy w stosunku do Lucene, ponieważ widziałem wiele ciekawych rozwiązań zbudowanych również z Solr i Elasticsearch.
Jedną rzeczą, której nauczyłem się o wyszukiwaniu opartym na Lucene jest to, że można, z dobrym zespołem, zbudować z niego prawie każdą wyszukiwaną rzecz. Jednak wymaga to zespołu. Wyszukiwanie oparte na Lucene nie jest tak naprawdę przeznaczone do pracy „z pudełka” dla twojego rozwiązania. Niezależnie od tego, jak bardzo Elasticsearch ułatwił to zadanie, wyszukiwanie oparte na Lucene to framework, a nie rozwiązanie. Jest to zestaw naprawdę niesamowitych struktur danych skoncentrowanych na wyszukiwaniu, które można stosunkowo łatwo poskładać, aby zrobić coś swojego. Nawet jeśli Twoja Rzecz™ oznacza zmianę szczegółów tak niskiego poziomu, jak sposób, w jaki indeks jest zapisywany na dysku!
Innym sposobem powiedzenia tego jest to, że możesz zbudować Algolię w Elasticsearch (lub uzyskać wystarczająco blisko). Nie możesz zbudować Elasticsearch w Algolii. Zyskujesz dzięki Algolii skupienie się na konkretnym problemie. Poświęcasz głębokie możliwości dostosowywania i rozszerzalności open source. Jeszcze innym sposobem, aby to powiedzieć jest porównanie rozwiązań wyszukiwania do aplikacji webowych. Pod wieloma względami Algolia jest jak budowanie witryny za pomocą kreatora witryn, takiego jak Wix. Lucene jest bardziej jak budowanie własnej aplikacji internetowej z deweloperami stojącymi za nią i wszystkimi związanymi z tym niskopoziomowymi rozważaniami, irytacją, ale także mocą.
Punktem odniesienia jest porównanie wydajności Algolii do Elasticsearch. W testach Algolia twierdzi, że do 200x poprawa wydajności. Średnio, jest to raczej 10-20x poprawa wydajności (wciąż imponująca). Jednakże, Algolia wybrała najniższy wspólny mianownik w natychmiastowym wyszukiwaniu w Elasticsearch: zapytania rozmyte i zapytania prefiksowe. Jak napisano w Elasticsearch: The Definitive Guide innym powszechnym podejściem, które znacznie poprawia prędkość jest użycie ngramów. Zasadniczo unikaj pracy z zapytaniami rozmytymi i zbuduj gigantyczną strukturę danych, która może sobie z tym poradzić.
Teraz ngramy mają swoje własne problemy. Powiększają one twój indeks. Jednak w przypadku 2 milionów dokumentów z dużą ilością krótkiego tekstu, może to nie nadymać indeksu tak bardzo. I podejrzewam, że miałoby to poprawę o rzędy wielkości w wydajności. Jeśli rozdęty indeks stałby się problemem, moglibyśmy produkować mniej ngramów o większym rozmiarze. Jest też buforowanie do rozważenia: Założę się, że oba rozwiązania buforują wyniki dla każdego zapytania o naciśnięcie klawisza. Więc zastanawiam się, jak to zabarwia rozważania Algolia vs ES.
Możemy nawet odwrócić terminy umieszczone w indeksie, aby uzyskać zapytania sufiksowe, aby złapać wcześniejsze literówki. Albo robić egzotyczne rzeczy z rozmytymi zapytaniami i ngramami jednocześnie. Możemy nawet napisać zapytanie do Lucene, które skupia się na literówkach. Spójrz na całą tę moc!
Chodzi jednak o to, że sprawiłem, iż zacząłeś myśleć o tym, jak rozwiązać ten problem. Algolia już zbudowała rozwiązanie! Dlaczego po prostu nie skorzystać z ich rozwiązania? Cóż, jest kilka zastrzeżeń, które chciałbym mieć, idąc na całość do obozu Algolia:
- Turn-key może często zamienić się w lock-in. Istnieją przykłady hostowanych rozwiązań wyszukiwania (i baz danych), które zostały przejęte, a nowy właściciel (w przypadku FoundationDB – Apple) nie był zainteresowany wspieraniem istniejącego biznesu.
- Dbasz o „rzeczy, a nie ciągi znaków”. Rozwiązanie Algolia silnie koncentruje się na dopasowywaniu konkretnych ciągów. Podejście Lucene do relewancji koncentruje się bardziej abstrakcyjnie na terminach jako cechach treści, używając TF*IDF jako systemu podobieństwa cech (nasza książka w dużej mierze omawia relewancję w tych kategoriach).
- Robisz coś bliskiego nietradycyjności. Masz specyficzny język zapytań do wdrożenia. Musisz wyraźnie mapować wernakularze między ekspertami a laikami. Chcesz zrobić learning-to-rank. Chcesz używać kontrolowanych słowników, budować wyszukiwanie semantyczne. Masz konkretne problemy związane z Geo. To wszystko są funkcjonalności, które można wbudować w Solr/ES, a w Algolii jesteśmy zamknięci na to, co daje nam Algolia.
- Chcemy głęboko manipulować zachowaniem wyszukiwarki. Jest to ogromna część możliwości Lucene.
Jest jednak kilka powodów, dla których mocno rozważyłbym Algolię
- Masz mały zespół, ale dobre wyszukiwanie jest ważne. Algolia działa całkiem dobrze po wyjęciu z pudełka. Ma dobry poziom konfigurowalności rankingu, który może obejmować zarówno tekst, jak i wartości liczbowe, takie jak popularność z pewnym wsparciem geo.
- Potrzebujesz przede wszystkim wsparcia dla wyszukiwania pojedynczych elementów. Podejście Algolia jest idealne dla przypadków takich jak potrzeba wyszukiwania „bananów” i dopasowania do bananów. Algolia może nie mieć sensu dla użytkowników, którzy wpisują „minion fruit” i oczekują bananów.
- Potrzebujesz obsługi literówek. Rozwiązania Lucene w tym zakresie są niezręczne. Mam nadzieję, że będą one coraz lepsze i szybsze, ale wyszukiwanie rozmyte nie jest słodkim punktem Lucene.
Oto kilka elementów marketingu Algolii, z którymi bym się nie zgodził:
- Algolia lubi wskazywać, że hosting Elasticsearch będzie trudny. Myślę, że z opcjami takimi jak Bonsai i Elastic Cloud, to prawie nie ma miejsca. Z dobrym hostingiem ES, w zasadzie masz dobre „API w chmurze”, które jest tak samo łatwe do pracy, jak każda inna usługa.
- Algolia chce, abyś uwierzył, że Elasticsearch nie jest dobrą wyszukiwarką. Jest dobry tylko w analityce dużych danych i „wyszukiwaniu dużych danych” (nie jestem pewien, co to znaczy). W duchu znajdowania „rzeczy nie ciągów” nie zgodziłbym się. To po prostu wymaga pracy i zrozumienia, co jest specjalnego w twoim rozwiązaniu wyszukiwania.
- Algolia ma nadzieję, że wszystko stanie się natychmiastowym wyszukiwaniem. Jednak z mojego doświadczenia wynika, że większość wyszukiwań (nawet tych prowadzonych przez Algolię) to najpierw autocomplete, aby wybrać słowa kluczowe, a następnie wyszukiwanie słów kluczowych. To wciąż jest w słodkim miejscu Lucene dla wyszukiwania.
- Wierzę w benchmarki, które dostarcza Algolia, ale zauważono, że nie próbują szybszych strategii natychmiastowego wyszukiwania na Elasticsearch. Nie jesteśmy w stanie sami odtworzyć ich benchmarków. Algolia wydaje się godna zaufania, ale chciałbym móc przetestować to niezależnie. Chciałbym również zobaczyć ich ponowne uruchomienie przeciwko nowszym wersjom Elasticsearch.
Ale Algolia wskazuje na ważne słabości modelu relewancji Lucene
- Typy i dopasowanie rozmyte: W zakresie, w jakim świat chce natychmiastowego wyszukiwania z tolerancją na literówki, wyszukiwanie oparte na Lucene jest trudne do uzyskania pracy. Wierzę również, że jest wolniejsze niż rozwiązanie Algolii (choć nie mogę odtworzyć benchmarków).
- Domyślne ustawienia relewancji w Elasticsearch/Solr są trudne do dostrojenia. Jak słusznie zauważa Algolia, funkcja rankingowa dismax daje dość mylące wyniki. Piszemy o tym zjawisku tutaj. Można i warto uciec od tych domyślnych ustawień, ale chciałbym, aby wyszukiwanie miało więcej sensu po wyjęciu z pudełka.
- Elasticsearch i Solr prymitywy dla relewancji są niskopoziomowe. Algolia ma wrażenie, że są one na wyższym poziomie i bardziej skupiają się na tworzeniu wspólnego zrozumienia pomiędzy biznesem a programistami. Jest to jeden z głównych powodów, dla których zbudowaliśmy Quepid. Mimo to, przy wszystkich opcjach Solr/ES, nadal można spotkać się z pustymi spojrzeniami ze strony biznesu, kiedy zaczyna się mówić w kategoriach zapytań boolean, zapytań funkcyjnych i innych.
Mój główny wniosek jest taki, że jestem entuzjastycznie nastawiony do Algolii w przypadku odpowiednich przypadków użycia. Ale musisz być pewien, że spełni ona twoje potrzeby. Mam nadzieję, że dzięki temu stałeś się bardziej świadomym klientem.