Control de Concurrencia sobre ındices invertidos

Control de Concurrencia sobre ı́ndices invertidos
Carolina Bonacic
Mauricio Marı́n
Departamento Cs. Computación, Universidad de Chile
Departamento de Computación, Universidad de Magallanes, Chile *
Abstract
Basado en una estrategia de control de concurrencia para ı́ndices invertidos, en el presente artı́culo se discute
la introducción de una nueva operación sobre el ı́ndice; este proceso esta basado en el modelo de computaci ón
paralela BSP. Además, se analiza la eficiencia y balance de los procesadores bajo este contexto.
1. Introducción
Una arquitectura para máquinas de búsqueda en la Web, presenta una serie de componetes básicos; entre ellos
se encuentran el: crawler (recorre la Web buscando las páginas a indexar), indexador (mantiene un ı́ndice con esa
información), máquina de consultas (realiza las búsquedas en el ı́ndice) y la interfaz (interactúa con el usuario).
Bajo este contexto, un indexador para la Web usualmente esta construido por variantes del ı́ndice invertido [1],
que son populares estructuras de datos frecuentemente usadas en bases de datos textuales. Estan formados por un
conjunto de términos del texto y una lista de documentos donde aparecen éstos.
En muchos casos, por bueno que sea el algoritmo de indexación, no es suficiente para: texto demasiado grande;
la frecuencia de actualización es muy alta; llegan muchas consultas por segundo; la velocidad de los discos no
está creciendo al ritmo necesario. Una alternativa a esto es utilizar paralelismo; frente a este punto se trabajó con
el modelo de computación paralela BSP [8, 9], donde es factible expandir la capacidad de procesamiento tanto
como se quiera.
El caso tı́pico es tener operaciones de sólo lectura sobre el ı́ndice. Sin embargo, en aplicaciones tales como
servicios de noticias es deseable poder incluir nuevo texto a medida que se generan nuevas noticias y mezclar
este proceso con las consultas de lectura de los usuarios. Esto trae consigo un problema de concurrencia sobre el
ı́ndice.
Recientemente en [7] se ha encontrado un algoritmo eficiente de control de concurrencia para ı́ndices invertidos.
El algoritmo propuesto en [7] permite realizar las operaciones de lectura y escritura de manera eficiente y toma
ventaja de la propiedad de sincronización global de procesadores que aporta BSP. Bajo este criterio, el presente
artı́culo abordará la inclusión de una nueva operación sobre el ı́ndice, la cual tiene relación con la eliminación
concurrente de texto.
2. Modelo BSP para computación paralela
El modelo BSP puede ser visto como un modelo de programación, donde se describe el punto de vista del
programador del sistema distribuido o paralelo, o como un modelo de computación utilizado en el diseño de
algoritmos, el cual tiene asociado un modelo de costos.
*
Contact e-mail: mauricio.marin@umag.cl
La idea fundamental de BSP [8, 9], es la división entre computación y comunicación. Se define un sstep como
una operación básica que se realiza sobre datos locales de un procesador. Todo programa BSP consiste en un
conjunto de estos pasos, denominados superstep, en los cuales, existe una fase de computación local independiente,
le sigue una fase global de comunicaciones y finalmente una sincronización por barrera que permite separar los
diferentes superstep.
Un acercamiento más común a la programación BSP, es la programación imperativa SPMD (Single Program
Multiple Data) con funcionalidades de BSP provistas por llamadas a librerı́as, donde un programa BSP es iniciado
por el usuario en una máquina, y luego este programa se duplica automáticamente en las máquinas restantes que
conforman la red. Cada uno ejecuta el mismo código pero con sus datos locales. Entre las librerias más comunes
se encuentran: BSP lib [4] ó BSP pub [6]
El costo en tiempo de un programa en BSP esta dado por una suma acumulativa de costos en cada superstep y
el costo de cada superstep, el la suma de los parámetros: w, h, g y l, donde w es el máximo de computación por
cada procesador, h es el máximo de mensajes enviados/recibidos por cada procesador con cada palabra costando g
unidades de tiempo, y l es el costo de una sincronización por barrera en el procesador. El efecto de la arquitectura
del computador esta incluida en los parámetros g y l, relacionados en función de p. Estos valores permiten que la
velocidad de los procesadores s pueda ser empı́ricamente determinada [8].
3. Trabajo Previo
El desarrollo de este trabajo es parte del diseño de un buscador basado en una estrategia de crawling [3] y en
un ı́ndice invertido [7].
Se ha mostrado experimentalmente en [3] que aquellas estrategias que recorren el grafo de la Web aplicando la
táctica de recorrido por profundidad, son capaces de recuperar las páginas relevantes casi tan eficientemente como
las basadas en métodos mas complejos y de gran costo en tiempo computacional como el llamado page-rank.
Los documentos recuperados durante el proceso de crawling son indexados para luego ser puestos al servicio
de un buscador como google [5].
El proceso de crawler [2], comienza trabajando con un conjuto de páginas raiz (home page), descargándolas y
extrayendo sus enlaces.
La estratégia del scheduler esta basada en una cola de prioridad donde los nodos representan los sitios y las
prioridades estan dadas por las páginas asociadas a los sitios. Por cada nodo-sitio se tiene otra cola donde se
mantiene la página que determina la prioridad del nodo en ese sitio.
En el proceso de simulación del scheduler, se escoge el website desde la cola de sitios web y se envia la
información de esos sitios al módulo que simulará la descarga de páginas desde el websitie.
La idea de este diseño es tener un crawler que sea capaz de procesar rápidamente los documentos que va
recibiendo y a la vez reducir el tiempo requerido para indexar los resúmenes de cada documento. Mas aún, es
deseable que a medida que se generan los nuevos resúmenes de documentos estos se pongan a disposición de
los usuarios del buscador inmediatamente y de manera concurrente. Todo esto para hacer que las respuestas a los
usuarios del buscador hagan referencia a copias lo más recientes posible de los respectivos documentos disponibles
en la Web.
Una combinación de crawler y buscador concurrente puede sin dudas reflejar de mejor manera los requerimientos de la Web, los cuales se caracterizan por ser un sistema altamente dinámico y de rápido crecimiento (las
páginas aparecen y desaparecen de manera indeterminada).
4. Listas Invertidas
Como se mencionó, una lista invertida es la estructura de datos más elemental para la recuperación de palabras
[1]. Se caracterisa por tener operaciones de solo lectura, pero en aplicaciones más especı́ficas como en sistemas de
noticias, se importante manejar las actualizaciones de los documentos.
El proceso de actualización o eliminación de documentos, tiene relación con los resúmenes recuperados por
el proceso de crawling. Para realizar esta acción, primero se debe verificar si existe una versión antigua de ese
documento en el ı́ndice. Si ese es el caso, se elimina ésta y luego se inserta la nueva versión. Antes se recorre el
documento antiguo para obtener las palabras de su vocabulario y luego se debe ir a las respectivas listas invertidas
asociadas a ese vocabulario, para remover las referencias del documento antiguo. El broker deberı́a enviar la
eliminación e inserción del documento de manera consecutiva para que entremedio no exista una consulta de
lectura que pase por alto la existencia del documento siendo insertado/eliminado.
4.1. Implementación del Algoritmo
El ı́ndice general se encuentra distribuido de manera uniforme en los p procesadores. A cada procesador se le
entrega un conjunto de instrucciones a ejecutar. El proceso de lectura de consulta e indexaciones de documentos,
finaliza, cuando ya no se envı́an más instrucciones a los procesadores.
En la rutina principal, se extraen los mensajes de la cola de entrada y dependiendo del tipo, se envia al método
que corresponde:
void Procesador::run()
{
Mensaje *m;
while( msgin->empty() == false)
{
// Extrae el siguiente mensaje de la Cola.
m = (Mensaje*)msgin->top();
msgin->pop();
switch(m->tipo)
{
case MSG_QUERY:
// manejo de consultas de lectura.
case MSG_QUERY_1: // punto de acceso al indice general.
case MSG_QUERY_2: // ranking final
runQUERY(m);
break;
case MSG_INDEX:
case MSG_INDEX_1:
// insercion de un nuevo documento.
// punto de acceso al indice general.
runINDEX(m);
break;
default:
printf("ERROR switch - Procesador::run()\n");
}
} // while
} // fin de run()
Consultas tipo Lectura
supersteps.
Llega una consulta que debe ser resuelta utilizando el ı́ndice general. Esto toma tres
Superstep1
Para cada query de p , ésta se divide s en términos.
Cada término se distribuye de manera uniforme entre los p procesadores: H(s ) = p
Superstep2
De cada término recibido, se busca su repectiva listas invertida desde el ı́ndice general.
De cada una de estas listas, se extraen los K mejores elementos.
Toda la información recuperada en los pasos anteriores, es enviada al procesador que separó los términos de
la consulta.
En esta etapa tanto las lecturas (consultas) como las escrituras (inserción de documentos) se deben sincronizar
por medio de un timestamps.
Superstep3
Una vez verificado que han llegado todos los términos de la consulta al procesador actual, se realiza el
proceso de ranking.
Se entrega los k documentos de respuesta al usuario.
Consultas tipo Escritura Llega una solicitud para indexar un documento, ya sea nuevo o una actualización del
mismo, equivalente a la eliminación de un documento.
Primero se indexa el documento solo y luego se actualiza el ı́ndice general. Este proceso toma dos supersteps:
Superstep1
Del documento a indexar, se forma su ı́ndice particular.
Por cada w del ı́ndice, se obtiene su lista invertida.
Se envia al p la palabra w más su respectiva lista invertida.
Superstep2
for(w[i] de P[i])
{
if(archivo ya indexado)
{
if(w[i] esta en el indice general)
se descarta w[i]
else
insertaIndiceGeneral(w[i] + lista invertida)
}
else
actualizaIndiceGeneral(w[i] + lista invertida)
}
insertaIndiceGeneral: almacena en el ı́ndice general w más su lista invertida.
actualizaIndiceGeneral: si w ya se encuentra en el ı́ndice, se aumenta su frecuencia; sino se inserta w más
su lista invertida.
5. Resultados Empı́ricos
El objetivo de realizar una serie de experimentos y mediciones sobre el algoritmo propuesto, es para verificar
que los tiempos de respuesta disminuyen a medida que se trabaja con más procesadores. Además es necesario, ver
la carga de trabajo de cada máquina, i.e., que haya un buen balance de carga.
De las operaciones ejecutadas sobre el ı́ndice invertido, la más reelevante a medir es la escritura, principalmente
porque en ella se manipula el ı́ndice general y la cantidad de información que se maneja es mucho más alta, por lo
ésta abarca un tiempo mayor de ejecución.
Las mediciones se efectuaron sobre una colección de texto xml y se ejecutaron del orden de 90.000 consultas
por cada procesador.
La figura 1 muestra el tiempo promedio de ejecución de un conjunto de consultas de tipo escritura. Claramente
se puede apreciar que los tiempos de ejecución del algoritmo paralelo van disminuyendo a medida que aumenta la
cantidad de consultas; además, los tiempos decrecen mientras mayor sea el número de procesadores que trabajan,
esto trae como consecuencia poder afirmar, que el algoritmo paralelo propuesto es escalable.
Sumado a lo anterior, la figura 2 muestra la eficiencia de procesar el mismo número de consultas analizado
anteriormente, es quiere decir, que los procesadores trabajan en promedio lo mismo.
Además de analizar el tiempo de ejecución, es necesario examinar que ocurre con la cantidad de mensajes que
se transmite por superstep en cada procesador. De acuerdo a lo observado en la figura 3, el trabajo realizado en
cada máquina tiende a 1, lo que implica que la distribución de mensajes esta correcta, i.e., existe un buen balance
de carga, los procesadores reciben en promedio la misma cantidad de mensajes a ejecutar.
600
500
P= 1
P= 4
P= 8
P= 16
Tiempo de Ejecucion
400
300
200
100
0
0
0.1
0.2
0.3
0.4
Porcentaje Escrituras
0.5
0.6
0.7
0.6
0.7
Figura 1. Tiempos de Ejecución
1
0.8
Eficiencia
0.6
P= 4
P= 8
P= 16
0.4
0.2
0
0
0.1
0.2
0.3
0.4
Percentaje Escrituras
0.5
Figura 2. Tamaño de los mensajes
1
0.8
Eficiencia
0.6
P= 4
P= 8
P= 16
0.4
0.2
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Porcentaje Escrituras
Figura 3. Balance de carga
6. Conclusiones
Con el incremento de la Web, es deseable tener una arquitectura de máquinas de búsqueda capaz de entregar y
procesar información de forma eficiente y rápida.
Para ello, en este trabajo se analizó el comportamiento del indexador, al momento de recibir información por
parte del crawler. Este le enviaba los resúmenes extraidos de las páginas recuperadas (operación equivalente a una
escritura) y a su vez recibia las consultas hechas por los usuarios (lecturas).
Los datos obtenidos, muestran que el algoritmo paralelo aquı́ planteado entrega óptimos resultados, principalmente por la disminusión de los tiempos de respuesta al usuario. El trabajar con un número considerable de
procesadores, refleja que el algoritmo es escalable y se verifica tambien que la distribución de trabajo en cada
procesador se encuentra bien balanceada.
Por lo tanto, es factible mantener una arquitectura de máquinas de búsqueda, donde el trabajo del indexador sea
entregar páginas más frescas al usuario debido al manejo de la concurrencia de las consultas.
Referencias
[1] R. Baeza-Yates and B. Ribeiro. Modern information retrieval. Addison-Wesley, 1999.
[2] C. Castillo and R. Baeza-Yates. A new model for web crawling. 2000.
[3] C. Castillo, M. Marı́n, A. Rodriguez, and R. Baeza-Yates. Scheduling algorithms for web crawling. To be
submitted, 2004.
[4] http://www.bsp worldwide.org. Bsp and worldwide standard.
[5] http://www.google.com. Google search engine.
[6] http://www.uni paderborn.de/bsp. Bsp pub library at paderborn university.
[7] M. Marı́n. Fats concurrency control algorithm for inverted files. To be submitted, 2004.
[8] D.B. Skillicorn, J.M.D. Hill, and W.F. McColl. Questions and answers about BSP. Technical Report PRGTR-15-96, Computing Laboratory, Oxford University, 1996. Also in Journal of Scientific Programming, V.6
N.3, 1997.
[9] L.G. Valiant. A bridging model for parallel computation. Comm. ACM, 33:103–111, Aug. 1990.