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

280

Con el movimiento de 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ías usar NoSQL (MongoDB, Cassandra, CouchDB, etc.) sobre Lucene (o Solr) como tu "base de datos"?

Lo que estoy buscando (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 potentes sistemas de búsqueda y peso. Sin mencionar las facetas en Solr (que Solr se está integrando en Lucene pronto, ¡yay!). Puede utilizar documentos de Lucene para almacenar ID y acceder a los documentos como tal, como MongoDB. Combínelo con Solr, y ahora obtendrá una solución de carga equilibrada basada en WebService.

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 tener más poder de agrupación y recopilación de listas sobre MongoDB (creo). No puede ser 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. Renueve un documento, cree una identificación y guárdelo. Hecho. Bonito y fácil.

mongodb  solr  lucene  memcached  nosql 
— eduncan911
fuente
8
— bajafresh4life
44
Gracias, pero eso no responde a mi pregunta: es decir, ¿por qué usaría MongoDB en lugar de Lucene para mi base de datos? Ambos manejan documentos, pero Lucene tiene algunas opciones de búsqueda muy poderosas. +1 aunque para encontrar una pregunta relacionada. Busqué varias veces en Stackoverflow y no obtuve una comparación cercana.
— eduncan911
¿Cómo estás usando Lucene que proporciona una funcionalidad similar a MongoDB? ¿Lo está vinculando a una base de datos relacional para el almacenamiento?
— Philip Tinney
1
@Philip: Es una pregunta hipotética. ¿Por qué no usar Lucene como almacenamiento de documentos? Obtiene mucho más poder de búsqueda y escalabilidad (cuando se mezcla con Solr, lo que hace que Lucene sea aún más fácil de usar).
— eduncan911

Respuestas:

250

Esta es una gran pregunta, algo en 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 servir para 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 programadores 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 un almacén de datos, pero Guardian ha avanzado un poco y resume esto en una excelente plataforma de diapositivas , pero tampoco se comprometen 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 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. Sin remordimientos hasta el momento (6 meses y contando) y no veo ninguna razón para cambiar a otro.

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 atenerse a una tecnología (Solr / Lucene) y optimizarla al máximo: menos partes móviles.

Mis 2 centavos, espero que haya ayudado.

— Mikos
fuente
10
Solr no tiene funcionalidad de reducción de mapas. Por lo tanto, los informes, las estadísticas, el cálculo de las puntuaciones, etc., no son posibles Use Solr solo si tiene / puede amenazar sus datos como datos de texto
— Roland Kofler
8
Solr no tiene incorporado map-reduce, pero puedes combinarlo con Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
— Mikos
66
Map-reduce no, pero tiene la capacidad de ejecutar una consulta en paralelo en varios servidores solr y agregar esos resultados. Entonces, si bien no tiene un propósito general map-reduce, ya ha escrito lo que escribiría con map-reduce, que son consultas de búsqueda paralelas.
— chubbsondubs
@Roo: ¿Sería una opción usar Lucene como DB principal y crear índices agregados con MongoDB de alguna manera? ¿O eso no tiene sentido? Y Mikos: gran respuesta y +1 para la experiencia del mundo real.
— Mueca de desesperación
2
de solr6 admite la funcionalidad de reducción de mapas con expresiones paralelas
— Divyang Shah
36

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 se compromete, su cambio a solr no tendrá efecto, si se compromete cada vez, el rendimiento se ve afectado.

No hay transacción en solr.

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

— Peter Long
fuente
13
MongoDB tampoco tiene transacciones.
— usuario183037
1
Solr o Lucene tienen búsqueda en tiempo real, por lo que comprometerse no es un problema.
— mihaicc
1
@ user183037 en MongoDB cualquier actualización dentro de un documento es Atomic. Y para su información, Lucene tampoco tiene transacciones (en su sentido)
— Aravind Yarram el
48
Esta respuesta se ha vuelto incorrecta. Solr 4+ admite actualizaciones parciales, y los compromisos suaves / casi en tiempo real eliminan la mayoría de los problemas de los compromisos Solr "a la antigua".
— Mauricio Scheffer
1
Agregaron soporte para transacciones en MongoDB 4.
— Jonas
26

Usamos MongoDB y Solr juntos y funcionan bien. Puede encontrar mi blog aquí donde describí cómo utilizamos estas tecnologías juntas. Aquí hay un extracto:

[...] Sin embargo, observamos que el rendimiento de la consulta de Solr disminuye cuando aumenta el tamaño del índice. Nos dimos cuenta de que la mejor solución es usar Solr y 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 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. [...]

— Parvin Gasimzade
fuente
3
Buena publicación de blog. Sí, así es exactamente como he usado Lucene en el pasado con almacenes de datos SQL y MySql más antiguos (almacenando ID en Lucene y recuperando los tipos complejos del almacén de datos). Sin embargo, técnicamente, esta pregunta era explorar las diferencias entre los dos, no exactamente cómo usar "lo mejor de ambos mundos". +1 por usarlo de esa manera, ya que es realmente la única forma real de usar grandes cantidades de datos.
— eduncan911
Gracias por su respuesta. Sé que la pregunta es sobre elegir Nosql sobre Lucene, pero aquí quiero mostrar que, en lugar de elegir uno sobre otro, usarlos de manera híbrida dará el mejor resultado.
— Parvin Gasimzade
2
¿Recuerdas (ahora 1,5 años después) aproximadamente el tamaño de la base de datos Solr cuando el rendimiento de la consulta había disminuido tanto que comenzaste a pensar en agregar MongoDB? (¿Fue 10.000 documentos o 10.000.000 de documentos?)
— KajMagnus
Muy útil. Trabajo en SIG, por lo que poder combinar texto completo con búsqueda espacial de esta manera es muy interesante. Ya usamos MongoDB y Postgres, y he estado pensando en Solr por un tiempo.
— John Powell
2
@ParvinGasimzade el enlace de la publicación del blog no funciona. ¿Podría proporcionar otro enlace o fuente?
— olvido
24

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 monitoreando las operaciones de oplog y conectando 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 increíble.

Es un poco técnico de configurar, pero hay muchos tailers oplog que pueden integrarse en solr. Mira lo que hizo rangepan en este artículo.

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

— Prasith Govin
fuente
Si te entendí correctamente, la razón por la que usas MongoDB (además de Solr), ¿es porque MongoDB tiene una velocidad de inserción + lectura más rápida? ¿También indicó que MongoDB tiene un almacén de datos más confiable? (¿O te referías a Solr?) - ¿Con qué comenzaste inicialmente? ¿Solo MongoDB, solo Solr o ambos Mongo + Solr?
— KajMagnus
12

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 combinaciones posibles de filtro / clasificación, simplemente no puede).

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

