por - Opciones de búsqueda de texto completo para la configuración de MongoDB

hacer busquedas en mongodb (7)

Estamos planeando almacenar millones de documentos en MongoDB y la búsqueda de texto completo es muy necesaria. Leí Elasticsearch y Solr son las mejores soluciones disponibles para la búsqueda de texto completo.

¿La búsqueda elástica es lo suficientemente madura como para ser utilizada en la búsqueda de texto completo de Mongodb? También estamos fragmentando las colecciones. ¿Elasticsearch funciona con colecciones Sharded?
¿Cuáles son las ventajas y desventajas de usar Elasticsearch o Solr?
¿MongoDB es capaz de realizar búsquedas de texto completo?

Actualmente, en MongoDB 2.4.6, ahora hay una búsqueda de texto completo en MongoDB y es más rica en características, luego en versiones anteriores. En http://docs.mongodb.org/manual/core/text-search/ se describen las capacidades de la nueva funcionalidad.

Vale la pena mencionar:

tokenizes y deriva los términos de búsqueda durante la creación del índice y la ejecución del comando de texto. asigna un puntaje a cada documento que
contiene el término de búsqueda en los campos indexados. El puntaje determina la relevancia de un documento para una consulta de búsqueda determinada.

Sin embargo, en esta respuesta (desde septiembre de 2013) https://.com/a/18631775/1920149 puede ver que el mongo todavía advierte sobre el uso de esta funcionalidad en producción. Esta funcionalidad todavía está en etapa beta.

En términos de MongoDB nativamente, no, no tiene soporte de búsqueda de texto completo. Puede ver que es una solicitud de función popular:

https://jira.mongodb.org/browse/SERVER-380

Por lo que sé sobre el plugin de ES River para MongoDB, el oplog funciona por su funcionalidad. Dado que una configuración fragmentada tendría varios oplogs y no habría forma de alterar fácilmente ese código para conectarse a través de un mongos.

De forma similar para Solr, los ejemplos que he visto generalmente implican un comportamiento similar al plugin de ES. Algo más de información sólida aquí:

http://blog.knuthaugen.no/2010/04/cooking-with-mongodb-and-solr.html

No tengo experiencia en el uso de uno, pero otros han hecho comparaciones antes, eche un vistazo aquí:

Solr vs. ElasticSearch

ElasticSearch, Sphinx, Lucene, Solr, Xapian. ¿Cuál se ajusta a qué uso?

Hay algunas capacidades de búsqueda en MongoDB, pero no es tan rica en funciones como los motores de búsqueda.

http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo

Usamos Mongo con Solr para hacer que el contenido se pueda buscar. Preferimos Solr porque

Es fácil de configurar y personalizar
Tiene una gran comunidad (Esto es realmente útil si trabajas con herramientas de código abierto)

Como no trabajamos con ES, no pude decir mucho al respecto. Puede encontrar algunas discusiones sobre Solr vs ES en los enlaces a continuación.

La búsqueda de texto completo es posible en el entorno del producto con Mongodb desde la versión 2.6 al crear un índice de texto en los campos requeridos. indexe el texto en mongodb

Mongo no es bueno para la búsqueda de texto completo. Obviamente necesita indexar sus campos para realizar búsquedas rápidas, y los campos de indexación que contienen datos GRANDES (cadenas largas y largas) serán un error en mongo. tiene un límite de 1k para el índice, si tiene contenido más de 1k, será ignorado por el índice y no se mostrará en los resultados de búsqueda. obviamente, si intenta realizar una búsqueda de texto completo de sus artículos, mongo no es una buena opción.

MongoDB no puede hacer una búsqueda eficiente de texto completo. Puede hacer búsquedas con comodines en los campos, pero no creo que estos usen índices de manera eficiente.

Recomendaría utilizar la funcionalidad River de ElasticSearch para enviar automáticamente los documentos de MongoDB a ElasticSearch.

elasticsearch-river-mongodb es un río MongoDB a Elasticsearch que cuando un documento cambia en MongoDB, ElasticSearch supervisará el oplog y luego actualizará automáticamente su índice.

Esto minimiza el problema de mantener los dos almacenes de datos sincronizados, ya que ElasticSearch solo está monitoreando las tablas de replicación de Mongo.

Tengo una experiencia profesional con Solr / MySQL y ElasticSearch / MongoDB.

Si vas a consultar mucho tu buscador, ya guardas tu MongoDB (quiero decir, si quieres fragmentar tu motor de búsqueda): debes usar ElasticSearch, a menos que lo que quieras hacer no se pueda hacer con ElasticSearch . Y deberías usarlo incluso si no vas a usar fragmentos.

ElasticSearch es un nuevo proyecto además de Lucene que trae el mecanismo de fragmentación, de alguien que está acostumbrado a entornos distribuidos y búsqueda (Shay Bannon hizo Compass y trabajó para Gigaspaces, el editor de cuadrícula de datos).

ElasticSearch es tan fácil como MongoDB a shard, creo que es incluso más simple y el predeterminado funciona muy bien para la mayoría de los casos.

No me gusta mucho Solr.

El lenguaje de consulta no está estructurado en absoluto (pero es el caso de los complementos y Lucene, y creo que también puede utilizar este lenguaje de consulta no estructurado con ES)
No creo que haya un cliente de Solr adecuado. El cliente de Solr java apesta, y escucho a PHP chicos también quejándose, mientras que el cliente ElasticSearch Java es muy agradable, mucho más seguro y ofrece soporte asíncrono (bueno si usas Netty por ejemplo). Con Solr, harás MUCHA concatenación de cuerdas.
Menos fácil de escalar
Proyecto no tan nuevo, sentí que el departamento técnico tiene. ElasticSearch nace de Compass, así que creo que todo el departamento técnico se ha abandonado para tener un nuevo enfoque.

En cuanto a la importación de datos, tengo experiencia con los ríos Solr DataImportHandler y ElasticSearch (CouchDB y MongoDB). Lo que puedo decirte es:

Solr permite hacer más cosas, pero de una forma XML muy desestructurada, y la documentación no le ayuda tanto a comprender lo que realmente está sucediendo una vez que está fuera del mundo hello y trata de usar algunas funciones avanzadas.
El enfoque de ElasticSearch es más simple y también limitado, pero cuenta con compatibilidad inmediata con algunas tecnologías, mientras que DataImportHandler parece más complejo: amigable con SQL
Con mi proyecto Solr tuve que usar indexación manual para algunos documentos, pero fue principalmente debido a la imposibilidad de desnormalizar los datos necesarios en un documento (el proyecto Solr usa MySQL).

También hay un nuevo conector MongoDB para Solr y ElasticSearch, que necesito probar lo antes posible :) http://blog.mongodb.org/post/29127828146/introducing-mongo-connector

Así que al final, definitivamente elegiré ElasticSearch, porque:

Ahora tiene una gran comunidad
Muchas personas que conozco con experiencia en Solr como ElasticSearch
El lado del cliente es más seguro y estructurado, y proporciona sincronización con Java Futures
Ambos pueden importar datos de MongoDB fácilmente con el nuevo conector
Hasta donde yo sé, permite hacer casi todo lo que hace Solr (en mi experiencia, pero no soy un experto en motores de búsqueda)
Agrega sharding fuera de la caja
Agrega percolación que puede ayudar a crear aplicaciones escalables en tiempo real (pero es probable que necesite una tecnología de mensajería adicional)
El código fuente que leí casi no tiene departamento técnico en comparación con Solr (al menos en el lado del cliente), y parece fácil crear complementos.