cluster - MongoDB+Elasticsearch o solo Elasticsearch?

elasticsearch vs mongodb performance

Question

Tenemos un nuevo proyecto allí para indexar una gran cantidad de datos y para proporcionar tiempo real. También he completado la búsqueda con facetas, texto completo, geoespacial ...

El primer prototipo es indexar en MongoDB y luego en Elasticsearch, porque había leído que Elasticsearch no aplica una suma de comprobación en los archivos almacenados y no se puede confiar plenamente en el índice. Pero desde las últimas versiones (en la versión 1.5), ahora hay una suma de comprobación y supongo que si podemos usar Elasticsearch como almacén de datos primario. ¿Y cuál es el beneficio de usar MongoDB además de Elasticsearch?

No puedo encontrar una respuesta actualizada sobre estas características en Elasticsearch

Muchas gracias

Answer 1

Bueno, elige la herramienta adecuada para el trabajo correcto. Si necesita funciones de búsqueda, como búsqueda de texto completo, faceting, etc., nada puede vencer a un motor de búsqueda completo. ElasticSearch (ES) o Solr es solo una cuestión de elección.

En realidad, puede alimentar (indexar) documentos en ES para buscar y luego obtener los detalles completos de una entrada particular de MongoDB o de cualquier otra base de datos.

Puedo facilitarle la tarea, eche un vistazo a mi trabajo de código abierto que utiliza MongoDB, ES, Redis y RabbitMQ, todo integrado en un solo lugar, aquí en github

Tenga en cuenta que la aplicación está integrada en .Net C #.

Answer 2

Hablando de argumentos para usar Mongo en lugar de / junto con ES:

1. Usuario / gestión de roles.

   • Incorporado en MongoDB. Puede no ajustarse a todas sus necesidades, puede ser torpe en alguna parte, pero existe y se implementó hace bastante tiempo.
   • Lo único para la seguridad en ES es shield . Pero se envía solo para la suscripción Gold / Platinum para uso de producción.

2. Esquema

   • ES no tiene esquemas, pero está construido sobre Lucene y escrito en Java . La idea central de esta herramienta, el índice y los documentos de búsqueda, y trabajar de esta manera requiere la coherencia del índice. En la parte posterior, todos los documentos deben estar ajustados en un índice lucene plano, lo que requiere cierta comprensión sobre cómo ES debe tratar con sus documentos y valores anidados, y cómo debe organizar sus índices para mantener el equilibrio entre la velocidad y la integridad / consistencia de los datos. Trabajar con ES requiere que tengas en cuenta constantemente algunas cosas sobre el esquema. Es decir: como puede indexar casi cualquier cosa a ES sin poner el mapeo correspondiente por adelantado, ES puede "adivinar" el mapeo sobre la marcha, pero a veces lo hace incorrectamente y a veces el mapeo implícito es malo, porque una vez que se pone, no se puede cambiar w / o reindexación del índice completo. Por lo tanto, es mejor no tratar ES como una tienda sin esquemas, ya que puede pisar un rastrillo en algún momento (y esto será dolor :)), sino tratarlo como un esquema intensivo, al menos cuando se trabaja con documentos, que puede ser cortado en campos de concreto.
   • Mongo, por otro lado, puede "masticar y no dejar migas" de casi cualquier cosa que pongas en él. Y la mayoría de sus consultas funcionarán bien, hasta que recuerde cómo Mongo manejará sus datos desde la perspectiva de JavaScript. Y como JS está débilmente tipado, puede trabajar con un flujo de trabajo realmente sin esquema (seguro, si lo necesita)

3. Manejo de datos que no son de mesa.

   • ES está limitado a manejar datos sin ponerlos en el índice de búsqueda. Y esta solución es lo suficientemente buena, cuando necesita almacenar y recuperar algunos datos adicionales (en comparación con los datos que desea buscar en contra).
   • MongoDB es compatible con gridFS . Esto le da la capacidad de manejar grandes cantidades de datos detrás de la misma interfaz. Es decir, puede almacenar datos binarios en Mongo y recuperarlos dentro de la misma interfaz, desde la perspectiva de su código.