index fulltext full mysql postgresql full-text-search lucene sphinx

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



php mysql full text search (8)

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

  • MySql incorporado en la búsqueda de texto completo

Criteria de selección:

  • relevancia del resultado y clasificación
  • velocidad de búsqueda e indexación
  • Facilidad de uso y facilidad de integración con Django.
  • requisitos de recursos: el sitio se alojará en un VPS , por lo que idealmente el motor de búsqueda no requeriría una gran cantidad de RAM y CPU
  • escalabilidad
  • funciones adicionales como "¿quiso decir?", búsquedas relacionadas, etc.

Cualquier persona 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án ser indexados continuamente. No tiene que ser en tiempo real, pero lo ideal sería que los nuevos datos se mostraran en el índice con no más de 15 a 30 minutos de retraso.


Apache Solr

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

Simple introducción

Cualquier persona 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 prácticamente un juego y funciona perfectamente .

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.

  • relevancia del resultado y clasificación

El impulso le ayuda a clasificar sus resultados en la parte superior. Digamos que está tratando de buscar un nombre john en los campos nombre y apellido , y desea darle relevancia al campo nombre, entonces necesita aumentar el campo nombre como se muestra.

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

Como puede ver, el campo de primer nombre se incrementa con una puntuación de 2.

Más sobre SolrRelevancy

  • 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 desde las tablas de su 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 esta situación fácilmente.

Cuanto mayor sea la memoria 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 Solr y Django , sin embargo, puedes lograr hacerlo con haystacksearch.org . Encontré un article interesante sobre el mismo y aquí está el github para ello.

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

Solr se reproduce en RAM, así que si la memoria RAM es alta, no tienes que preocuparte por Solr .

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

  • escalabilidad

Solr es altamente escalable. Echa un vistazo en SolrCloud . Algunas características clave de la misma.

  • Fragmentos (o fragmentación 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, automáticamente se encarga de equilibrar la carga utilizando su mecanismo Round-Robin)
  • Busqueda distribuida
  • Alta disponibilidad
  • funciones adicionales como "¿quiso decir?", búsquedas relacionadas, etc.

Para el escenario anterior, podría usar el SpellCheckComponent que está empaquetado con Solr . Hay muchas otras características, The 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 enfoca ampliamente en Apache Solr y MySQL . Django está fuera de alcance.

Suponiendo que está en el entorno LINUX, podría continuar con este artículo. (La mía era una versión de Ubuntu 14.04)

Instalación detallada

Empezando

Descarga Apache Solr desde here . Esa sería la versión 4.8.1 . Podrías descargar nuevas versiones, encontré este establo.

Después de descargar el archivo, extráigalo a una carpeta de su elección. Diga .. Downloads o lo que sea .. Así que se verá como Downloads/solr-4.8.1/

En su aviso .. Navegue dentro del directorio

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

Así que ahora estás aquí ..

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

Iniciar el servidor de aplicaciones Jetty

Jetty está disponible dentro de la carpeta de ejemplos del directorio solr-4.8.1 , así que navegue dentro de eso e inicie 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 hacer que el servidor Jetty se ejecute en segundo plano)

Para comprobar si Apache Solr se ejecuta correctamente, visite esta URL en el navegador. http://localhost:8983/solr

Ejecutando embarcadero en el puerto personalizado

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

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

Descarga el JConnector

Este archivo JAR actúa como un puente entre MySQL y JDBC. Descargue la versión independiente de la plataforma here

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

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

Creando la tabla MySQL para ser vinculada a Apache Solr

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

Estructura 1.Table

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 ...

<lib dir="../../../contrib/dataimporthandler/lib/" regex=".*/.jar" /> <lib dir="../../../dist/" regex="solr-dataimporthandler-/d.*/.jar" />

Ahora agregue el DIH (Data Import Handler)

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler" > <lst name="defaults"> <str name="config">db-data-config.xml</str> </lst> </requestHandler>

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

Si el archivo existe, ignórelo, agregue estas líneas a ese archivo. Como puede ver 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.