— mjalajel
fuente
10

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

— Acuarela
fuente
66
que en mi humilde opinión no es del todo cierto. Solr tiene un esquema como se define en schema.xmlPERO también tiene 'campos dinámicos', es decir, campos cuyos tipos se determinan mediante comodines, por lo que puede hacer que todos los campos coincidan, digamos, *_iindexados como campos enteros. al agregar documentos, a continuación, puede tener documentos conaining campos como count_i, foo_i, bar_ique son todos entendida como campos enteros sin aparecer en schema.xmlforma literal. bastante sin esquema, diría. ver youtube.com/watch?v=WYVM6Wz-XTw para más información.
— flujo
Tengo que volver y aumentar esto con un +1 porque eso es cierto: los cambios de esquema en Solr siempre han estado en un PITA para mantenerse sincronizado con otros almacenes de datos.
— eduncan911
44
¡Solr tiene una función que admite esquema o no esquema!
— Krunal
5

@ mauricio-scheffer mencionó Solr 4: para aquellos interesados ​​en eso, LucidWorks está describiendo 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 de NoSQL (ish). (El -ish es para su versión de schemaless que en realidad es un esquema dinámico).

— Beth
fuente
1

Si solo desea almacenar datos utilizando el formato de valor clave, no se recomienda Lucene porque su índice invertido desperdiciará demasiado espacio en disco. Y con el ahorro 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 RAM. La mayor ventaja para Lucene es que admite muchas consultas, por lo que se pueden admitir consultas difusas.

— 张洪岩
fuente
1

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 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 documento
    • 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 lucenos 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 dogo mongo son limitados, eso podría ir en contra del grano para lucene
  • las 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áficas
— Darren Weber
fuente
0

MongoDB Atlas tendrá un motor de búsqueda basado en lucene pronto. El gran anuncio se hizo en la conferencia MongoDB World 2019 de esta semana. Esta es una excelente manera de alentar un mayor uso de su producto Atlas MongoDB de altos ingresos.

Esperaba verlo en la versión 4.2 de MongoDB Enterprise, pero no ha habido noticias de llevarlo a su línea de productos local.

Más información aquí: https://www.mongodb.com/atlas/full-text-search

— Gary Russo
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.