Primeiramente, há uma distinção importante a ser feita aqui:o MongoDB é um banco de dados de uso geral, o Elasticsearch é um mecanismo de pesquisa de texto distribuído apoiado pelo Lucene. As pessoas têm falado sobre o uso do Elasticsearch como um banco de dados de uso geral, mas sabem que não era o design original. Eu acho que os bancos de dados NoSQL de uso geral e os mecanismos de busca estão indo para a consolidação, mas, do jeito que está, os dois vêm de dois campos muito diferentes.
Estamos usando MongoDB e Elasticsearch na minha empresa. Armazenamos nossos dados no MongoDB e usamos o Elasticsearch exclusivamente para seus recursos de pesquisa de texto completo. Enviamos apenas um subconjunto dos campos de dados do mongo que precisamos consultar para o elastic. Nosso caso de uso difere do seu, pois nossos dados do Mongo mudam o tempo todo:um registro, ou um subconjunto dos campos de um registro, pode ser atualizado várias vezes ao dia e isso pode exigir a reindexação desse registro para elastic. Por esse motivo, usar o elastic como único armazenamento de dados não é uma boa opção para nós, pois não podemos atualizar campos selecionados; precisaríamos reindexar um documento em sua totalidade. Esta não é uma limitação elástica, é assim que funciona o Lucene, o mecanismo de busca subjacente por trás do elástico. No seu caso, o fato de os registros não serem alterados depois de armazenados evita que você tenha que fazer essa escolha. Dito isso, se a segurança dos dados for uma preocupação, eu pensaria duas vezes antes de usar o Elasticsearch como o único mecanismo de armazenamento para seus dados. Pode chegar lá em algum momento, mas não tenho certeza se ainda está lá.
Em termos de velocidade, não só o Elastic/Lucene está a par com a velocidade de consulta do Mongo, no seu caso onde há "muito pouca constante em termos de quais campos são usados para a filtragem a qualquer momento", podem ser ordens de magnitude mais rapidamente, especialmente à medida que os conjuntos de dados se tornam maiores. A diferença está nas implementações de consulta subjacentes:
- O Elastic/Lucene usa o modelo de espaço vetorial e índices invertidos para recuperação de informações, que são formas altamente eficientes de comparar a similaridade de registros com uma consulta. Quando você consulta o Elastic/Lucene, ele já sabe a resposta; a maior parte de seu trabalho está em classificar os resultados para você pelos mais prováveis de corresponder aos termos da sua consulta. Este é um ponto importante:os motores de busca, ao contrário dos bancos de dados, não podem garantir resultados exatos; eles classificam os resultados de acordo com a proximidade com a sua consulta. Acontece que, na maioria das vezes, os resultados são quase exatos.
- A abordagem do Mongo é a de um armazenamento de dados de propósito mais geral; ele compara documentos JSON entre si. Você pode obter um ótimo desempenho com todos os meios, mas precisa criar cuidadosamente seus índices para corresponder às consultas que você executará. Especificamente, se você tiver vários campos pelos quais consultará, precisará criar cuidadosamente suas chaves compostas para que reduzam o conjunto de dados que será consultado o mais rápido possível. Por exemplo. sua primeira chave deve filtrar a maior parte do seu conjunto de dados, sua segunda deve filtrar ainda mais o que resta e assim por diante. Se suas consultas não corresponderem às chaves e à ordem dessas chaves nos índices definidos, seu desempenho cairá um pouco. Por outro lado, o Mongo é um verdadeiro banco de dados, portanto, se a precisão é o que você precisa, as respostas que ele dará serão pontuais.
Para expirar registros antigos, o Elastic possui um recurso TTL integrado. O Mongo acaba de apresentá-lo a partir da versão 2.2, eu acho.
Como não conheço seus outros requisitos, como tamanho de dados esperado, transações, precisão ou a aparência de seus filtros, é difícil fazer recomendações específicas. Espero que haja o suficiente aqui para você começar.