<dataConfig> <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/yourdbname" user="dbuser" password="dbpass"/> <document> <entity name="test_solr" query="select CONCAT(''test_solr-'',id) as rid,name from test_solr_mysql WHERE ''${dataimporter.request.clean}'' != ''false'' OR `created` > ''${dataimporter.last_index_time}''" > <field name="id" column="rid" /> <field name="solr_name" column="name" /> </entity> </document> </dataConfig>

(CONSEJO: puede tener cualquier número de entidades, pero tenga cuidado con el campo de identificación, si son iguales, se omitirá la indexación).

4.Modifica el archivo schema.xml

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

<uniqueKey>id</uniqueKey> <field name="solr_name" type="string" indexed="true" stored="true" />

Implementación

Indexación

Aquí es donde está el verdadero negocio. Debe hacer la indexación de datos de MySQL a Solr 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í.

Como lo indica el marcador, vaya a Iniciar sesión para verificar si alguna de las configuraciones anteriores ha generado errores.

Paso 2: Revise sus registros

Bien, ahora estás aquí. Como puedes, hay muchos mensajes amarillos (ADVERTENCIAS). Asegúrate de no tener 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 hubiera algún error en esa consulta, habría aparecido aquí.

Bien, no hay errores. Estamos bien para ir Vamos a elegir collection1 de la lista como se muestra y seleccione Dataimport

Paso 3: DIH (Data Import Handler)

Con 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 hacerlo, elija la importación completa y verifique las opciones Limpiar y Confirmar . Ahora haga clic en Ejecutar como se muestra.

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

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

Después de hacer clic en Ejecutar , Solr comienza a indexar los registros, si hubiera algún error, diría que Falló la indexación y tiene que volver a la sección Registro para ver qué ha fallado.

Suponiendo que no haya errores con esta configuración y si la indexación se completa con éxito, obtendría esta notificación.

Paso 4: Ejecutando Consultas Solr

Parece que todo salió bien, ahora podría usar Solr Queries para consultar los datos que se indexaron. 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

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

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

Así es como escribes Solr Queries. Para leer más sobre esto, revisa este hermoso article .


Estoy viendo 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, un carácter extendido realmente bueno y soporte multilingüe, una buena integración con los 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 encantado de cómo funciona en su sitio de documentación. Si bien tiene una gran cantidad de términos de coincidencia en los fragmentos de resultados, el algoritmo predeterminado para el cual los términos de coincidencia no es excelente. Además, si desea indexar rtf, PDF, MS Office, debe encontrar e integrar un convertidor de formato de archivo.

OTOH, es mucho mejor que la búsqueda de texto 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 la facilidad de uso, por lo que las herramientas están ahí para hacer búsquedas que satisfagan a casi todos.

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


Me alegra ver que alguien habla de Lucene, porque no tengo idea de eso.

Esfinge, por otro lado, lo sé bastante bien, así que veamos si puedo ser de alguna ayuda.

  • La clasificación de relevancia del resultado es la predeterminada. Puede configurar su propia clasificación si lo desea, y asignar a campos específicos mayores ponderaciones.
  • La velocidad de indexación es súper rápida, porque habla directamente con la base de datos. Cualquier lentitud vendrá de consultas SQL complejas y claves externas no indexadas y otros problemas similares. Nunca he notado ninguna lentitud en la búsqueda tampoco.
  • Soy un tipo de Rails, así que no tengo idea de lo fácil que es implementar con Django. Sin embargo, hay una API de Python que viene con la fuente Sphinx.
  • El daemon del servicio de búsqueda (searchd) es bastante bajo en el uso de memoria, y puede establecer límites sobre la cantidad de memoria que utiliza también el proceso del indexador.
  • La escalabilidad es donde mi conocimiento es más incompleto, pero es bastante fácil copiar archivos de índice a múltiples máquinas y ejecutar varios demonios de búsqueda. Sin embargo, la impresión general que recibo de los demás es que es bastante bueno bajo una carga alta, por lo que escalarlo en múltiples 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 bastante facilidad. Sphinx emite palabras clave mediante el uso de diccionarios, por lo que ''conducir'' y ''conducir'' (por ejemplo) se considerarían iguales en las búsquedas.
  • Sin embargo, Sphinx no permite actualizaciones parciales de índice para datos de campo. El enfoque común a 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 en uno o dos segundos). Debido a la pequeña cantidad de datos, esto puede tardar unos segundos. Sin embargo, aún tendrá que volver a indexar el conjunto de datos principal con regularidad (aunque, ¿con qué frecuencia depende de la volatilidad de sus datos, cada día? ¿Cada hora?). Sin embargo, las rápidas velocidades de indexación mantienen todo esto bastante indoloro.

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

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


