Esta pregunta es acerca de hacer una arquitectura elección antes de profundizar en los detalles de la experimentación y la aplicación. Es acerca de la conveniencia, en la escalabilidad y el rendimiento de los términos, de elasticsearch v. s. MongoDB, para un poco de propósito específico.

Hipotéticamente tanto para la tienda de objetos de datos que tienen campos y valores, y permitir la consulta de ese cuerpo, de los objetos. Así que, presumiblemente, el filtrado de los subconjuntos de los objetos de acuerdo a los campos seleccionados ad-hoc, es algo ajuste para ambos.

Mi aplicación giran en torno a la selección de objetos de acuerdo a criterios.
Sería seleccionar objetos mediante el filtrado simultáneamente por más de un solo campo, dicho de otra manera, su consulta criterios de filtrado normalmente comprenden en cualquier lugar entre 1 y 5 campos, tal vez más en algunos casos. Mientras que los campos elegido como filtros serían un subconjunto de una gran cantidad de campos. Imagen de algunos de los 20 nombres de campo existentes, y cada consulta es un intento de filtrar los objetos que por unos campos de aquellos general de 20 campos (puede ser menos o más de 20 en general los nombres de campo existentes, sólo utiliza este número para demostrar la relación de los campos a los campos utilizados como filtros en cada discretos de consulta). El filtrado puede ser por la existencia de los campos de especialización, así como por los valores de campo, por ejemplo, el filtrado de objetos que tienen Un campo, y su campo B es entre x e y, y su campo de C es igual a w.

Mi solicitud será continuamente haciendo este tipo de filtrado, mientras que no hay nada o muy poco constante en términos de los campos que se utilizan para la filtración en cualquier momento. Tal vez en elasticsearch índices deben ser definidos, pero incluso sin los índices de velocidad está a la par con la de MongoDB.

Según los datos de entrar en la tienda, no hay detalles acerca de eso.. los objetos sería casi nunca cambió después de haber sido insertado. Tal vez los viejos objetos tendría que ser abandonado, me gustaría asumir tanto los almacenes de datos de apoyo a caducar eliminando cosas internamente o a través de una aplicación de consulta. Menos frecuentemente, los objetos que se ajustan a una determinada consulta tendría que ser descartado también).

¿Qué te parece?
Y, ¿has experimentado este aspecto?

Estoy interesado en el rendimiento y la escalabilidad de la misma, de cada uno de los dos almacenes de datos, para este tipo de tarea. Este es el tipo de arquitectura de diseño de la pregunta, y los detalles de la tienda de opciones específicas o consulta de los pilares que debe hacer bien diseñado son bienvenidos como una manifestación de un pensamiento-hacia fuera sugerencia.

Gracias!

  • Yo no tengo ni idea de por qué esto mantiene conseguir votos, son prominentes opciones después de tanto tiempo?
  • interesante lo que elegiste hace 6 años y lo que fue su expierence hasta ahora :)?
  • ACTUALIZACIÓN – Para los curiosos, si esta respuesta es todavía relevante, MongoDB ahora tiene los índices de texto completo para proporcionar la misma funcionalidad y los beneficios como elastic search fue descrito en la respuesta seleccionada. Se almacenan como índices separados y pueden ser consultados como sea necesario, pero de no perder ninguna de las ventajas de tener un propósito general de la base de datos. He estado usando MongoDB para propósito general y para las consultas de búsqueda de texto para el año pasado y lo recomiendo. Sólo mis dos centavos.
InformationsquelleAutor matanster | 2012-10-04

