2010-03-30 12 views
34

En un proyecto nuevo, necesito un uso riguroso de lucene para la implementación de un buscador. Este buscador será una pieza muy importante (y grande) del proyecto. ¿Es válido o conveniente reemplazar Base de datos relacional + Lucene con MongoDb?¿Es MongoDB una alternativa válida a db + lucene relacional?

corregir: Ok, aclararé: no estoy preguntando sobre el riesgo, puedo pagar ese precio en este proyecto. Mi punto es: ¿MongoDB está orientado a este tipo de cosas? ¿Puedo hacer un motor de búsqueda completo con el mismo rendimiento que puedo obtener en Lucene ?. Un amigo me señala MongoDB como alternativa, pero no veo si el rendimiento de Lucene viene con el documento alternativo (y luego, también lo veré en MongoDB), o, por otro lado, el índice invertido y las optimizaciones son completas. Independiente de la orientación del documento.

+0

Mis 2 centavos: tomaría un enfoque compuesto, en el que puede tener más tarde la posibilidad de cambiar la fuente de datos subyacente –

+1

Ok, aclararé: no estoy preguntando sobre el riesgo, puedo pagar ese precio en este proyecto. Mi punto es: ¿MongoDB está orientado a este tipo de cosas? ¿Puedo hacer un motor de búsqueda completo con el mismo rendimiento que puedo obtener en Lucene ?. Un amigo me señala MongoDB como alternativa, pero no veo si el rendimiento de Lucene viene con el documento alternativo (y luego, también lo veré en MongoDB), o, por otro lado, el índice invertido y las optimizaciones son completamente independiente de la orientación del documento. – Hugo

Respuesta

1

No estoy familiarizado con MongoDB así que no puedo responder directamente a la pregunta, pero me gustaría tener en cuenta que a diferencia de Lucene (que es de unos diez años) y bases de datos relacionales (que han existido durante décadas) es MongoDB menos de tres años.

En esta etapa del juego, es probable que aún esté madurando. Puede ser adecuado para sus necesidades (y tengo curiosidad por ver si alguien familiarizado con su uso sonará aquí), pero tendrá que tener esto en cuenta en su ecuación. ¿Estás dispuesto a pagar el precio para usar tecnología de vanguardia?

Incluso si termina siendo lo suficientemente estable y eficiente, puede tener problemas con soporte limitado en forma de sitios web/tutoriales, etc. (debido a la pequeña base de usuarios). También corres el riesgo de que se suspenda.

Puede valer la pena aprovechar esta oportunidad, pero tiene que hacerlo con los ojos abiertos y sin cegar por el efecto "oh, mira el juguete nuevo y brillante".

+0

Sure Kris, noté que, en este caso particular, puedo pagar ese precio. Gracias. – Hugo

+0

Si el juguete se interrumpe, siempre puede mover los datos a un RDBMS :) –

-7

No, no lo es, ya que MongoDB no es relacional.

0

Lucene es un producto establecido y estable. Por desgracia, no es cierto lo mismo de MongoDB. Entonces, creo que Lucene más un RDBMS es una opción mucho menos arriesgada.

Por supuesto, hasta cierto punto depende de la naturaleza del proyecto: ¿qué tan importante es "muy importante (y grande)"? La otra cosa es, ¿tienes experiencia previa de MongoDB (supongo que no)? Si puede obtener acceso a personas que tienen cierta experiencia, eso mitigaría el riesgo.

2

de Look posible pero más lento (see here)

  • Usted tendrá que hacer la división de palabras y frenar su auto.
  • Ranking de consultas 'requiere código suministrado por el usuario para hacerlo'
19

Técnicamente se puede hacer búsqueda de texto completo con MongoDB, pero que se está perdiendo en un lote que un proveedor de búsqueda de texto completo tiene que ofrecer. Me encanta MongoDB, pero me gustaría asociarlo con un proveedor de búsqueda de texto completo (como Lucene o Sphinx) si el tiempo de implementación es una preocupación. Creo que la conveniente capacidad de MongoDB para indexar arreglos de palabras se deja mejor al etiquetado y la búsqueda basada en el etiquetado que la búsqueda de texto completo.

Buscar (Recuperación de información) no se trata solo de obtener cualquier documento que coincida, si desea que los resultados de búsqueda tengan alguna relevancia, necesitará algo como TF-IDF, concordancia de frase (palabras en una secuencia de puntuación más alta) o cualquier número de otras técnicas de IR para mejorar la precisión de búsqueda. Si usa MongoDB, deberá implementarlo desde cero.

Si realmente quieres implementarlo todo desde el principio pero sin molestarte con el almacenamiento en bruto, MongoDB está bastante cerca de la mejor tienda de base de datos sobre la que puedes implementarlo (no puedo pensar en muchos otros), pero eso todavía no lo hace una gran opción.

2

MongoDB es una NoSQL, Lucene y SOLR son los motores de búsqueda, y la adición de otra cosa que la comparación es cachés como Terracota, junto con Ehcache. Todos tienen su propio propósito.

Si se requiere buscar junto con la búsqueda de texto completo con stemming, la configuración de relevancia muestra resultados con la coincidencia de texto en el título del producto más que la coincidencia de texto en destription y muchas características basadas en texto. También ranking, relevancia, sonido, mateo, palabra parcial, etc. Todo esto se maneja mejor mediante sistemas de almacenamiento basados ​​en búsqueda como SOLR y Lucene.

Si su criterio es la recuperación de fater solamente y no necesita que sus objetos de datos de presentación sean duraderos, simplemente use un caché lke Terracota.

Si necesita más rápida recuperación y también tienen que colloborate y agregar datos en una fuente de datos y también es necesario que los datos agregados para ser duradera a continuación, utilizar NOSQL como MongoDB.

Cuestiones relacionadas