Imagine o caso de uso:
- Muitos (100+) pequenos índices de pesquisa (10Mb-100Mb, 1000-100000 documentos).
- Eles estão usando muitos aplicativos (microsserviços)
- Cada aplicativo pode usar mais de um índice
- Pequeno por índice de tamanho, sim. Mas uma carga enorme (centenas de solicitações de pesquisa por segundo) e solicitações são complexas (várias agregações, condições e assim por diante)
- Não são permitidos períodos de inatividade
- Tudo isso dura anos e cresce constantemente.
A ideia de ter uma instância individual do ES para cada índice - é uma enorme sobrecarga nesse caso.
Com base na minha experiência, esse tipo de caso de uso é muito complexo para oferecer suporte no Elasticsearch.
Por quê?
PRIMEIRO.
O principal problema é o desconhecimento fundamental da compatibilidade com as costas.
Quebrar mudanças são tão legais! (Nota: imagine o servidor SQL, que exige que você faça pequenas alterações em todas as suas instruções SQL, quando atualizadas ... não pode imaginar. Mas para o ES é normal)
As preterições que serão lançadas no próximo grande lançamento são muito sexy! (Nota: você sabe, Java contém algumas preterições, com mais de 20 anos, mas ainda trabalhando na versão Java real ...)
E não é só isso, às vezes você ainda tem algo que não foi documentado em nenhum lugar (pessoalmente só me deparei uma vez, mas ...)
Assim. Se você deseja atualizar o ES (porque precisa de novos recursos para algum aplicativo ou deseja obter correções de bugs) - você está no inferno. Especialmente se for sobre atualização de versão principal.
A API do cliente não será compatível. As configurações do índice não serão compatíveis. E atualizar todos os aplicativos / serviços no mesmo momento com a atualização do ES não é realista.
Mas você deve fazê-lo de tempos em tempos. Não há outro jeito.
Os índices existentes são atualizados automaticamente? - Sim. Mas isso não ajuda quando é necessário alterar algumas configurações do índice antigo.
Para viver com isso, você precisa investir constantemente muito poder em ... compatibilidade futura de seus aplicativos / serviços com versões futuras do ES. Ou você precisa criar (e de qualquer maneira suportar constantemente) algum tipo de middleware entre seu aplicativo / serviços e o ES, que fornece uma API de cliente compatível. (E você não pode usar o Transport Client (porque exigia a atualização do jar para todas as atualizações secundárias do ES), e esse fato não facilita a sua vida)
Parece simples e barato? Não, não é. Longe disso. A manutenção contínua de infraestrutura complexa, baseada no ES, é muito cara em todos os sentidos possíveis.
SEGUNDO. API simples? Bem ... não mesmo. Quando você realmente está usando condições e agregações complexas ... A solicitação JSON com 5 níveis aninhados é o que for, mas não é simples.
Infelizmente, não tenho experiência com SOLR, não posso dizer nada sobre isso.
Mas o Sphinxsearch é muito melhor nesse cenário, devido ao SphinxQL totalmente compatível com as versões anteriores.
Nota: Sphinxsearch / Manticore são realmente interessantes. Não é baseado em Lucine e, como resultado, seriamente diferente. Contém vários recursos exclusivos da caixa que o ES não possui e malucos rapidamente com índices de tamanho pequeno / médio.