1 Comentario

  1. 349

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

    Estamos utilizando tanto MongoDB y Elasticsearch en mi empresa. Tenemos que guardar nuestros datos en MongoDB y el uso de Elasticsearch exclusivamente para sus’ funciones de búsqueda de texto. Sólo enviamos un subconjunto de los mongo campos de datos que tenemos a la consulta elástica. Nuestro caso de uso difiere de la tuya en la que nuestro Mongo de datos cambia todo el tiempo: un registro, o un subconjunto de los campos de un registro, puede ser actualizado varias veces al día y esto puede llame para re-indexación de registro para elástica. Por esa sola razón, el uso de elásticos como el único almacén de datos no es una buena opción para nosotros, ya que no se puede actualizar seleccione los campos; tendríamos que volver a indizar un documento en su totalidad. Este no es un elástico limitación, esta es la forma en Lucene obras, en el motor de búsqueda detrás de la elástica. En su caso, el hecho de que los registros no pueden modificarse una vez almacenados ahorra el tener que elegir. Habiendo dicho que, si la seguridad de los datos es una preocupación, pensaría dos veces sobre el uso de Elasticsearch como el único mecanismo de almacenamiento para sus datos. Se puede llegar en algún momento, pero no estoy seguro de que es allí todavía.

    En términos de velocidad, no sólo es Elástica/Lucene a la par con la consulta de la velocidad de Mongo, en su caso, donde hay «muy poco constante en términos de los campos que se utilizan para la filtración 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 la consulta subyacente implementaciones:

    • Elástica/Lucene utilizar el Modelo De Espacio Vectorial y índices invertidos para La Recuperación De La Información, que son altamente eficientes maneras de comparar el registro de similitud en contra de una consulta. Cuando se consulta el Elástico/Lucene, que ya sabe la respuesta, la mayoría de su trabajo se encuentra en el ranking de los resultados por usted por los más probables para que coincida con los términos de consulta. Este es un punto importante: los motores de búsqueda, como contraposición a las bases de datos, no podemos garantizar que los resultados exactos; clasificar los resultados por lo cerca que llegar a su consulta. Se da la circunstancia de que la mayoría de las veces, los resultados son cercanos a exacta.
    • Mongo es que de una finalidad más general almacén de datos; compara documentos JSON uno contra el otro. Usted puede obtener un gran rendimiento de la misma por todos los medios, pero con mucho cuidado la creación de índices para que coincida con las consultas que se ejecutan. Específicamente, si usted tiene múltiples campos por los que se le consulta, se debe moldear cuidadosamente su claves compuestas por lo que pueden reducir el conjunto de datos que se consulta lo más rápido posible. E. g. su primera llave de filtro de la mayoría de su conjunto de datos, su segundo debe filtrar aún más abajo de lo que la izquierda, y así sucesivamente y así sucesivamente. Si las consultas no coinciden con las claves y el orden de las claves en su definición de índices, su rendimiento disminuirá un poco. Por otro lado, Mongo es una verdadera base de datos, por lo que si la precisión es lo que usted necesita, las respuestas va a dar va a ser el clavo.

    Para caducar viejos discos Elásticos, se ha construido en función TTL. Mongo sólo introdujo a partir de la versión 2.2, creo.

    Ya no sé sus otros requisitos, como era de esperar el tamaño de los datos, transacciones, precisión o lo que tu filtros aspecto, es difícil hacer recomendaciones específicas. Con suerte, aquí hay suficiente para empezar.

    • Solo para comentar que este es probablemente el más alto nivel de respuesta que se esperaba en una arquitectura tema en este sitio. Gracias por ser erudito, analítica, articulado, y realmente atractivo el escenario.
    • Con respecto a la exactitud, usted puede ser capaz de controlarlo con el Elástico/Lucene por la elección de cómo acortar y analizar sus campos. Si en tus campos no son analizados (es decir, roto en un espacio separado de los términos), se puede forzar el motor de búsqueda de tratarlos como-es. Entonces, si usted consulta utilizando un término de la consulta (elasticsearch.org/guide/reference/query-dsl/term-query.html) puede asegurarse de que usted consigue solamente coincidencia exacta de los resultados. Este enfoque sería similar a cómo regular DB haría una coincidencia exacta.
    • ACTUALIZACIÓN – Para los curiosos, si esta respuesta es todavía relevante, MongoDB ahora tiene los índices de texto completo para proporcionar la misma funcionalidad y los beneficios como elastic search fue descrito en la respuesta seleccionada. Se almacenan como índices separados y pueden ser consultados como sea necesario, pero de no perder ninguna de las ventajas de tener un propósito general de la base de datos. He estado usando MongoDB para propósito general y para las consultas de búsqueda de texto para el año pasado y lo recomiendo. Sólo mis dos centavos.

Dejar respuesta

Please enter your comment!
Please enter your name here