mongoosastic - elasticsearch vs MongoDB para la aplicación de filtrado

kibana mongodb

Question

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

Hipotéticamente ambos almacenan objetos de datos que tienen campos y valores, y permiten consultar ese cuerpo de objetos. Así que, presumiblemente, filtrar subconjuntos de los objetos de acuerdo con 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 filtrando simultáneamente por más de un solo campo, puesto de manera diferente, sus criterios de filtrado de consultas típicamente 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 en general (puede haber menos o más de 20 nombres de campo en general existentes, acabo de usar este número para demostrar la proporción de campos a campos usados ​​como filtros en cada consulta discreta). El filtrado puede ser por la existencia de los campos elegidos, así como por los valores de campo, por ejemplo, filtrando los objetos que tienen el campo A, y su campo B está entre xey, y su campo C es igual a w.

Mi aplicación realizará continuamente este tipo de filtrado, mientras que no habrá nada o muy poco constante en términos de qué campos se utilizan para el filtrado en cualquier momento. Tal vez en los índices de búsqueda elástica se deba definir, pero quizás incluso sin índices, la velocidad es similar a la de MongoDB.

Según los datos que entran a la tienda, no hay detalles especiales sobre eso ... los objetos casi nunca se cambiarían después de haber sido insertados. Quizás los objetos antiguos deban descartarse, me gustaría suponer que ambos almacenes de datos soportan la expiración de eliminar cosas internamente o mediante una consulta hecha por la aplicación. (Con menos frecuencia, los objetos que se ajustan a una determinada consulta también deberían descartarse).

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

Estoy interesado en el rendimiento y la escalabilidad de este, 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 la consulta que deberían hacerlo bien estructurado son bienvenidos como una demostración de una sugerencia completamente pensada.

¡Gracias!

Answer 1

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 saben que no fue su diseño original. Creo que las bases de datos y los motores de búsqueda NoSQL de propósito general se dirigen a la consolidación, pero tal como están las cosas, los dos provienen de dos campos muy diferentes.

Estamos usando MongoDB y Elasticsearch en mi compañía. Almacenamos nuestros datos en MongoDB y usamos 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 al elástico. 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 una nueva indexación de ese registro en elástico. Solo por esa razón, usar elástico como el único almacén de datos no es una buena opción para nosotros, ya que no podemos actualizar los campos seleccionados; Tendríamos que volver a indexar un documento en su totalidad. Esta 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 no se modifiquen una vez guardados le evita tener que tomar esa decisión. Habiendo dicho eso, si la seguridad de los datos es una preocupación, 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 usan para filtrar en cualquier momento", podrían ser órdenes de magnitud más rápido, especialmente a medida que los conjuntos de datos se vuelven más grandes. La diferencia radica en las implementaciones de consulta subyacentes:

• Elástico / Lucene utiliza el Modelo de espacio vectorial e índices invertidos para la Recuperación de información , que son formas altamente eficientes de comparar la similitud de registros con una consulta. Cuando consulta Elastic / Lucene, ya conoce la respuesta; la mayor parte de su trabajo consiste en clasificar los resultados para usted por los más probables para que coincidan con sus términos de 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 por lo cerca que llegan a su consulta. Simplemente 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 documentos JSON uno contra el otro. Puede obtener un gran rendimiento de todos modos, pero debe crear cuidadosamente los índices para que coincidan con las consultas que ejecutará. Específicamente, si tiene varios campos por los cuales consultará, debe crear cuidadosamente sus claves compuestas para que reduzcan el conjunto de datos que se consultarán lo más rápido posible. Por ejemplo, su primera clave debería filtrar la mayoría de su conjunto de datos, su segundo debería filtrar aún más lo que queda, y así sucesivamente. Si sus consultas no coinciden con las claves y el orden de esas teclas en los índices definidos, su rendimiento disminuirá bastante. Por otro lado, Mongo es una verdadera base de datos, así que si la precisión es lo que necesita, las respuestas que dará serán acertadas.

Para caducar los registros antiguos, Elastic tiene una característica integrada TTL. Mongo acaba de presentarlo a partir de la versión 2.2, creo.

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