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

Con el movimiento NoSQL creciendo basado en bases de datos basadas en documentos, he observado a MongoDB últimamente. He notado una sorprendente similitud con la forma de tratar los artículos como “Documentos”, al igual que Lucene (y los usuarios de Solr).

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

Lo que estoy (y estoy seguro de que otros están) buscando en una respuesta son algunas comparaciones profundas de ellos. Pasemos por alto todas las discusiones de bases de datos relacionales, ya que tienen un propósito diferente.

Lucene ofrece algunas ventajas serias, como poderosos sistemas de búsqueda y peso. Sin mencionar las facetas en Solr (que Solr se integrará en Lucene pronto, ¡yay!). Puede usar documentos Lucene para almacenar ID y acceder a los documentos como tales, como MongoDB. Mézclalo con Solr, y ahora obtienes una solución balanceada de carga basada en WebService.

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

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

MongoDB (y otros) tienen algunas ventajas, como la facilidad de uso de su API. Nuevo encima de un documento, crea una identificación, y almacénala. Hecho. Bonito y fácil.

Esta es una gran pregunta, algo sobre lo que he reflexionado bastante. Resumiré mis lecciones aprendidas:

  1. Puede usar Lucene / Solr fácilmente en lugar de MongoDB para casi todas las situaciones, pero no al revés. La publicación de Grant Ingersoll lo resume aquí.

  2. MongoDB, etc. parece cumplir un propósito donde no hay requisitos de búsqueda y / o facetado. Parece ser una transición más simple y posiblemente más fácil para los progtwigdores que se desintoxican del mundo RDBMS. A menos que uno esté acostumbrado, Lucene y Solr tienen una curva de aprendizaje más pronunciada.

  3. No hay muchos ejemplos del uso de Lucene / Solr como almacén de datos, pero Guardian ha hecho algunos progresos y resumió esto en una excelente plataforma de diapositivas , pero ellos también no están decididos a saltar totalmente en el carro de Solr e “investigar” combinar Solr. con CouchDB.

  4. Finalmente, ofreceré nuestra experiencia, desafortunadamente no puedo revelar mucho sobre el caso comercial. 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 me arrepiento hasta ahora (6 meses y contando) y no veo razón para cambiar a otro.

Resumen: si no tiene un requisito de búsqueda, Mongo ofrece un enfoque simple y potente. Sin embargo, si la búsqueda es la clave de su oferta, es mejor que se quede con una sola tecnología (Solr / Lucene) y optimice todo: menos partes móviles.

Mis 2 centavos, espero que haya ayudado.

No 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 comprometes cada vez, el rendimiento sufre.

No hay transacción en solr.

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

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 oplog y las actualizaciones relevantes en cascada en Solr.

Con este enfoque híbrido, puede obtener lo mejor de ambos mundos con capacidades como la 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 increíble.

Es un poco técnico configurarlo, pero hay muchos oplog tailers que pueden integrarse en solr. Echa un vistazo a lo que hizo rangepan en este artículo.

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

Usamos MongoDB y Solr juntos y funcionan bien. Puedes encontrar mi publicación de blog aquí donde describí cómo utilizamos estas tecnologías juntas. 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 usar tanto Solr como Mongo DB juntos. Luego, integramos Solr con MongoDB almacenando contenidos en MongoDB y creando un índice usando Solr para la búsqueda de texto completo. Solo almacenamos la identificación ú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, puntajes, etc. […]

Dado que nadie más lo mencionó, permítanme agregar que MongoDB no tiene esquemas, mientras que Solr impone un esquema. Entonces, si es probable que los campos de sus documentos cambien, esa es una razón para elegir MongoDB sobre Solr.

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

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

@ mauricio-scheffer mencionó a Solr 4: para los interesados ​​en eso, LucidWorks describe 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 entran en detalles sobre las características NoSQL (ish). (El -ish es para su versión de schemaless en realidad un esquema dynamic.)

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

Las soluciones de terceros, como un mongo op-log tail son atractivas. Algunos pensamientos o preguntas permanecen sobre si las soluciones podrían estar estrechamente integradas, asumiendo una perspectiva de desarrollo / architecture. No espero ver una solución estrechamente integrada para estas características por algunas razones (algo especulativas y sujetas a aclaraciones y no actualizadas con los esfuerzos de desarrollo):

  • mongo es c ++, lucene / solr son java
  • lucene admite varios formatos de documentos
    • mongo se centra en JSON (BSON)
  • lucene usa documentos inmutables
    • las actualizaciones de campo único son un problema, si están disponibles
  • Los índices lucene son inmutables con operaciones de fusión complejas
  • las consultas de mongo son javascript
  • mongo no tiene analizadores / tokenizadores de texto (AFAIK)
  • Los tamaños de mongo doc son limitados, que pueden ir contra el grano para lucene
  • las operaciones de agregación de mongo pueden no tener cabida 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 de SQL / gráfico

NoSQL funciona como bases de datos multinodo que ofrecen excelentes características de escalabilidad. Hoy en día, muchas bases de datos NoSQL admiten particiones de datos en diferentes nodos, lo que ayuda a escalar grandes conjuntos de datos y reducir la duplicación innecesaria. La eficacia de la aplicación no solo depende de los modelos de datos sino también de la eficacia de las nuevas funciones. Los modelos de datos funcionan como un puente entre los problemas del mundo real y el software. Las soluciones de bases de datos NoSQL desarrollan aplicaciones de software modernas.