elasticsearch vs MongoDB para la aplicación de filtrado [cerrado]

Esta pregunta se trata de hacer una elección arquitectónica antes de profundizar en los detalles de experimentación e implementación. Se trata de la idoneidad, en términos de escalabilidad y rendimiento, de elasticsearch vs MongoDB, para un propósito algo específico.

Hipotéticamente, ambos almacenan objetos de datos que tienen campos y valores, y permiten consultar ese cuerpo de objetos. Por lo tanto, presumiblemente filtrar subconjuntos de objetos según los campos seleccionados ad-hoc, es algo adecuado para ambos.

Mi aplicación girará en torno a la selección de objetos según los criterios. Seleccionaría objetos mediante el filtrado simultáneo de más de un campo, dicho de otro modo, sus criterios de filtrado de consultas generalmente comprenderían entre 1 y 5 campos, tal vez más en algunos casos. Mientras que los campos elegidos como filtros serían un subconjunto de una cantidad mucho mayor de campos. Imagine unos 20 nombres de campo existentes, y cada consulta es un intento de filtrar los objetos por unos pocos campos de esos 20 campos generales (puede haber menos o más de 20 nombres de campo generales existentes, solo utilicé este número para demostrar la proporción de campos a campos utilizados como filtros en cada consulta discreta). El filtrado puede ser por la existencia de los campos elegidos, así como por los valores de los campos, por ejemplo, filtrando objetos que tienen el campo A, y su campo B está entre x e y,

Mi aplicación realizará continuamente este tipo de filtrado, mientras que no habría nada o muy poca constante en términos de qué campos se utilizan para el filtrado en cualquier momento. Quizás en Elasticsearch se necesiten definir índices, pero quizás incluso sin índices la velocidad esté a la par con la de MongoDB.

Según los datos que ingresan a la tienda, no hay detalles especiales sobre eso ... los objetos casi nunca cambiarían después de haber sido insertados. Tal vez los objetos antiguos tendrían que descartarse, me gustaría asumir que el soporte de ambos almacenes de datos caduca eliminando cosas internamente o mediante una consulta realizada por la aplicación. (Con menos frecuencia, los objetos que se ajustan a una determinada consulta también deberían eliminarse).

¿Qué piensas? Y, ¿has experimentado este aspecto?

Estoy interesado en el rendimiento y la escalabilidad del mismo, de cada uno de los dos almacenes de datos, para este tipo de tarea. Este es el tipo de pregunta de diseño arquitectónico, y los detalles de las opciones específicas de la tienda o las piedras angulares de consulta que deberían hacerlo bien estructurado son bienvenidos como una demostración de una sugerencia completamente pensada.

¡Gracias!

En primer lugar, hay una distinción importante que hacer aquí: MongoDB es una base de datos de propósito general, Elasticsearch es un motor de búsqueda de texto distribuido respaldado por Lucene. La gente ha estado hablando sobre el uso de Elasticsearch como una base de datos de propósito general, pero sabe que no fue su diseño original. Creo que las bases de datos NoSQL de uso general y los motores de búsqueda se dirigen a la consolidación, pero tal como están, los dos provienen de dos campos muy diferentes.

Estamos utilizando MongoDB y Elasticsearch en mi empresa. Almacenamos nuestros datos en MongoDB y utilizamos Elasticsearch exclusivamente para sus capacidades de búsqueda de texto completo. Solo enviamos un subconjunto de los campos de datos de mongo que necesitamos consultar a elastic. Nuestro caso de uso difiere del suyo en que nuestros datos de Mongo cambian todo el tiempo: un registro, o un subconjunto de los campos de un registro, puede actualizarse varias veces al día y esto puede requerir la reindexación de ese registro a elástico. Solo por esa razón, usar Elastic como el único almacén de datos no es una buena opción para nosotros, ya que no podemos actualizar los campos de selección; necesitaríamos volver a indexar un documento en su totalidad. Esto no es una limitación elástica, así es como funciona Lucene, el motor de búsqueda subyacente detrás del elástico. En su caso, el hecho de que los registros ganaron ' Si se cambia una vez almacenado, no tendrá que tomar esa decisión. Dicho esto, si la seguridad de los datos es una preocupación, me lo pensaría dos veces antes de usar Elasticsearch como el único mecanismo de almacenamiento para sus datos. Puede llegar allí en algún momento, pero no estoy seguro de que esté allí todavía.

En términos de velocidad, Elastic / Lucene no solo está a la par con la velocidad de consulta de Mongo, en su caso donde hay "muy poca constante en términos de qué campos se utilizan para el filtrado en cualquier momento", podrían ser órdenes de magnitud más rápido, especialmente a medida que los conjuntos de datos se hacen más grandes. La diferencia radica en las implementaciones de consulta subyacentes:

• Elastic / Lucene utiliza el modelo de espacio vectorial y los índices invertidos para la recuperación de información , que son formas muy eficientes de comparar la similitud de registros con una consulta. Cuando consulta Elastic / Lucene, ya sabe la respuesta; la mayor parte de su trabajo radica en clasificar los resultados para usted según los más probables para que coincidan con los términos de su consulta. Este es un punto importante: los motores de búsqueda, a diferencia de las bases de datos, no pueden garantizarle resultados exactos; clasifican los resultados según la proximidad a su consulta. Sucede que la mayoría de las veces, los resultados son casi exactos.
• El enfoque de Mongo es el de un almacén de datos de propósito más general; compara los documentos JSON entre sí. Puede obtener un excelente rendimiento de todos los medios, pero debe elaborar cuidadosamente sus índices para que coincidan con las consultas que ejecutará. Específicamente, si tiene varios campos por los cuales consultará, debe elaborar cuidadosamente sus claves compuestaspara que reduzcan el conjunto de datos que se consultará lo más rápido posible. Por ejemplo, su primera clave debe filtrar la mayoría de su conjunto de datos, la segunda debe filtrar aún más lo que queda, y así sucesivamente. Si sus consultas no coinciden con las claves y el orden de esas claves en los índices definidos, su rendimiento disminuirá bastante. Por otro lado, Mongo es una verdadera base de datos, por lo que si la precisión es lo que necesita, las respuestas que dará serán acertadas.

Para los registros antiguos que caducan, Elastic tiene una función TTL integrada. Mongo acaba de presentarlo a partir de la versión 2.2, creo.

Como no conozco sus otros requisitos, como el tamaño de datos esperado, las transacciones, la precisión o el aspecto que tendrán sus filtros, es difícil hacer recomendaciones específicas. Con suerte, hay suficiente aquí para comenzar.