elasticsearch v. S. MongoDB for filtering application [closed]
A minha aplicação gira em torno da selecção de objectos de acordo com os critérios. Ele selecionaria objetos filtrando simultaneamente por mais de um único campo, colocando de forma diferente, seus critérios de Filtragem de consulta normalmente compreenderiam em qualquer lugar 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 poucos campos fora desses 20 campos globais (pode ser menos ou mais do que 20 nomes de campos globais existentes, eu apenas usei este número para demonstrar a razão de campos para campos usados como filtros em cada consulta discreta). A filtragem pode ser pela existência dos campos escolhidos, bem como pelos valores dos campos, por exemplo, filtrando objetos que têm o campo A, e seu campo B está entre x e y, e seu campo C é igual a W.
A minha aplicação vai continuar a fazer este tipo de filtragem., enquanto que não haveria nada ou muito pouco constante em termos de quais campos são usados para a filtragem a qualquer momento. Talvez em índices elasticsearch precisam ser definidos, mas talvez mesmo sem índices a velocidade é igual à do MongoDB. De acordo com os dados que entram na loja, não há detalhes especiais sobre isso.. os objetos quase nunca seriam alterados depois de terem sido inseridos. Talvez os objectos antigos precisassem de ser largados, eu gostaria de assumir que ambos os suportes de armazenamento de dados expirar a remoção de coisas internamente ou por uma pesquisa feita por aplicação. (Menos frequentemente, objetos que se encaixam em uma determinada consulta precisariam ser descartados também). O que achas? E já experimentou este aspecto?Estou interessado no desempenho e na escalabilidade dele, de cada uma das duas lojas de dados, para este tipo de tarefa. Este é o tipo de uma questão de desing arquitetônico, e detalhes de opções específicas de loja ou pilares de consulta que devem torná-lo bem arquitectados são bem-vindos como uma demonstração de uma sugestão totalmente pensada.
Obrigado!1 answers
Em primeiro lugar, há uma distinção importante a fazer aqui: MongoDB é um banco de dados de propósito geral, Elasticsearch é um motor de busca de texto distribuído apoiado por Lucene. As pessoas têm falado sobre o uso da Elasticsearch como um banco de dados de propósito geral, mas sabem que não era o seu "design original". Penso que as bases de dados NoSQL de propósito geral e os motores de busca estão a caminho da consolidação, mas, tal como está, os dois vêm de dois campos muito diferentes.
Estamos a usar os dois MongoDB. e pesquisa elastica na minha companhia. Nós armazenamos nossos dados em MongoDB e usamos Elasticsearch exclusivamente para suas capacidades de pesquisa de texto completo. Nós só enviamos um subconjunto dos campos de dados mongo que precisamos consultar para elástico. O nosso caso de uso difere do seu porque os nossos dados Mongo mudam o tempo todo: um registro, ou um subconjunto dos campos de um registro, pode ser atualizado várias vezes por dia e isso pode exigir a re-indexação desse registro para elástico. Só por essa razão, usando elástico como única data store não é uma boa opção para nós, já que não podemos atualizar campos selecionados; precisaríamos re-indexar um documento na sua totalidade. Esta não é uma limitação elástica, é assim que Lucene funciona, o motor de busca subjacente por trás elástico. No seu caso, o fato de que os registros não serão alterados uma vez armazenados salva você de ter que fazer essa escolha. Dito isto, se a segurança dos dados é uma preocupação, eu pensaria duas vezes sobre a utilização Elasticsearch como o único mecanismo de armazenamento para os seus dados. Pode chegar lá em algum ponto, mas ainda não sei se está lá.Em termos de velocidade, não só é Elástica/Lucene em pé de igualdade com a consultar velocidade de Mongo, no seu caso, onde há "muito pouco constante em termos de quais os campos que são usados para a filtragem, a qualquer momento", pode ser ordens de magnitude mais rápido, especialmente como os conjuntos de dados se tornam maiores. A diferença reside nas implementações de consulta subjacentes:
- elástico / Luceno usar o modelo de espaço vetorial e invertido índices para recuperação de informação , que são formas altamente eficientes de comparar a semelhança de registo com uma consulta. Quando você consulta Elastic / Lucene, ele já sabe a resposta; a maior parte do seu trabalho está em classificar os resultados para você pelos mais prováveis para corresponder os Termos de sua consulta. Este é um ponto importante: os motores de busca, ao contrário das bases de dados, não podem garantir resultados exatos; eles classificam os resultados por quão perto eles chegam à sua consulta. Acontece que a maioria dos por vezes, os resultados estão perto do EXACTO. A abordagem de Mongo é a de um armazenamento de dados de finalidade mais geral; compara os documentos JSON uns com os outros. Você pode obter um ótimo desempenho fora dele por todos os meios, mas você precisa criar cuidadosamente seus índices para corresponder às consultas que você estará executando. Especificamente, se tiver vários campos pelos quais irá consultar, terá de criar cuidadosamente as suas teclas compostas de modo a que reduzam o conjunto de dados que será questionado tão rapidamente quanto possível. possivel. Por exemplo, a sua primeira chave deve filtrar a maior parte do seu conjunto de dados, o seu segundo deve filtrar ainda mais o que sobrou, e assim por diante. Se as suas consultas não coincidirem com as chaves e a ordem dessas chaves nos índices definidos, o seu desempenho irá cair bastante. Por outro lado, Mongo é um banco de dados verdadeiro, então, se a precisão é o que você precisa, as respostas que ele vai dar será spot on.
Para expirar discos antigos, Elastic tem uma característica TTL construída. Mongo ... introduziu - o a partir da versão 2.2, penso eu.
Uma vez que não conheço os teus outros requisitos, como o tamanho esperado dos dados, as transacções, a precisão ou como os teus filtros vão parecer, é difícil fazer recomendações específicas. Espero que haja aqui o suficiente para começar.