Esta questão é sobre como fazer uma escolha arquitetônica antes de investigar os detalhes de experimentação e implementação. É sobre a adequação, em termos de escalabilidade e desempenho, de elasticsearch v.s. MongoDB, para um propósito um pouco específico.

Hipoteticamente, armazene objetos de dados que tenham campos e valores e permita a consulta desse corpo de objetos. Então, presumivelmente filtrar subconjuntos dos objetos de acordo com campos selecionados ad-hoc, é algo adequado para ambos.

Meu aplicativo vai girar em torno de selecionar objetos de acordo com critérios. Ele selecionaria objetos ao filtrar simultaneamente por mais de um único campo, e, diferentemente, seus critérios de filtragem de consulta normalmente incluiriam entre 1 e 5 campos, talvez mais em alguns casos. Considerando que 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 fora dos 20 campos em geral (pode ser menor ou mais de 20 nomes de campo existentes, eu usei esse número para demonstrar a proporção de campos para campos usados ​​como filtros em todas as consultas discretas). A filtragem pode ser pela existência dos campos escolhidos, bem como pelos valores do campo, e. filtrando objetos que possuem campo A, e seu campo B está entre x e y, e seu campo C é igual a w.

Meu aplicativo estará continuamente 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 em elasticsearch os índices precisem ser definidos, mas talvez, mesmo sem índices, a velocidade seja equivalente à 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 inseridos. Talvez objetos antigos precisem ser descartados, eu gostaria de supor que ambos os armazenamentos de dados suportam expirar a exclusão de material internamente ou por uma consulta feita pelo aplicativo. (Menos frequentemente, objetos que se encaixam em uma determinada consulta precisariam ser descartados também).

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

Estou interessado no desempenho e na escalabilidade de cada um dos dois armazenamentos de dados para esse tipo de tarefa. Este é o tipo de questão de desenho arquitetônico, e detalhes de opções específicas de lojas ou pilares de consulta que devem torná-lo bem arquitetado são bem-vindos como uma demonstração de uma sugestão totalmente pensada.

Obrigado!