Procesamiento de consultas

El éxito creciente de la tecnología de bases de datos relacionales en el procesamiento de datos se debe, en parte, a la disponibilidad de lenguajes no procedurales los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la productividad del usuario final. Ocultando los detalles de bajo nivel acerca de la localización física de datos, los lenguajes de bases de datos relacionales permiten la expresión de consultas complejas en una forma concisa y simple. Particularmente, para construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un módulo del DBMS llamado el procesador de consultas (query processor).

Dado que la ejecución de consultas es un aspecto crítica en el rendimiento de un DBMS, el procesamiento de consultas ha recibido una gran atención tanto para bases de datos centralizadas como distribuidas. Sin embargo, el procesamiento de consultas es mucho más difícil en ambientes distribuidos que en centralizados, ya que existe un gran número de parámetros que afectan el rendimiento de las consultas distribuidas. En este capítulo revisaremos el procesamiento de consultas para bases de datos distribuidas.

4.1 El problema de procesamiento de consultas

La función principal de un procesador de consultas relacionales es transformar una consulta en una especificación de alto nivel, típicamente en cálculo relacional, a una consulta equivalente en una especificación de bajo nivel, típicamente alguna variación del álgebra relacional (ver Figura 4.1). La consulta de bajo nivel implementa de hecho la estrategia de ejecución para la consulta. La transformación debe ser correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semántica que la consulta original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien definido que se conoce entre el cálculo relacional y el álgebra relacional hace que la correctitud de la transformación sea fácil de verificar. Sin embargo, producir una estrategia de ejecución eficiente es mucho más complicado. Una consulta en el cálculo relacional puede tener muchas transformaciones correctas y equivalentes en el álgebra relacional. Ya que cada estrategia de ejecución equivalente puede conducir a consumos de recursos de cómputo muy diferentes, la dificultad más importante es seleccionar la estrategia de ejecución que minimiza el consumo de recursos.

Figura 4.1. Procesamiento de consultas.

Ejemplo 4.1. Considere el siguiente subconjunto del esquema de la base de datos de ingeniería que se presentó en el capítulo 2

E( ENO, ENOMBRE, TITULO )

G( ENO, JNO, RESPONSABLE, JORNADA )

y la siguiente consulta de usuario:

"Encuentre todos los nombres de empleados que manejan un proyecto"

La expresión de la consulta en SQL se puede ver como

SELECT ENOMBRE

FROM E, G

WHERE E.ENO = G.ENO AND RESPONSABLE = "ADMINISTRADOR"

Dos consultas equivalentes en el álgebra relacional que son transformaciones correctas de la consulta en SQL son:

y

Como es intuitivamente obvio, la segunda estrategia que evita calcular el producto cartesiano entre E y G, consume mucho menos recursos que la primera y, por lo tanto, es mejor.

•

En un contexto centralizado, las estrategias de ejecución de consultas pueden ser bien expresadas como una extensión del álgebra relacional. Sin embargo, en sistemas distribuidos, el álgebra relacional no es suficiente para expresar la ejecución de estrategias. Debe ser complementada con operaciones para el intercambio de datos entre nodos diferentes. Además de elegir el orden de las operaciones del álgebra relacional, el procesador de consultas distribuidas debe seleccionar también los mejores sitios para procesar datos y posiblemente la forma en que ellos tienen que ser transformados.

Ejemplo 4.2. Considere la siguiente consulta del Ejemplo 4.1:

Supongamos que las relaciones E y G están fragmentadas horizontalmente como sigue:

E1 =  ENO  "E3" (E)

E2 =  ENO > "E3" (E)

G1 =  ENO  "E3" (G)

G2 =  ENO > "E3" (G)

Los fragmentos E1, E2, G1 y G2 están almacenados en los nodos 1, 2, 3 y 4, respectivamente, y el resultado se quiere en el nodo 5. En la Figura 4.2 se presentan dos estrategias distribuidas de ejecución diferentes para la misma consulta (se ha ignorado el operador de proyección por simplicidad del ejemplo). La estrategia A explota el hecho de que las relaciones E y G están fragmentadas de la misma manera y ejecuta la operación de selección y junta en paralelo. La estrategia B centraliza todos los datos en el nodo resultante antes de procesar la consulta.

Para evaluar el consumo de recursos, se usará un modelo de costo simple. Suponga que el costo de acceso a un tuplo (tupacc) es 1 unidad, y la transferencia de un tuplo (tuptrans) tiene un costo de 10 unidades. Suponga que las relaciones E y G tienen 400 y 1000 tuplos, respectivamente, y que existen 20 administradores en la relación G. También, suponga que los datos están uniformemente distribuidos entre los nodos. Finalmente, suponga que las relaciones G y E están agrupadas localmente en los atributos RESP y ENO, respectivamente, de manera que, hay un acceso directo a los tuplos de G y E, respectivamente.

El costo de la estrategia A se puede derivar como sigue:

Figura 4.2. Estrategias de ejecución distribuida equivalentes.

El costo de la estrategia B se puede derivar como sigue:

La estrategia A es mejor por un factor de 37, lo cual es significativo. La diferencia sería aún mayor si se hubiera asumido un costo de comunicación mayor y/o un grado de fragmentación mayor.

•

4.2

...