Comparación del motor de búsqueda de texto completo: Lucene, Sphinx, Postgresql, MySQL?

Estoy construyendo un sitio de Django y estoy buscando un motor de búsqueda.

Algunos candidatos:

  • Lucene / Lucene con brújula / Solr

  • Esfinge

  • Postgresql incorporado en la búsqueda de texto completo

  • Búsqueda de texto completo incorporada de MySQL

Criteria de selección:

  • resultado relevancia y ranking
  • velocidad de búsqueda e indexación
  • facilidad de uso y facilidad de integración con Django
  • Requerimientos de recursos: el sitio se alojará en un VPS , por lo que, idealmente, el motor de búsqueda no requeriría mucha RAM y CPU.
  • escalabilidad
  • características adicionales tales como “¿quisiste decir?”, búsquedas relacionadas, etc.

Cualquiera que haya tenido experiencia con los motores de búsqueda anteriores u otros motores que no están en la lista, me encantaría escuchar sus opiniones.

EDITAR: en cuanto a las necesidades de indexación, a medida que los usuarios continúan ingresando datos en el sitio, esos datos deberían indexarse ​​continuamente. No tiene que ser en tiempo real, pero idealmente aparecerían nuevos datos en el índice con no más de 15 – 30 minutos de retraso

    Es bueno ver que alguien intervino sobre Lucene, porque no tengo idea de eso.

    Sphinx, por otro lado, lo sé bastante bien, así que vamos a ver si puedo ser de alguna ayuda.

    • El ranking de relevancia de resultados es el predeterminado. Puede configurar su propia clasificación si lo desea, y dar campos específicos de mayor ponderación.
    • La velocidad de indexación es superrápida, porque habla directamente con la base de datos. Cualquier lentitud vendrá de consultas SQL complejas y claves foráneas no indexadas y otros problemas similares. Nunca noté ninguna lentitud en la búsqueda tampoco.
    • Soy un tipo de Rails, así que no tengo idea de lo fácil que es implementarlo con Django. Sin embargo, hay una API de Python que viene con la fuente Sphinx.
    • El daemon del servicio de búsqueda (búsqueda) tiene muy poco uso de memoria, y puede establecer límites sobre la cantidad de memoria que utiliza el proceso del indexador.
    • La escalabilidad es donde mi conocimiento es más incompleto, pero es bastante fácil copiar archivos de índice a varias máquinas y ejecutar varios daemons de búsqueda. La impresión general que recibo de los demás es que es bastante bueno bajo alta carga, por lo que escalarlo en varias máquinas no es algo que deba abordarse.
    • No hay soporte para “did-you-mean”, etc., aunque esto se puede hacer con otras herramientas con la suficiente facilidad. Sphinx no usa palabras para usar diccionarios, por lo que “conducir” y “manejar” (por ejemplo) se considerarían lo mismo en las búsquedas.
    • Sin embargo, Sphinx no permite actualizaciones de índice parciales para datos de campo. El enfoque común para esto es mantener un índice delta con todos los cambios recientes, y volver a indexar esto después de cada cambio (y esos nuevos resultados aparecen dentro de uno o dos segundos). Debido a la poca cantidad de datos, esto puede tomar una cuestión de segundos. Sin embargo, todavía tendrá que volver a indexar el conjunto de datos principal regularmente (aunque la frecuencia depende de la volatilidad de sus datos, ¿todos los días? ¿Cada hora?). Sin embargo, las veloces velocidades de indexación mantienen todo esto bastante sencillo.

    No tengo idea de qué tan aplicable a su situación es esto, pero Evan Weaver comparó algunas de las opciones comunes de búsqueda Rails (Sphinx, Ferret (un puerto de Lucene para Ruby) y Solr), ejecutando algunos puntos de referencia. Podría ser útil, supongo.

    No he sondeado las profundidades de la búsqueda de texto completo de MySQL, pero sé que no compite a la velocidad ni a nivel de característica con Sphinx, Lucene o Solr.

    No conozco Sphinx, pero en cuanto a Lucene frente a una búsqueda de texto completo en la base de datos, creo que el rendimiento de Lucene no tiene comparación. Debería poder realizar casi cualquier búsqueda en menos de 10 ms, sin importar cuántos registros tenga que buscar, siempre que haya configurado su índice Lucene correctamente.

    Aquí viene el obstáculo más grande: personalmente, creo que integrar Lucene en su proyecto no es fácil . Claro, no es muy difícil configurarlo para que pueda hacer una búsqueda básica, pero si quiere sacar el máximo provecho de ella, con un rendimiento óptimo, definitivamente necesita un buen libro sobre Lucene.

    En cuanto a los requisitos de CPU y RAM, realizar una búsqueda en Lucene no hace demasiada tarea en la CPU, aunque indexar tus datos es, aunque no lo haces con demasiada frecuencia (tal vez una o dos veces al día), así que no es así. mucho de un obstáculo.

    No responde todas sus preguntas, pero en resumen, si tiene una gran cantidad de datos para buscar y desea un gran rendimiento, entonces creo que Lucene es definitivamente el camino a seguir. Si no vas a tener tantos datos para buscar, entonces también puedes buscar una base de datos de búsqueda de texto completo. La configuración de una búsqueda de texto completo de MySQL es definitivamente más fácil en mi libro.

    Estoy sorprendido de que no hay más información publicada sobre Solr. Solr es bastante similar a Sphinx pero tiene características más avanzadas (AFAIK ya que no he usado Sphinx, solo leí sobre él).

    La respuesta en el siguiente enlace detalla algunas cosas sobre Sphinx que también se aplica a Solr. Comparación del motor de búsqueda de texto completo: Lucene, Sphinx, Postgresql, MySQL?

    Solr también proporciona las siguientes características adicionales:

    1. Admite la replicación
    2. Varios núcleos (piense en estos como bases de datos separadas con su propia configuración y sus propios índices)
    3. Búsquedas booleanas
    4. Resaltar las palabras clave (bastante fácil de hacer en el código de la aplicación si tiene regex-fu; sin embargo, ¿por qué no dejar que una herramienta especializada le haga un mejor trabajo?)
    5. Actualizar índice a través de XML o archivo delimitado
    6. Comuníquese con el servidor de búsqueda a través de HTTP (incluso puede devolver Json, Native PHP / Ruby / Python)
    7. PDF, indexación de documentos de Word
    8. Campos dynamics
    9. Facetas
    10. Campos agregados
    11. Detener palabras, sinónimos, etc.
    12. Más como esto …
    13. Índice directamente desde la base de datos con consultas personalizadas
    14. Sugerir automáticamente
    15. Autocalentamiento de caché
    16. Indexación rápida (en comparación con los tiempos de indexación de búsqueda de texto completo de MySQL): Lucene utiliza un formato de índice binario invertido.
    17. Impulso (reglas personalizadas para boost la relevancia de una palabra clave o frase en particular, etc.)
    18. Búsquedas estructuradas (si un usuario de búsqueda conoce el campo que desea buscar, restringe su búsqueda escribiendo el campo, luego el valor, y SÓLO se busca ese campo en lugar de todo, la experiencia del usuario es mucho mejor)

    Por cierto, hay muchas más características; sin embargo, he enumerado solo las características que he utilizado en la producción. Por cierto, de fábrica, MySQL admite los números 1, 3 y 11 (limitados) en la lista anterior. Para las características que está buscando, una base de datos relacional no va a cortarlo. Eliminaría esos inmediatamente.

    Además, otro beneficio es que Solr (bueno, Lucene en realidad) es una base de datos de documentos (p. Ej., NoSQL), por lo que muchos de los beneficios de cualquier otra base de datos de documentos se pueden realizar con Solr. En otras palabras, puede usarlo para algo más que solo buscar (es decir, rendimiento). Sé creativo con eso 🙂

    Apache Solr


    Además de responder a las consultas de OP, permítanme ofrecer algunas ideas sobre Apache Solr desde una simple introducción a una instalación e implementación detalladas .

    Introducción simple


    Cualquiera que haya tenido experiencia con los motores de búsqueda anteriores u otros motores que no están en la lista, me encantaría escuchar sus opiniones.

    Solr no debe usarse para resolver problemas en tiempo real. Para los motores de búsqueda, Solr es bastante juego y funciona sin problemas .

    Solr funciona bien en aplicaciones web de alto tráfico ( leí en alguna parte que no es adecuado para esto, pero estoy respaldando esa afirmación ). Utiliza la memoria RAM, no la CPU.

    • resultado relevancia y ranking

    El impulso te ayuda a clasificar tus resultados en la parte superior. Digamos que estás tratando de buscar un nombre john en los campos firstname y lastname , y quieres darle relevancia al campo firstname , entonces necesitas impulsar el campo firstname como se muestra.

     http://localhost:8983/solr/collection1/select?q=firstname:john^2&lastname:john 

    Como puede ver, el campo firstname se impulsa con una puntuación de 2.

    Más sobre SolrRelevancecy

    • velocidad de búsqueda e indexación

    La velocidad es increíblemente rápida y no hay compromiso en eso. La razón por la que me mudé a Solr .

    Con respecto a la velocidad de indexación, Solr también puede manejar UNIONES de sus tablas de base de datos. Un JOIN más alto y complejo afecta la velocidad de indexación. Sin embargo, una enorme configuración de RAM puede abordar fácilmente esta situación.

    Cuanto mayor sea la RAM, más rápida será la velocidad de indexación de Solr.

    • facilidad de uso y facilidad de integración con Django

    Nunca intenté integrar a Solr y Django , sin embargo puedes lograr hacer eso con Haystack . Encontré un artículo interesante sobre el mismo y aquí está el github .

    • Requerimientos de recursos: el sitio se alojará en un VPS, por lo que, idealmente, el motor de búsqueda no requeriría mucha RAM y CPU.

    Solr se reproduce en la RAM, por lo que si la memoria RAM es alta, no debes preocuparte por Solr .

    El uso de la memoria RAM de Solr se dispara en la indexación completa si tiene unos mil millones de registros, podría hacer uso inteligente de las importaciones de Delta para hacer frente a esta situación. Como se explicó, Solr es solo una solución casi en tiempo real .

    • escalabilidad

    Solr es altamente escalable. Echa un vistazo a SolrCloud . Algunas características clave de esto.

    • Shards (o sharding es el concepto de distribuir el índice entre varias máquinas, por ejemplo, si su índice ha crecido demasiado)
    • Equilibrio de carga (si Solrj se usa con la nube Solr, se ocupa automáticamente del equilibrio de carga con su mecanismo Round-Robin)
    • Búsqueda distribuida
    • Alta disponibilidad
    • características adicionales tales como “¿quisiste decir?”, búsquedas relacionadas, etc.

    Para el escenario anterior, puede usar el SpellCheckComponent que está empacado con Solr . Hay muchas otras funciones, SnowballPorterFilterFactory ayuda a recuperar registros, por ejemplo, si escribió, libros en lugar de libros , se le presentarán los resultados relacionados con el libro .


    Esta respuesta se centra ampliamente en Apache Solr y MySQL . Django está fuera del scope.

    Suponiendo que se encuentre en un entorno LINUX, puede continuar con este artículo. (el mío era una versión de Ubuntu 14.04)

    Instalación detallada

    Empezando

    Descargue Apache Solr desde aquí . Esa sería la versión 4.8.1 . Puedes descargar nuevas versiones, encontré esto estable.

    Después de descargar el archivo, extráigalo a la carpeta que elija. Diga … Downloads o lo que sea … Entonces se verá como Downloads/solr-4.8.1/

    En su indicación .. Navegue dentro del directorio

    shankar@shankar-lenovo: cd Downloads/solr-4.8.1

    Entonces ahora estás aquí ..

    shankar@shankar-lenovo: ~/Downloads/solr-4.8.1$

    Inicie el servidor de aplicaciones Jetty

    Jetty está disponible dentro de la carpeta de ejemplos del directorio solr-4.8.1 , así que navega dentro de eso e inicia el servidor de aplicaciones Jetty.

    shankar@shankar-lenovo:~/Downloads/solr-4.8.1/example$ java -jar start.jar

    Ahora, no cierre la terminal, minimícela y déjela a un lado.

    (CONSEJO: Use & after start.jar para ejecutar el Jetty Server en segundo plano)

    Para verificar si Apache Solr se ejecuta con éxito, visite esta URL en el navegador. http: // localhost: 8983 / solr

    Running Jetty en un puerto personalizado

    Se ejecuta en el puerto 8983 como predeterminado. Puede cambiar el puerto aquí o directamente dentro del archivo jetty.xml .

    java -Djetty.port=9091 -jar start.jar

    Descargue el JConnector

    Este archivo JAR actúa como un puente entre MySQL y JDBC, descargue la versión independiente de la plataforma aquí

    Después de descargarlo, extraiga la carpeta y copie mysql-connector-java-5.1.31-bin.jar y péguela en el directorio lib .

    shankar@shankar-lenovo:~/Downloads/solr-4.8.1/contrib/dataimporthandler/lib

    Creando la tabla MySQL para vincular a Apache Solr

    Para usar Solr , debe tener algunas tablas y datos para buscar. Para eso, usaremos MySQL para crear una tabla y presionar algunos nombres aleatorios y luego podríamos usar Solr para conectarnos a MySQL e indexar esa tabla y sus entradas.

    1. Estructura de la mesa

     CREATE TABLE test_solr_mysql ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(45) NULL, created TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ); 

    2.Popular la tabla anterior

     INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jean'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jack'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jason'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Vego'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Grunt'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jasper'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Fred'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jenna'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Rebecca'); INSERT INTO `test_solr_mysql` (`name`) VALUES ('Roland'); 

    Entrar en el núcleo y agregar las directivas lib

    1.Navegar a

     shankar@shankar-lenovo: ~/Downloads/solr-4.8.1/example/solr/collection1/conf 

    2. Modificando el solrconfig.xml

    Agregue estas dos directivas a este archivo.

        

    Ahora agregue el DIH ( controlador de importación de datos)

       db-data-config.xml   

    3. Cree el archivo db-data-config.xml

    Si el archivo existe, entonces ignore, agregue estas líneas a ese archivo. Como puede ver en la primera línea, debe proporcionar las credenciales de su base de datos MySQL . El nombre de la base de datos, nombre de usuario y contraseña.

              

    (SUGERENCIA: puede tener cualquier cantidad de entidades, pero tenga cuidado con el campo de id, si son iguales, se saltará la indexación).

    4. Modifique el archivo schema.xml

    Agregue esto a su schema.xml como se muestra ..

     id  

    Implementación

    Indexación

    Aquí es donde está el verdadero negocio. Necesita hacer la indexación de datos de MySQL a Solr inorder para hacer uso de Solr Queries.

    Paso 1: ir al Panel de administración de Solr

    Pulse la URL http: // localhost: 8983 / solr en su navegador. La pantalla se abre así.

    Este es el principal panel de administración de Apache Solr

    Como indica el marcador, vaya a Inicio de sesión en el registro para verificar si alguna de las configuraciones anteriores ha producido errores.

    Paso 2: revisa tus registros

    Ok, ahora que estás aquí, como puedes, hay muchos mensajes amarillos (ADVERTENCIAS). Asegúrese de que no tenga mensajes de error marcados en rojo. Anteriormente, en nuestra configuración, habíamos agregado una consulta de selección en nuestro db-data-config.xml , por ejemplo, si había algún error en esa consulta, se habría mostrado aquí.

    Esta es la sección de registro de su motor Apache Solr

    Bien, no hay errores. Estamos bien para irnos. Elegimos collection1 de la lista como se muestra y seleccionamos Dataimport

    Paso 3: DIH (Manejador de importación de datos)

    Usando el DIH, se conectará a MySQL desde Solr a través del archivo de configuración db-data-config.xml desde la interfaz de Solr y recuperará los 10 registros de la base de datos que se indexa en Solr .

    Para hacer eso, elija importación completa y marque las opciones Limpiar y Confirmar . Ahora haga clic en Ejecutar como se muestra.

    Alternativamente, puede usar una consulta directa de importación completa como esta también ..

     http://localhost:8983/solr/collection1/dataimport?command=full-import&commit=true 

    El controlador de importación de datos

    Después de hacer clic en Ejecutar , Solr comienza a indexar los registros; si hubiera algún error, diría que la indexación falló y debe regresar a la sección de registro para ver qué ha ido mal.

    Suponiendo que no haya errores con esta configuración y que la indexación se complete con éxito, recibirá esta notificación.

    Éxito de indexación

    Paso 4: ejecutar consultas de Solr

    Parece que todo ha ido bien, ahora puedes usar Solr Queries para consultar los datos que fueron indexados. Haga clic en la consulta a la izquierda y luego presione el botón Ejecutar en la parte inferior.

    Verá los registros indexados como se muestra.

    La consulta de Solr correspondiente para listar todos los registros es

     http://localhost:8983/solr/collection1/select?q=*:*&wt=json&indent=true 

    Los datos indexados

    Bueno, ahí van los 10 registros indexados. Digamos que solo necesitamos nombres que comiencen con Ja , en este caso, debe apuntar al nombre de columna solr_name , de ahí que su consulta sea así.

     http://localhost:8983/solr/collection1/select?q=solr_name:Ja*&wt=json&indent=true 

    Los datos JSON que comienzan con Ja *

    Así es como escribes Solr Queries. Para leer más al respecto, consulte este hermoso artículo .

    Estoy mirando la búsqueda de texto completo de PostgreSQL en este momento, y tiene todas las características correctas de un motor de búsqueda moderno, muy buen carácter extendido y soporte multilingüe, buena integración ajustada con campos de texto en la base de datos.

    Pero no tiene operadores de búsqueda fáciles de usar como + o AND (usa & |!) Y no estoy muy contento con la forma en que funciona en su sitio de documentación. Si bien tiene negrita de términos de coincidencia en los fragmentos de resultados, el algoritmo predeterminado para el que coinciden los términos no es excelente. Además, si desea indexar rtf, PDF, MS Office, debe buscar e integrar un convertidor de formato de archivo.

    OTOH, es mucho mejor que la búsqueda de texto de MySQL, que ni siquiera indexa palabras de tres letras o menos. Es el valor predeterminado para la búsqueda de MediaWiki, y realmente creo que no es bueno para los usuarios finales: http://www.searchtools.com/analysis/mediawiki-search/

    En todos los casos que he visto, Lucene / Solr y Sphinx son realmente geniales . Son códigos sólidos y han evolucionado con mejoras significativas en usabilidad, por lo que las herramientas están ahí para hacer una búsqueda que satisfaga a casi todos.

    para SHAILI – SOLR incluye la biblioteca de códigos de búsqueda Lucene y tiene los componentes para ser un buen motor de búsqueda independiente.

    Solo mis dos centavos a esta muy vieja pregunta. Recomiendo echar un vistazo a ElasticSearch .

    Elasticsearch es un servidor de búsqueda basado en Lucene. Proporciona un motor de búsqueda de texto completo distribuido y apto para múltiples usuarios con una interfaz web RESTful y documentos JSON sin esquema. Elasticsearch se desarrolla en Java y se lanza como código abierto bajo los términos de la licencia de Apache.

    Las ventajas sobre otros motores FTS (búsqueda de texto completo) son:

    • Interfaz RESTful
    • Mejor escalabilidad
    • Gran comunidad
    • Construido por los desarrolladores de Lucene
    • Extensa documentación
    • Hay muchas bibliotecas de código abierto disponibles (incluido Django)

    Estamos utilizando este motor de búsqueda en nuestro proyecto y estamos muy contentos con él.

    SearchTools-Avi dijo “búsqueda de texto MySQL, que ni siquiera indiza palabras de tres letras o menos”.

    FYIs, la longitud de palabra minima de texto completo de MySQL es ajustable al menos desde MySQL 5.0. Google ‘mysql fulltext min length’ para instrucciones simples.

    Dicho esto, el texto completo de MySQL tiene limitaciones: por un lado, se vuelve lento de actualizar una vez que alcanzas un millón de registros más o menos, …

    Yo agregaría mnoGoSearch a la lista. Solución extremadamente eficiente y flexible, que funciona como Google: el indexador obtiene datos de múltiples sitios. Puede usar criterios básicos o inventar sus propios ganchos para obtener la máxima calidad de búsqueda. También podría obtener los datos directamente de la base de datos.

    La solución no es tan conocida hoy en día, pero cumple con las necesidades máximas. Puede comstackr e instalarlo o en un servidor independiente, o incluso en su servidor principal, no necesita tantos recursos como Solr, ya que está escrito en C y funciona perfectamente incluso en servidores pequeños.

    Al principio, debes comstackrlo tú mismo, por lo que requiere algún conocimiento. Hice un pequeño script para Debian, lo que podría ayudar. Cualquier ajuste es bienvenido

    Como está utilizando Django framework, podría usar el cliente PHP en el medio, o encontrar una solución en Python, vi algunos artículos .

    Y, por supuesto, mnoGoSearch es de código abierto, GNU GPL.