Poisas sobre Algolia (vs Solr & Elasticsearch)
1 de junho, 2016 Doug Turnbull Categoria: Lucene
Após ficar rabugento num post do blog Algolia, e tendo um episódio de Search Disco com Julien Lemoine CTO da Algolia, fico fascinado com a solução.
Algolia, tão quente agora!
Algolia pressupõe que todos vamos querer uma pesquisa instantânea (também conhecida como search-as-you-type). Então eles construíram uma pesquisa instantânea extremamente boa, hospedada. Tudo o que você quer fazer com a busca instantânea está lá. Basta ler este post incrível sobre o entendimento da consulta
- Tolerância ao typo, “Doug Trunbull”
- Prefixo de busca “Doug Turn”
- Prefixo com tolerância ao typo “Doug Trun”
- Decompounding (às vezes isso pode ser tolerância ao typo) DougTrun
- Um lematizer de consulta, e mais…
É como se em vez de procurar, você tivesse autocompletar em esteróides. Junte isso com a classificação padrão mais sã do que Elasticsearch ou Solr, e você fica com um produto bem atraente.
Eu digo tudo isso como um Lucenista bem raivoso. Eu escrevi um livro sobre Relevância em Lucene. Estou muito inclinado para Lucene, pois vi muitas soluções convincentes construídas com Solr e Elasticsearch também.
Uma coisa que aprendi sobre a pesquisa baseada em Lucene é que você pode, com uma boa equipe, construir praticamente qualquer coisa de pesquisa com ele. No entanto, é preciso uma equipa. A pesquisa baseada em Lucena não é realmente destinada a funcionar bem “fora da caixa” para a sua solução. Independentemente da facilidade com que a Elasticsearch o fez, a pesquisa baseada em Lucena é uma estrutura, não uma solução. É um conjunto de estruturas de dados realmente fantásticas, focadas na pesquisa, que você pode juntar de forma relativamente fácil para fazer o seu Thing™. Mesmo que o seu Thing™ signifique alterar detalhes tão baixos como a forma como o índice é armazenado no disco!
Outra forma de dizer que você poderia construir Algolia no Elasticsearch (ou chegar perto o suficiente). Você não pode construir o Elasticsearch em Algolia. Você ganha com o foco da Algolia em um problema específico. Você sacrifica uma profunda personalização e extensibilidade do código aberto. Mais uma maneira de dizer é comparar soluções de busca com aplicações web. De muitas maneiras a Algolia é como construir um site com um construtor de sites como o Wix. Lucene é mais como construir seu próprio aplicativo web com desenvolvedores por trás dele, e todas as considerações de baixo nível associadas, aborrecimentos, mas também power.
Case em questão é a comparação de desempenho do Algolia com Elasticsearch. Nos testes da Algolia, a Algolia alega até 200x de melhoria de desempenho. Em média, há mais de 10-20x de melhoria de desempenho (ainda impressionante). No entanto, a Algolia escolheu o menor denominador comum na pesquisa instantânea em Elasticsearch: consultas fuzzy e consultas de prefixo. Como está escrito em Elasticsearch: O Guia Definitivo outra abordagem comum que melhora tremendamente a velocidade é o uso de ngrams. Basicamente, evite o trabalho fuzzy de consulta e construa uma estrutura de dados gigante que possa lidar com ela.
Agora os ngrams têm seus próprios problemas. Eles fazem crescer o seu índice. No entanto, no caso de 2 milhões de documentos com muito texto curto, pode não inchar muito o índice. E eu suspeito que teria melhorias de ordem de magnitude no desempenho. Se um índice inchado se tornasse um problema, poderíamos produzir menos ngramas de tamanho maior. Há também o cache a considerar: Aposto que ambas as soluções têm resultados de cache para cada consulta de teclas. Então eu me pergunto como isso colore a consideração Algolia vs ES.
Podemos até inverter termos colocados no índice para obter consultas de sufixos para pegar erros de digitação anteriores. Ou fazer coisas exóticas com consultas fuzzy e ngrams simultaneamente. Poderemos até escrever uma consulta Lucene que se concentre em erros de digitação. Veja todo o poder aqui!
O ponto é que eu fiz você começar a pensar sobre como você resolveria o problema. A Algolia já construiu uma solução! Porque não correr com a deles? Bem, há um par de reservas que eu teria que ter ido inteiro-hog para o campo Algolia:
- Turn-key pode muitas vezes transformar-se em lock-in. Há exemplos de soluções de busca hospedadas (e bancos de dados sendo adquiridos e o novo dono (no caso da FoundationDB Apple) não estando interessado em apoiar o negócio existente.
- Você se preocupa com “coisas não cordas”. A solução da Algolia concentra-se fortemente na correspondência específica de strings. A abordagem da Lucene à relevância foca mais abstratamente em termos como características de conteúdo, usando TF*IDF como um sistema de similaridade de características (nosso livro discute amplamente a relevância nestes termos).
- Você está fazendo qualquer coisa próxima a não tradicional. Você tem uma linguagem de consulta específica para implementar. Você precisa mapear explicitamente os vernáculos entre especialistas e leigos. Você quer fazer aprender a classificar. Você quer fazer uso de vocabulários controlados, construir pesquisas semânticas. Você tem preocupações específicas com Geo. Todas estas são características que você pode construir em Solr/ES e você está preso no que Algolia lhe dá.
- Você quer manipular profundamente o comportamento do motor de busca. Esta é uma grande parte do ponto doce da Lucene.
Mas há um par de razões que eu consideraria fortemente Algolia
- Você tem uma equipe pequena, mas uma boa busca é importante. A Algolia trabalha muito bem fora da caixa. Tem um bom nível de configurabilidade de ranking que pode incluir tanto texto como valores numéricos como popularidade com algum suporte geo.
- Precisa principalmente de suportar pesquisas com um único item. A abordagem da Algolia é ideal para casos como a necessidade de procurar “banana” e combinar em bananas. A Algolia pode não fazer sentido para usuários que digitam “minion fruit” e esperam bananas.
- Você precisa suportar typos. Soluções Lucene para isto são embaraçosas. Espero que elas fiquem melhores e mais rápidas, mas a procura difusa não é o ponto doce da Lucene.
Algolia tem algumas peças de marketing que eu discordaria:
- Algolia gosta de apontar que hospedar Elasticsearch vai ser difícil. Eu acho que com opções como Bonsai e Elastic Cloud, este dificilmente é o caso. Com um bom host ES, você basicamente tem uma boa “API na nuvem” que é tão fácil de trabalhar como qualquer outro serviço.
- Algolia quer que você acredite que Elasticsearch não é um bom mecanismo de busca. Só é bom em grande análise de dados e “grande busca de dados” (não tenho certeza do que isso significa). No espírito de encontrar “coisas que não cordas” eu discordaria. Basta trabalhar e entender o que há de especial na sua solução de busca.
- Algolia espera que tudo se torne uma busca instantânea. No entanto, na minha experiência, a preponderância das experiências de busca (mesmo muitas conduzidas por Algolia) são autocompletas primeiro para selecionar palavras-chave, e depois a busca por palavras-chave. Isto ainda está no ponto doce da Lucene para busca.
- Eu acredito que as referências que Algolia fornece, mas é notado que eles não tentam estratégias de busca instantânea mais rápida em Elasticsearch. Nós próprios não podemos recriar os seus pontos de referência. Algolia parece ser confiável, mas eu gostaria de poder testar isso independentemente. Eu também gostaria de vê-los correr novamente contra novas versões do Elasticsearch.
Mas Algolia aponta importantes fraquezas no modelo de relevância da Lucene
- Tipos e correspondência fuzzy: Na medida em que o mundo quer busca instantânea com tolerância a erros de digitação, a busca baseada na Lucene é difícil de se fazer funcionar. Eu também acredito que é mais lento que a solução focada da Algolia (embora eu não consiga recriar os benchmarks).
- Elasticsearch/Solr defaults for relevance are hard to tune. Como Algolia corretamente aponta, a função de classificação dismax produz resultados bastante confusos. Nós escrevemos sobre esse fenômeno aqui. Você pode e deve se afastar desses padrões, mas eu gostaria que a busca fizesse mais sentido fora da caixa.
- Elasticsearch e Solr primitivos para relevância sentem-se de baixo nível. Algolia se sente de nível mais alto e mais focada na criação de um entendimento comum entre o negócio e os desenvolvedores. Esta é uma grande razão pela qual construímos o Quepid. Mesmo assim, com todas as opções em Solr/ES você ainda terá olhares em branco do negócio quando você começar a falar em termos de consultas booleanas, consultas de funções, e what-not.
Meu grande takeaway é na verdade eu estou bastante entusiasmado com Algolia para os casos de uso certo. Mas você precisa ter certeza de que ele irá satisfazer suas necessidades. Espero que isto o tenha tornado um comprador mais informado.