Me sorprende que no haya 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 esto).

La respuesta en el enlace a continuación detalla algunas cosas sobre Sphinx que también se aplican 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. Soporta replicación
  2. Múltiples núcleos (piense en estos como bases de datos separadas con su propia configuración e índices propios)
  3. Búsquedas booleanas
  4. Resaltado de palabras clave (bastante fácil de hacer en el código de la aplicación si tiene expresiones regulares; sin embargo, ¿por qué no dejar que una herramienta especializada haga un mejor trabajo para usted)?
  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 Word
  8. Campos dinámicos
  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. Sugerencia automática
  15. Cache Autowarming
  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 invertido binario.
  17. Impulso (reglas personalizadas para aumentar la relevancia de una palabra clave o frase en particular, etc.)
  18. Búsquedas de campo (si un usuario de búsqueda conoce el campo que desea buscar, restringe su búsqueda escribiendo el campo, luego el valor, y SOLO ese campo se busca en lugar de todo, mucho mejor experiencia de usuario)

Por cierto, hay toneladas más características; sin embargo, he enumerado solo las características que realmente he usado en producción. BTW, listo para usar, MySQL admite # 1, # 3 y # 11 (limitado) en la lista anterior. Para las características que está buscando, una base de datos relacional no lo va a cortar. Los eliminaría de inmediato.

Además, otro beneficio es que Solr (bueno, Lucene en realidad) es una base de datos de documentos (por ejemplo, NoSQL), por lo que muchos de los beneficios de cualquier otra base de datos de documentos pueden realizarse con Solr. En otras palabras, puede usarlo para más que solo buscar (es decir, Rendimiento). Sé creativo con ello :)


No sé Sphinx, pero en cuanto a Lucene frente a una base de datos de búsqueda de texto completo, creo que el rendimiento de Lucene es incomparable. Debería poder realizar casi cualquier búsqueda en menos de 10 ms, sin importar cuántos registros deba buscar, siempre que haya configurado su índice de Lucene correctamente.

Sin embargo, aquí viene el mayor obstáculo: personalmente, creo que integrar a Lucene en su proyecto no es fácil . Claro, no es demasiado difícil configurarlo para que puedas hacer una búsqueda básica, pero si quieres aprovechar al máximo el rendimiento óptimo, definitivamente necesitas un buen libro sobre Lucene.

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

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


Sólo mis dos centavos a esta pregunta muy vieja. Recomiendo encarecidamente 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, multitenant con una interfaz web RESTful y documentos JSON sin esquema. Elasticsearch se desarrolló en Java y se lanzó como código abierto bajo los términos de la Licencia Apache.

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

  • Interfaz RESTful
  • Mejor escalabilidad
  • Comunidad grande
  • Construido por los desarrolladores de Lucene
  • Amplia documentación
  • Hay muchas bibliotecas de código abierto disponibles (incluyendo Django)

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


SearchTools-Avi dijo "Búsqueda de texto en MySQL, que ni siquiera indexa palabras de tres letras o menos".

Para su información, la longitud mínima de la palabra MySQL en texto completo es ajustable desde al menos MySQL 5.0. Google ''mysql fulltext min length'' para instrucciones simples.

Dicho esto, el texto completo de MySQL tiene limitaciones: por una parte, se actualiza lentamente una vez que alcanza un millón de registros, ...


Yo añadiría mnoGoSearch a la lista. Solución extremadamente eficaz 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, pero satisface las necesidades máximas. Puede compilarlo 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 se ejecuta perfectamente incluso en servidores pequeños.

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

Mientras usas el framework Django, puedes usar o cliente PHP en el medio, o encontrar una solución en Python, vi some articles .

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