NoSQL(MongoDB) vs Lucene(o Solr) como su base de datos

memcached (9)

Con el movimiento NoSQL creciendo en base a bases de datos basadas en documentos, he visto MongoDB últimamente. He notado una sorprendente similitud con la forma de tratar los elementos como "Documentos", al igual que Lucene (y los usuarios de Solr).

Entonces, la pregunta: ¿Por qué querría usar NoSQL (MongoDB, Cassandra, CouchDB, etc.) sobre Lucene (o Solr) como su "base de datos"?

Lo que estoy buscando (y estoy seguro de que otros lo están) en una respuesta es una comparación profunda de ellos. Vamos a pasar por alto las discusiones de bases de datos relacionales, ya que tienen un propósito diferente.

Lucene ofrece algunas ventajas serias, como sistemas de pesas y búsqueda poderosos. Sin mencionar las facetas en Solr (que Solr se integrará pronto en Lucene, ¡yay!). Puede utilizar los documentos de Lucene para almacenar ID y acceder a los documentos como MongoDB. Mézclelo con Solr, y ahora obtiene una solución de carga equilibrada basada en servicio web.

Incluso puede incluir una comparación de proveedores de caché fuera de proceso como Velocity o MemCached cuando se habla de almacenamiento de datos y escalabilidad similares de MongoDB.

Las restricciones en torno a MongoDB me recuerdan el uso de MemCached, pero puedo usar Velocity de Microsoft y tengo más poder de agrupación y recopilación de listas sobre MongoDB (creo). No se puede obtener más rápido o escalable que el almacenamiento en caché de datos en la memoria. Incluso Lucene tiene un proveedor de memoria.

MongoDB (y otros) tienen algunas ventajas, como la facilidad de uso de su API. Crear un documento nuevo, crear una identificación y almacenarlo. Hecho. Bonito y fácil.

@ mauricio-scheffer mencionó Solr 4; para aquellos interesados en eso, LucidWorks describe a Solr 4 como "el servidor de búsqueda NoSQL" y hay un video en http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/ donde se detallan las características de NoSQL (ish). (El -ish es para su versión de schemaless siendo en realidad un esquema dinámico).

Como nadie más lo mencionó, permítame agregar que MongoDB no tiene esquema, mientras que Solr hace cumplir un esquema. Por lo tanto, si es probable que cambien los campos de sus documentos, esa es una razón para elegir MongoDB sobre Solr.

Desde mi experiencia con ambos, Mongo es ideal para un uso simple y directo. La principal desventaja de Mongo que hemos sufrido es el bajo rendimiento en consultas no anticipadas (no puede crear índices de Mongo para todas las posibles combinaciones de filtro / clasificación, simplemente no puede).

Y aquí donde Lucene / Solr prevalece a lo grande, especialmente con el almacenamiento en caché de FilterQuery, el rendimiento es sobresaliente.

Esta es una gran pregunta, algo sobre lo que he reflexionado bastante. Voy a resumir mis lecciones aprendidas:

Puede usar Lucene / Solr fácilmente en lugar de MongoDB para casi todas las situaciones, pero no al revés. El post de Grant Ingersoll lo resume aquí.
MongoDB, etc. parece tener un propósito donde no hay un requisito de búsqueda y / o facetado. Parece ser una transición más simple y posiblemente más fácil para los programadores que desintoxican el mundo RDBMS. A menos que uno esté acostumbrado, Lucene y Solr tienen una curva de aprendizaje más pronunciada.
No hay muchos ejemplos de uso de Lucene / Solr como almacén de datos, pero Guardian ha avanzado bastante y resume esto en una excelente slide-deck , pero también no se compromete a saltar totalmente en el carro de Solr e "investigando" combinando Solr con CouchDB.
Finalmente, ofreceré nuestra experiencia, desafortunadamente no puedo revelar mucho sobre el caso de negocios. Trabajamos en la escala de varios TB de datos, una aplicación casi en tiempo real. Después de investigar varias combinaciones, decidió quedarse con Solr. No se arrepiente hasta ahora (6 meses y contando) y no ve ninguna razón para cambiar a otra.

