Desde hace algún tiempo, estaba pensando en hacer un buscador que indizara una gran cantidad de texto para comprobar que problemas reales se tienen cuando se trata con cantidades ingentes de información. Para ello habia dos opciones, escoger una base de datos con muchos registros o escoger una con menos registros pero si una cantidad grande de texto por cada uno de ellos.
Pero, ¿Cuantos son muchos registros?. Respecto a temas de indización y búsquedas de texto completo considero imposible (en cuanto a rendimiento) seguir usando el motor FULLTEXT de MySQL a partir de unos 300.000 registros.
Se sopesaron las diferentes bases de datos (por supuesto, libres) que podrían usarse para este estudio y se llego a dos en concreto:
- Wikipedia: unos 200.000 registros con mucho texto
- FreeDB: alrededor de 1.000.000 con poco texto
Teniendo en cuenta, que el FreeDB tiene muchos resultados duplicados y poco texto (que afearía un poco los resultados), decidí aventurarme por la wikipedia en castellano. El idioma también fue un detonante, ya que tenia intención de aplicarle despues un stemmer en castellano.
Al llegar a este punto solo queda definir las fases:
- Descarga e importación de la base de datos
- Configuración y construcción de los índices
- Creación de un pequeño sitio web para el buscador
Descarga e importación de la base de datos
La Wikipedia ofrece la descarga de unos dump de base de datos en formato xml (y algunos en sql), que luego pueden ser importados a la base de datos que tengamos de mediawiki. La página que explica todo esto es http://en.wikipedia.org/wiki/Wikipedia:Database_download.
Para ver que parte de la wikipedia necesitaba y no descargar absolutamente todo (pesa bastante), eché un ojo a este esquema de la base de datos .
Las tablas necesarias son únicamente:
- text: contiene el texto de las páginas
- page: contiene los titulos y ciertos parámetros como si es redirección o el espacio de nombres
- revision: contiene la referencia de revisiones
Los dump en castellano en cuestión se pueden bajar de http://download.wikimedia.org/eswiki/latest/.
Ponemos a bajar el dump que nos vale eswiki-latest-pages-articles.xml.bz2
Para poder crear las tablas de MySQL a partir del dump se tuvo que usar las herramientas de las que provee el propio software de MediaWiki. Así que tras descargarlo y desempaquetarlo, se configuran los parametros de acceso en el archivo LocalSettings.php y mediante el script importDump.php se rellenan las tablas deseadas tal y como se explica aqui.
Configuración y construcción de los índices
Aquí llega la parte seria, se va a indizar una tabla de 1GB de texto. Puntos interesantes a estudiar:
- Tamaño del índice
- Tiempo de construcción
- Tiempo de consulta del índice para consultas simples
- Tiempo de consulta del índice para consultas complejas (booleanas, frase...)
La herramienta que se va a usar es Sphinx, porque es la que conozco (obvio pero importante) y porque mas que el medio en este estudio ella es el fín. Es decir, lo que quiero demostrar es que esta herramienta es muy rápida aun cuando la cantidad de información es muy grande.
Se definen dos índices: uno para el título del artículo y otro para el contenido.
Definicion del titulo
CODE:
-
source titulosrc
-
{
-
type = mysql
-
sql_host = host
-
sql_user = user
-
sql_pass = pass
-
sql_db = wikidb
-
sql_port = 3306
-
sql_query_pre =
-
sql_query = \
-
SELECT page_id, page_title \
-
FROM page WHERE page_namespace = 0 \
-
AND page_is_redirect = 0
-
-
}
-
-
index titulo
-
{
-
source = titulosrc
-
path = /ruta-sphinx/var/data/titulo
-
docinfo = extern
-
morphology = none
-
min_word_len = 1
-
charset_type = utf-8
-
charset_table = 0..9, A..Z->a..z, a..z, U+C9->U+E9, U+C1->U+E1, \
-
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
-
U+E9, U+FA, U+F1, U+F3, U+ED
-
}
Definicion del contenido
CODE:
-
source contenidosrc
-
{
-
type = mysql
-
sql_host = host
-
sql_user = user
-
sql_pass = pass
-
sql_db = wikidb
-
sql_port = 3306
-
sql_query_pre =
-
sql_query = \
-
SELECT page_id, page_title,old_text \
-
FROM page,revision,text \
-
WHERE page_id = rev_page AND \
-
rev_text_id = old_id AND \
-
page_namespace = 0 \
-
AND page_is_redirect = 0
-
}
-
index contenido
-
{
-
source = contenidosrc
-
path = /ruta-sphinx/var/data/contenido
-
docinfo = extern
-
morphology = none
-
min_word_len = 1
-
charset_type = utf-8
-
charset_table = 0..9, A..Z->a..z, _,a..z, U+C9->U+E9, U+C1->U+E1, \
-
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
-
U+E9, U+FA, U+F1, U+F3, U+ED
-
}
Ahora toca crear los índices con el indexer de sphinx. Y es justo aqui cuando me llevo una sorpresa desagradable: tarda muchísimo en general en índice de contenido, unos 15 minutos. Los índices generados ocupan 4.1 megas el del titulo, y 530 megas el del contenido.
Creación de un pequeño sitio web para el buscador
El site se ha hecho plagiando al amigo google un poco (y a todos en general) e intentando que tuviera el interfaz más simple posible. El buscador de la wikipedia permite hacer consultas sin saber absolutamente nada sobre tecnología (aparte claro, de rellenar un campo y darle a buscar) pero posibilita también a la vez el uso de consultas avanzadas. Para ello se usa el modo de consulta extendido.
La función de query a sphinx tiene esta pinta:
PHP:
-
function querySPHINX($tag,$indice,$off=0)
-
{
-
$port = 3312;
-
-
$cl = new SphinxClient ();
-
$cl->SetServer ( "localhost", $port );
-
$cl->SetLimits ($off, 10 );
-
$cl->SetMatchMode ( SPH_MATCH_EXTENDED );
-
$resultado = $cl->Query ( $tag, $indice );
-
$num_encontrados = $resultado['total_found'];
-
-
-
if($num_encontrados!=
0 &&
is_array($resultado) &&
is_array($resultado["matches"]))
-
{
-
//como los ids resultantes son los indices, se devuelve con array_keys
-
-
}
-
else
-
{
-
return false;
-
}
-
}
Las consultas normales llevan un AND implícito: si consultamos seat ibiza sobre el titulo veremos que solo nos saca el resultado que tiene las dos palabras a diferencia de seat | ibiza
Se pueden negar términos. Poniendo un - se pueden excluir palabras de la búsqueda. Por ejemplo si buscamos ibiza obtendremos unos resultados normales pero si ponemos ibiza -seat -dama -ciudad -isla tendremos unos resultados mucho más filtrados.
Es posible hacer busquedas de frase poniendo comillas. Entonces no sólo se buscarán todas las palabras sino que además deberán estar en el mismo orden. Esto permite hacer busquedas de fragmentos mayores (sobre el contenido) "Proverbios que dicen las viejas tras el fuego".
Por último, se dispone de un tipo de consulta, a mi juicio muy útil y potente que es el modo de frase por proximidad. Si el modo de frase buscaba una serie de palabras juntas y en un orden concreto, el modo por proximidad añade un cuantificador que permite que las palabras no estén exactamente igual a la frase pero si cerca. Pero ¿Cuánto de cerca?, pues es configurable. Si hacemos la consulta "kernel linux" se obtendrán los resultados que en el contenido tengan "kernel linux" y en cambio para "kernel linux"~5 se recogerán los resultados de los artículos que tengan las palabras kernel y linux en una distancia máxima de 5 palabras.
Se ha añadido también un pequeño informe de tiempos de ejecución que establece tres fases a medir:
- Consulta a sphinx: tiempo de query a sphinx. Es realmente el parametro a estudiar
- Recuperación de datos: tiempo de recogida de la información de la base de datos.
- Salida a pantalla: construcción de resúmenes (sólo en caso de contenido) e impresión por pantalla
En este informe podemos ver lo realmente rápido que es sphinx, teniendo en cuenta que una búsqueda en el contenido (que es el índice grande) tarda del orden de 2 milisegundos. No es nada comparado con los 20 milisegundos que le cuesta construir los resúmenes y escupir por pantalla la información.
Datos obtenidos
Los tiempos que se ponen a continuación son los de búsqueda en sphinx siempre sobre el índice de contenido y no incluyen en el tiempo ni consulta a base de datos ni impresión por pantalla.
Conclusiones
Sphinx es realmente rápido para búsquedas de texto completo aun cuándo se tiene un índice muy grande. Además nos provee de unos modos de búsqueda avanzada muy útiles al introducir unos operadores muy fáciles e intuitivos. Pero no todo es bueno, el tiempo que se tardó en construir el índice es, a mi juicio, excesivo ( revisaré los parámetros por si es cosa mía, que también es posible).
Por hacer
En breve se le harán un par de retoques al buscador pero adelanto que se le incorporará un stemmer de castellano que yo mismo hice para sphinx. Es posible que escriba las consultas para motor fullext de mysql y postee la comparativa de resultados. Tampoco descarto, ahora que ya tengo la base de datos montada, probar otras alternativas como CLucene. No estaría de más convertir el código de wiki a html en los resúmenes de los resultados (que pereza).