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 uso general, pero saben que no era su diseño original. Creo que las bases de datos NoSQL de uso general y los motores de búsqueda se encaminan a la consolidación, pero tal como están, los dos provienen de campos muy diferentes.
Estamos usando MongoDB y Elasticsearch en mi empresa. 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 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 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 seleccionados; necesitaríamos volver a indexar un documento en su totalidad. Esta no es una limitación de Elastic, 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 modifiquen una vez almacenados 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 el filtrado 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:
- 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 a Elastic/Lucene, ya sabe la respuesta; la mayor parte de su trabajo consiste en clasificar los resultados por los que tienen más probabilidades de coincidir 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 lo cerca que se acercan a su consulta. Da la casualidad de 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 entre sí. Puede obtener un gran rendimiento por todos los medios, pero debe diseñar cuidadosamente sus índices para que coincidan con las consultas que ejecutará. Específicamente, si tiene varios campos por los que consultará, debe diseñar cuidadosamente sus claves compuestas para que reduzcan el conjunto de datos que se consultará lo más rápido posible. P.ej. su primera clave debe filtrar la mayoría de su conjunto de datos, su 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 se reducirá bastante. Por otro lado, Mongo es una verdadera base de datos, por lo que si lo que necesita es precisión, las respuestas que le dará serán acertadas.
Para los registros antiguos que caducan, Elastic tiene una función TTL incorporada. Creo que Mongo acaba de presentarlo a partir de la versión 2.2.
Dado que no conozco sus otros requisitos, como el tamaño de datos esperado, las transacciones, la precisión o cómo se verán sus filtros, es difícil hacer recomendaciones específicas. Con suerte, aquí hay suficiente para comenzar.
