elasticsearch v. s. MongoDB para aplicación de filtrado [cerrado]

Question

elasticsearch v. s. MongoDB para aplicación de filtrado [cerrado]

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 v. s. 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. 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 criterios. Seleccionaría objetos filtrando simultáneamente por más de un solo campo, dicho de otra manera, sus criterios de filtrado de consultas normalmente 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 campos existentes, y cada consulta es un intento de filtrar los objetos por unos pocos campos de esos 20 campos totales (Puede ser menos o más de 20 nombres de campo totales 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 campo, por ejemplo, filtrar objetos que tienen campo A, y su campo B está entre x e y, y su campo C es igual a w.

Mi aplicación estará continuamente haciendo 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. Tal vez en elasticsearch los índices necesitan ser definidos, pero tal vez incluso sin índices la velocidad está a la par con la de MongoDB.

Según los datos que entran en la tienda, no hay detalles especiales sobre eso.. los objetos casi nunca se cambiarían después de haber sido insertados. Tal vez los objetos antiguos tendrían que ser eliminados, me gustaría asumir que ambos almacenes de datos soportan expirar eliminar cosas internamente o mediante una consulta realizada por una aplicación. (Con menos frecuencia, los objetos que se ajustan a una determinada consulta también tendrían que ser eliminados).

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

Me interesa el rendimiento y la escalabilidad del mismo, de cada uno de los dos almacenes de datos, para este tipo de tareas. 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 arquitectónico son bienvenido como una demostración de una sugerencia completamente pensada.

Gracias!

116

elasticsearch mongodb

Author: matanster, 2012-10-04

Source

1 answers

score 291 · Accepted Answer

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

Estamos usando 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, se puede actualizar varias veces al día y esto puede requerir la reindexación de ese registro a elastic. Por esa sola razón, el uso de elastic como único almacén de datos es 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. Esto no es una limitación elástica, así es como funciona Lucene, el motor de búsqueda subyacente detrás de elastic. En su caso, el hecho de que los registros no se cambiarán una vez almacenados le evita tener que tomar esa decisión. Dicho esto, 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é ahí 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ía 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 consultas subyacentes:

Elastic / Lucene utilice el Modelo de Espacio Vectorial y los índices invertidos para 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 radica en clasificar los resultados por usted por 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 garantizar resultados exactos; clasifican los resultados por lo cerca que están de tu consulta. Sucede que la mayoría de las veces, los resultados son casi exacto.
El enfoque de Mongo es el de un almacén de datos de propósito más general; compara documentos JSON entre sí. Puede obtener un gran rendimiento de él por todos los medios, pero necesita crear cuidadosamente sus índices para que coincidan con las consultas que ejecutará. Específicamente, si tiene varios campos por los que consultará, debe crear cuidadosamente sus claves compuestas para que reduzcan el conjunto de datos que se consultará lo más rápido posible. Por ejemplo, su primera llave debe filtrar la mayor parte de su conjunto de datos, su segundo 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 expiran, Elastic tiene una característica TTL incorporada. Mongo acaba de presentarlo como versión 2.2 creo.

Dado que no conozco sus otros requisitos, como el tamaño de los datos esperados, las transacciones, la precisión o cómo se verán sus filtros, es difícil hacer recomendaciones específicas. Con suerte, hay suficiente aquí para empezar.