elasticsearch vs MongoDB para aplicação de filtragem [fechado]

Esta questão é sobre como fazer uma escolha arquitetônica antes de se aprofundar nos detalhes da experimentação e implementação. Trata-se da adequação, em termos de escalabilidade e desempenho, da elasticsearch vs MongoDB, para uma finalidade específica.

Hipoteticamente, ambos armazenam objetos de dados que possuem campos e valores e permitem consultar esse corpo de objetos. Portanto, presumivelmente filtrar subconjuntos de objetos de acordo com os campos selecionados ad-hoc, é algo adequado para ambos.

Meu aplicativo girará em torno da seleção de objetos de acordo com os critérios. Ele selecionaria objetos filtrando simultaneamente por mais de um único campo; em outras palavras, seus critérios de filtragem de consultas normalmente compreendiam entre 1 e 5 campos, talvez mais em alguns casos. Enquanto os campos escolhidos como filtros seriam um subconjunto de uma quantidade muito maior de campos. Imagine cerca de 20 nomes de campos existentes e cada consulta é uma tentativa de filtrar os objetos por alguns campos dentre esses 20 campos gerais (pode haver menos ou mais de 20 nomes de campos gerais existentes, apenas usei esse número para demonstrar a proporção de campos para campos usados ​​como filtros em todas as consultas discretas). A filtragem pode ocorrer pela existência dos campos escolhidos, bem como pelos valores dos campos, por exemplo, filtrando objetos que possuem o campo A e seu campo B está entre x e y,

Meu aplicativo continuará fazendo esse tipo de filtragem, enquanto não haveria nada ou muito pouca constante em termos de quais campos são usados ​​para a filtragem a qualquer momento. Talvez nos índices de pesquisa elástica precisem ser definidos, mas talvez mesmo sem a velocidade dos índices esteja a par com a do MongoDB.

Conforme os dados que entram na loja, não há detalhes especiais sobre isso. Os objetos quase nunca eram alterados após serem inseridos. Talvez os objetos antigos precisem ser descartados, eu gostaria de assumir que os dois armazenamentos de dados expiram, excluindo itens internamente ou por uma consulta feita pelo aplicativo. (Com menos frequência, os objetos que se encaixam em uma determinada consulta também precisariam ser descartados).

O que você acha? E você já experimentou esse aspecto?

Estou interessado no desempenho e na escalabilidade dele, de cada um dos dois armazenamentos de dados, para esse tipo de tarefa. Esse é o tipo de questão de arquitetura e detalhes de opções específicas da loja ou pedras angulares de consulta que devem torná-la bem arquitetada são bem-vindos como demonstração de uma sugestão totalmente pensada.

Obrigado!

Primeiro, 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 seu design original. Eu acho que os bancos de dados NoSQL de uso geral e os mecanismos de busca estão destinados à consolidação, mas, como estão, os dois vêm de dois campos muito diferentes.

Estamos usando o MongoDB e o Elasticsearch na minha empresa. Armazenamos nossos dados no MongoDB e usamos o Elasticsearch exclusivamente para seus recursos de pesquisa de texto completo. Nós enviamos apenas um subconjunto dos campos de dados do mongo que precisamos consultar para 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 elástico. Por esse motivo, usar elástico como único repositório de dados não é uma boa opção para nós, pois não podemos atualizar campos selecionados; precisaríamos reindexar um documento na sua totalidade. Esta não é uma limitação elástica, é assim que o Lucene funciona, o mecanismo de pesquisa subjacente à elástica. No seu caso, o fato de os registros ganharem ' ser alterado depois de armazenado, evita que você faça essa escolha. Dito isto, se a segurança dos dados for uma preocupação, eu pensaria duas vezes em usar o Elasticsearch como o único mecanismo de armazenamento para seus dados. Pode chegar lá em algum momento, mas ainda não tenho certeza.

Em termos de velocidade, Elastic / Lucene não apenas é parecido com a velocidade de consulta do Mongo, no seu caso em que há "muito pouca constante em termos de quais campos são usados ​​para a filtragem a qualquer momento", pode haver ordens de magnitude mais rapidamente, especialmente quando os conjuntos de dados se tornam maiores. A diferença está nas implementações de consulta subjacentes:

• Elastic / Lucene usa o Modelo de espaço vetorial e índices invertidos para recuperação de informações , que são maneiras 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 do seu trabalho consiste em classificar os resultados para você pelos mais prováveis ​​de corresponder aos termos da sua consulta. Esse é um ponto importante: os mecanismos de pesquisa, ao contrário dos bancos de dados, não podem garantir resultados exatos; eles classificam os resultados pela distância que eles chegam à sua consulta. Acontece que, na maioria das vezes, os resultados são quase precisos.
• 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 por todos os meios, mas precisa criar cuidadosamente seus índices para corresponder às consultas que você estará executando. Especificamente, se você tiver vários campos pelos quais você consultará, precisará criar cuidadosamente suas chaves compostaspara que reduzam o conjunto de dados que será consultado o mais rápido possível. Por exemplo, sua primeira chave deve filtrar a maioria do seu conjunto de dados, sua segunda deve filtrar ainda mais o que resta, e assim por diante. Se suas consultas não coincidirem com as chaves e a ordem dessas chaves nos índices definidos, seu desempenho diminuirá bastante. Por outro lado, o Mongo é um verdadeiro banco de dados, portanto, se a precisão é o que você precisa, as respostas serão fornecidas.

Para expirar registros antigos, o Elastic possui um recurso TTL incorporado. Mongo acabou de introduzi-lo a partir da versão 2.2, eu acho.

Como não conheço seus outros requisitos, como tamanho esperado de dados, transações, precisão ou como serão os filtros, é difícil fazer recomendações específicas. Felizmente, há aqui o suficiente para você começar.