Resumen: si no tiene un requisito de búsqueda, Mongo ofrece un enfoque simple y poderoso. Sin embargo, si la búsqueda es clave para su oferta, es probable que sea mejor apegarse a una tecnología (Solr / Lucene) y optimizar la salida: menos partes móviles.

Mis 2 centavos, espero que ayude.

Las soluciones de terceros, como un mongo op-log tail son atractivas. Quedan algunos pensamientos o preguntas sobre si las soluciones podrían integrarse estrechamente, asumiendo una perspectiva de desarrollo / arquitectura. No espero ver una solución estrechamente integrada para estas características por varias razones (algo especulativa y sujeta a aclaraciones y no actualizada con los esfuerzos de desarrollo):

mongo es c ++, lucene / solr are java
- tal vez lucene podría usar algunas libertinas mongo
- tal vez Mongo podría reescribir algunos algoritmos de Lucene, ver también:
  - http://clucene.sourceforge.net/
  - http://lucy.apache.org/
Lucene soporta varios formatos de documentación.
- mongo se centra en JSON (BSON)
lucene utiliza documentos inmutables
- Las actualizaciones de un solo campo son un problema, si están disponibles.
Los índices de Lucene son inmutables con operaciones de fusión complejas.
las consultas de mongo son javascript
mongo no tiene analizadores de texto / tokenizadores (AFAIK)
Los tamaños de los documentos Mongo son limitados, lo que podría ir en contra del grano para luceno.
operaciones de agregación de mongo pueden no tener lugar en lucene
- Lucene tiene opciones para almacenar campos en documentos, pero eso no es lo mismo.
- solr de alguna manera proporciona agregación / estadísticas y consultas SQL / gráfico

No se puede actualizar parcialmente un documento en solr. Debe volver a publicar todos los campos para actualizar un documento.

Y el rendimiento importa. Si no te comprometes, tu cambio a solr no tendrá efecto, si te comprometes cada vez, el rendimiento se resentirá.

No hay transacción en solr.

Como solr tiene estas desventajas, algunas veces nosql es una mejor opción.

Si solo desea almacenar datos utilizando el formato clave-valor, Lucene no se recomienda porque su índice invertido desperdiciará demasiado espacio en el disco. Y con los datos guardados en el disco, su rendimiento es mucho más lento que el de las bases de datos NoSQL, como redis, ya que redis guarda los datos en la RAM. La mayor ventaja para Lucene es que admite muchas consultas, por lo que se pueden admitir consultas confusas.

También tenga en cuenta que algunas personas han integrado Solr / Lucene en Mongo al tener todos los índices almacenados en Solr y también monitorear las operaciones de oplog y las actualizaciones relevantes en cascada en Solr.

Con este enfoque híbrido, realmente puede tener lo mejor de ambos mundos con capacidades tales como búsqueda de texto completo y lecturas rápidas con un almacén de datos confiable que también puede tener una velocidad de escritura deslumbrante.

Es un poco técnico de instalar, pero hay muchos adaptadores de oplog que pueden integrarse en solr. Echa un vistazo a lo que rangos hizo en este artículo.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Usamos MongoDB y Solr juntos y funcionan bien. Puede encontrar mi publicación de blog aquí donde describí cómo usamos estas tecnologías en conjunto. Aquí hay un extracto:

[...] Sin embargo, observamos que el rendimiento de las consultas de Solr disminuye cuando aumenta el tamaño del índice. Nos dimos cuenta de que la mejor solución es utilizar Solr y Mongo DB juntos. Luego, integramos Solr con MongoDB almacenando los contenidos en MongoDB y creando un índice usando Solr para la búsqueda de texto completo. Solo almacenamos la ID única para cada documento en el índice de Solr y recuperamos el contenido real de MongoDB después de buscar en Solr. Obtener documentos de MongoDB es más rápido que Solr porque no hay analizadores, puntuación, etc. [...]