Capitulo4 - BDD - Procesamiento de Consultas

Procesamiento de consultas distribuidas
.
• 1.Objetivos del procesamiento de consultas
• 2. Características de los procesadores de
consultas
• 3. Descomposición de consultas y Reducción
de expresiones
Procesamiento de consultas distribuidas.
Objetivo
• El objetivo del procesamiento de consultas distribuidas puede
resumirse de la siguiente manera: dada una consulta de
cálculo en una base de datos distribuida, encuentre una
estrategia de ejecución correspondiente que minimice una
función de costo del sistema que incluya E/S, CPU y costos de
comunicación.
• El éxito de la tecnología de bases de datos relacionales en
el procesamiento de datos se debe, en parte, a la
disponibilidad de lenguajes no procesales (es decir, SQL),
que pueden mejorar significativamente el desarrollo de
aplicaciones y la productividad del usuario final.

• Al ocultar los detalles de bajo nivel sobre la
organización física de los datos, los lenguajes de
bases de datos relacionales permiten la expresión
de consultas complejas de manera concisa y simple.

• En particular, para construir la respuesta a la
consulta, el usuario no especifica con precisión el
procedimiento a seguir. Este procedimiento en
realidad es ideado por un módulo DBMS,
generalmente llamado procesador de consultas.

• Esto libera al usuario de la optimización de
consultas, una tarea que lleva mucho tiempo y que
es mejor manejada por el procesador de consultas,
ya que puede explotar una gran cantidad de
información útil sobre los datos.

• Debido a que es un problema crítico de
rendimiento, el procesamiento de consultas ha
recibido (y continúa recibiendo) considerable
atención en el contexto de los DBMS centralizados y
distribuidos.
• Sin embargo, el problema de procesamiento de
consultas es mucho más difícil en entornos
distribuidos que en los centralizados, porque un
mayor número de parámetros afecta el rendimiento
de las consultas distribuidas.

• En particular, las relaciones involucradas en una consulta
distribuida pueden fragmentarse y / o replicarse, lo que
induce costos generales de comunicación. Además, con
muchos sitios para acceder, el tiempo de respuesta de la
consulta puede ser muy alto.

Problema de procesamiento de consultas
• La función principal de un procesador de consultas
relacionales es transformar una consulta de alto
nivel (típicamente, en cálculo relacional) en una
consulta equivalente de nivel inferior (típicamente,
en alguna variación del álgebra relacional).

• La consulta de bajo nivel realmente implementa la
estrategia de ejecución para la consulta. Una
consulta de cálculo relacional puede tener muchas
transformaciones equivalentes y correctas en
álgebra relacional.
• Dado que cada estrategia de ejecución equivalente
puede conducir a consumos muy diferentes de
recursos informáticos, la principal dificultad es
seleccionar la estrategia de ejecución que minimice
el consumo de recursos.
• Ejemplo 6.1. Consideramos el siguiente subconjunto del
esquema de la base de datos de ingeniería que se
muestra en la Figura 2.3: consumo.

EMP(ENO, ENAME, TITLE)
ASG(ENO, PNO, RESP, DUR)

y la siguiente consulta de usuario simple:
"Encuentra los nombres de los empleados que
gestionan un proyecto"
• La expresión de la consulta en cálculo
relacional utilizando la sintaxis SQL es

SELECT ENAME
FROM EMP,ASG
WHERE EMP.ENO = ASG.ENO
AND RESP = ‘‘Manager’’
• Dos consultas de álgebra relacional equivalentes que son transformaciones
correctas de la consulta anterior son

ПENAME(ϬRESP=“Manager” ⋀ EMP.ENO=ASG.ENO (EMP X ASG))

y

ПENAME(EMP ⋈ ENO (ϬRESP=“Manager” (ASG)))

Es intuitivamente obvio que la segunda consulta, que evita el producto
cartesiano de EMP y ASG, consume muchos menos recursos informáticos que la
primera y, por lo tanto, debe conservarse.

• En un sistema distribuido, el álgebra
relacional no es suficiente para expresar
estrategias de ejecución. Debe
complementarse con operadores para el
intercambio de datos entre sitios.
• Además de la opción de ordenar operadores
de álgebra relacional, el procesador de
consultas distribuidas también debe
seleccionar los mejores sitios para procesar
datos, y posiblemente la forma en que los
datos deben transformarse.
• Esto aumenta el espacio de solución para
elegir la estrategia de ejecución distribuida, lo
que hace que el procesamiento de consultas
distribuidas sea significativamente más difícil.
Caracterización de procesadores de consultas
• Es bastante difícil evaluar y comparar
procesadores de consultas en el contexto de
sistemas centralizados y sistemas distribuidos
porque pueden diferir en muchos aspectos.
• A continuación, enumeramos características
importantes de los procesadores de consultas
que pueden usarse como base para la
comparación.
• Las primeras cuatro características son válidas
para procesadores de consultas centralizados
y distribuidos, mientras que las siguientes
cuatro características son particulares de los
procesadores de consultas distribuidas en
DBMS distribuidos estrechamente integrados.
• Languages
• Inicialmente, la mayoría del trabajo en el
procesamiento de consultas se realizó en el
contexto de DBMS relacionales porque sus
lenguajes de alto nivel le dan al sistema
muchas oportunidades de optimización. El
lenguaje de entrada al procesador de
consultas se basa así en el cálculo relacional.
• Languages
• En un contexto distribuido, el lenguaje de
salida es generalmente una forma interna de
álgebra relacional aumentada con primitivas
de comunicación.
• Types of Optimization
• Conceptualmente, la optimización de consultas
tiene como objetivo elegir el "mejor" punto en
el espacio de solución de todas las estrategias
de ejecución posibles. Un método inmediato
para la optimización de consultas es buscar en
el espacio de la solución, predecir
exhaustivamente el costo de cada estrategia y
seleccionar la estrategia con un costo mínimo.
• Types of Optimization
• En los sistemas centralizados y distribuidos,
una heurística común es minimizar el tamaño
de las relaciones intermedias. Esto se puede
hacer realizando primero operadores unarios
y ordenando los operadores binarios por los
tamaños crecientes de sus relaciones
intermedias.
• Optimization Timing
• Una consulta puede optimizarse en diferentes
momentos en relación con el tiempo real de
ejecución de la consulta. La optimización se
puede realizar de forma estática antes de
ejecutar la consulta o dinámicamente a
medida que se ejecuta la consulta. La
optimización de consulta estática se realiza en
el momento de la compilación de la consulta.
• Optimization Timing
• La optimización de la consulta dinámica
continúa en el momento de la ejecución de la
consulta. En cualquier punto de ejecución, la
elección del mejor operador siguiente puede
basarse en un conocimiento preciso de los
resultados de los operadores ejecutados
previamente.
• Statistics
• La efectividad de la optimización de consultas
se basa en estadísticas en la base de datos. La
optimización dinámica de consultas requiere
estadísticas para elegir qué operadores deben
hacerse primero.
• Decision Sites
• Cuando se utiliza la optimización estática, un solo
sitio o varios sitios pueden participar en la selección
de la estrategia que se aplicará para responder la
consulta. La mayoría de los sistemas utilizan el
enfoque de decisión centralizado, en el que un solo
sitio genera la estrategia. Sin embargo, el proceso de
decisión podría distribuirse entre varios sitios que
participan en la elaboración de la mejor estrategia.
• Explotación de la topología de red
• La topología de la red generalmente es
explotada por el procesador de consultas
distribuido. Con las redes de área amplia, la
función de costo a minimizar puede
restringirse al costo de comunicación de
datos, que se considera el factor dominante.
• Esta suposición simplifica enormemente la
optimización de consultas distribuidas, que se
puede dividir en dos problemas separados: la
selección de la estrategia de ejecución global,
basada en la comunicación entre sitios, y la
selección de cada estrategia de ejecución local,
basada en un algoritmo de procesamiento de
consultas centralizado.
• Con las redes de área local, los costos de
comunicación son comparables a los costos de
E/S. Por lo tanto, es razonable que el
procesador de consultas distribuidas aumente
la ejecución paralela a expensas del costo de
comunicación.
• La mayoría de los algoritmos de optimización
consideran el proceso de localización
independientemente de la optimización. Sin
embargo, algunos algoritmos explotan la
existencia de fragmentos replicados en tiempo
de ejecución para minimizar los tiempos de
comunicación.
Procesamiento de consultas distribuidas. Capas
de procesamiento de consultas
• En la Figura 6.3 se muestra un esquema de
capas genérico para el procesamiento de
consultas donde cada capa resuelve un
subproblema bien definido.
• La entrada es una consulta sobre datos
globales expresados en cálculo relacional. Esta
consulta se plantea en relaciones globales
(distribuidas), lo que significa que la
distribución de datos está oculta.
• Cuatro capas principales están involucradas en
el procesamiento de consultas distribuidas.
Las primeras tres capas mapean la consulta de
entrada en un plan de ejecución de consulta
distribuido optimizado
• Realizan las funciones de descomposición de
consultas, localización de datos y optimización
global de consultas. La descomposición de
consultas y la localización de datos
corresponden a la reescritura de consultas.
• Las primeras tres capas son realizadas por un
sitio de control central y usan información de
esquema almacenada en el directorio global.
La cuarta capa realiza la ejecución de
consultas distribuidas ejecutando el plan y
devuelve la respuesta a la consulta.
Descomposición de consultas
• La primera capa descompone la consulta de
cálculo en una consulta algebraica sobre
relaciones globales. La información necesaria
para esta transformación se encuentra en el
esquema conceptual global que describe las
relaciones globales.
• La descomposición de consultas se puede ver
como cuatro pasos sucesivos. Primero, la
consulta de cálculo se reescribe en una forma
normalizada que sea adecuada para su
posterior manipulación.
• En segundo lugar, la consulta normalizada se
analiza semánticamente para que las
consultas incorrectas se detecten y se
rechacen lo antes posible.
• Tercero, la consulta correcta (aún expresada
en cálculo relacional) se simplifica. Una forma
de simplificar una consulta es eliminar
predicados redundantes.
• Cuarto, la consulta de cálculo se reestructura
como una consulta algebraica.
Procesamiento de consultas distribuidas. Data
Localization
• La entrada a la segunda capa es una consulta
algebraica sobre relaciones globales. La
función principal de la segunda capa es
localizar los datos de la consulta utilizando
información de distribución de datos en el
esquema de fragmentos
Procesamiento de consultas distribuidas. Data
Localization
• Esta capa determina qué fragmentos están
involucrados en la consulta y transforma la
consulta distribuida en una consulta sobre
fragmentos. La fragmentación se define por
predicados de fragmentación que se pueden
expresar a través de operadores relacionales.
Procesamiento de consultas distribuidas. Global
Query Optimization
• La entrada a la tercera capa es una consulta
algebraica sobre fragmentos. El objetivo de la
optimización de consultas es encontrar una
estrategia de ejecución para la consulta que
sea casi óptima. Recuerde que encontrar la
solución óptima es computablemente
intratable.
Procesamiento de consultas distribuidas. Global
Query Optimization
• La optimización de consultas consiste en
encontrar el "mejor" orden de los operadores
en la consulta, incluidos los operadores de
comunicación que minimizan una función de
costo. La función de costo, a menudo definida
en términos de unidades de tiempo, se refiere
a recursos informáticos como espacio en
disco, E/S de disco, espacio de búfer, costo de
CPU, costo de comunicación, etc.
Ejecución de consultas distribuidas
• La última capa es realizada por todos los sitios
que tienen fragmentos involucrados en la
consulta. Cada subconsulta que se ejecuta en
un sitio, llamada consulta local, se optimiza
utilizando el esquema local del sitio y se
ejecuta.
• La descomposición de consultas es la primera
fase del procesamiento de consultas que
transforma una consulta de cálculo relacional
en una consulta de álgebra relacional. Las
consultas de entrada y salida se refieren a
relaciones globales, sin conocimiento de la
distribución de datos.
• Por lo tanto, la descomposición de consultas
es la misma para sistemas centralizados y
distribuidos. Los pasos sucesivos de la
descomposición de la consulta son:
– (1) normalización,
– (2) análisis,
– (3) eliminación de redundancia y
– (4) reescritura.
Descomposición de consultas.
Normalization
• La consulta de entrada puede ser
arbitrariamente compleja, dependiendo de las
facilidades proporcionadas por el idioma. El
objetivo de la normalización es transformar la
consulta en un formulario normalizado para
facilitar el procesamiento posterior.
Analysis
• El análisis de consultas permite el rechazo de
consultas normalizadas para las cuales el
procesamiento posterior es imposible o
innecesario. Los principales motivos de
rechazo son que la consulta es de tipo
incorrecto o semánticamente incorrecto.
Cuando se detecta uno de estos casos, la
consulta simplemente se devuelve al usuario
con una explicación.
Elimination of Redundancy
• Los lenguajes relacionales pueden usarse de
manera uniforme para el control de datos
semánticos. En particular, una consulta de
usuario típicamente expresada en una vista
puede enriquecerse con varios predicados
para lograr correspondencia de relación de
vista y garantizar la integridad y seguridad
semántica.
• La calificación de consulta enriquecida puede
contener predicados redundantes. Una
evaluación ingenua de una calificación con
redundancia puede conducir a un trabajo
duplicado. Dicha redundancia y, por lo tanto,
el trabajo redundante pueden eliminarse
simplificando la calificación con las siguientes
reglas de idempotencia:
• 1. p ⋀ p ⇔ p
• 2. p ⋁ p ⇔ p
• 3. p⋀true ⇔ p
• 4. p ⋁ f alse ⇔ p
• 5. p⋀f alse ⇔ f alse
• 6. p ⋁ true ⇔true
• 7. p ⋀¬p ⇔ f alse
• 8. p ⋁¬p ⇔true
• 9. p1 ⋀ (p1 ⋁ p2) ⇔ p1
• 10. p1 ⋁ (p1 ⋀ p2) ⇔ p1
Reescribiendo
• El último paso de la descomposición de la
consulta reescribe la consulta en álgebra
relacional. En aras de la claridad, es habitual
representar gráficamente la consulta de
álgebra relacional mediante un árbol de
operadores.
Reescribiendo
• Un árbol de operadores es un árbol en el que
un nodo hoja es una relación almacenada en
la base de datos, y un nodo no hoja es una
relación intermedia producida por un
operador de álgebra relacional. La secuencia
de operaciones se dirige desde las hojas a la
raíz, lo que representa la respuesta a la
consulta.
Optimización de consultas
distribuidas
• La selección de la estrategia óptima
generalmente requiere la predicción de los
costos de ejecución de los pedidos de
candidatos alternativos antes de ejecutar
realmente la consulta. El costo de ejecución se
expresa como una combinación ponderada de
E/S, CPU y costos de comunicación.
distribuidas
• Una simplificación típica de los optimizadores
de consultas distribuidas anteriores era
ignorar el costo de procesamiento local (E/S y
costos de CPU) asumiendo que el costo de
comunicación es dominante.
distribuidas
• Las entradas importantes al optimizador para
estimar los costos de ejecución son
estadísticas fragmentarias y fórmulas para
estimar las cardinalidades de los resultados de
las operaciones relacionales.
distribuidas
• La optimización de consultas se refiere al
proceso de producir un plan de ejecución de
consultas (QEP) que representa una estrategia
de ejecución para la consulta. Esta QEP
minimiza una función de costo objetivo.
distribuidas
• Un optimizador de consultas, el módulo de
software que realiza la optimización de
consultas, generalmente se considera que
consta de tres componentes: un espacio de
búsqueda, un modelo de costos y una
estrategia de búsqueda (ver Figura 8.1).
distribuidas
distribuidas
• El espacio de búsqueda es el conjunto de
planes de ejecución alternativos que
representan la consulta de entrada. Estos
planes son equivalentes, en el sentido de que
producen el mismo resultado, pero difieren en
el orden de ejecución de las operaciones y la
forma en que se implementan estas
operaciones, y por lo tanto en su desempeño.
distribuidas
• El modelo de costos predice el costo de un
plan de ejecución dado. Para ser exactos, el
modelo de costos debe tener un buen
conocimiento sobre el entorno de ejecución
distribuida.
distribuidas
• La estrategia de búsqueda explora el espacio
de búsqueda y selecciona el mejor plan,
utilizando el modelo de costos. Define qué
planes se examinan y en qué orden.
distribuidas
• El costo de una estrategia de ejecución
distribuida se puede expresar con respecto al
tiempo total o al tiempo de respuesta. El
tiempo total es la suma de todos los
componentes de tiempo (también
denominado costo), mientras que el tiempo
de respuesta es el tiempo transcurrido desde
el inicio hasta la finalización de la consulta.
distribuidas
• Una fórmula general para determinar el
tiempo total se puede especificar de la
siguiente manera:

• Total time = TCPU * #insts+TI/O * #I/Os+TMSG
* #msgs+TTR * #bytes
distribuidas
• Los dos primeros componentes miden el
tiempo de procesamiento local, donde TCPU
es el tiempo de una instrucción de CPU y TI/O
es el tiempo de una I/O de disco. El tiempo de
comunicación está representado por los dos
últimos componentes. TMSG es el tiempo fijo
de inicio y recepción de un mensaje, mientras
que TTR es el tiempo que lleva transmitir una
unidad de datos de un sitio a otro.
Optimización de consultas distribuidas.
Optimización centralizada de consultas
• En esta sección presentamos las principales
técnicas de optimización de consultas para
sistemas centralizados. Esta presentación es
un requisito previo para comprender la
optimización de consultas distribuidas por tres
razones.
• Primero, una consulta distribuida se traduce
en consultas locales, cada una de las cuales se
procesa de forma centralizada. En segundo
lugar, las técnicas de optimización de
consultas distribuidas son a menudo
extensiones de las técnicas para sistemas
centralizados.
• Finalmente, la optimización centralizada de
consultas es un problema más simple; La
minimización de los costos de comunicación
hace que la optimización de consultas
distribuidas sea más compleja. El tiempo de
optimización, que puede ser dinámico,
estático o híbrido
• Dinámico
• La optimización dinámica de consultas
combina las dos fases de descomposición y
optimización de consultas con la ejecución. El
optimizador de consultas construye
dinámicamente la QEP que realiza llamadas al
motor de ejecución de DBMS para ejecutar las
operaciones de la consulta
• Estática
• Con la optimización de consultas estáticas,
existe una clara separación entre la
generación de QEP en tiempo de compilación
y su ejecución por el motor de ejecución
DBMS. Por lo tanto, un modelo de costo
preciso es clave para predecir los costos de los
QEP candidatos.
• Hibrida
• La optimización de consultas dinámicas y
estáticas tienen ventajas y desventajas. La
optimización dinámica de consultas combina
optimización y ejecución y, por lo tanto, puede
tomar decisiones de optimización precisas en
tiempo de ejecución.
• Hibrida
• Sin embargo, la optimización de la consulta se
repite para cada ejecución de la consulta. Por
lo tanto, este enfoque es mejor para consultas
ad-hoc.

Capitulo4 - BDD - Procesamiento de Consultas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capitulo4 - BDD - Procesamiento de Consultas

Cargado por

Copyright:

Formatos disponibles

Procesamiento de consultas distribuidas

• El objetivo del procesamiento de consultas distribuidas puede

resumirse de la siguiente manera: dada una consulta de

cálculo en una base de datos distribuida, encuentre una

estrategia de ejecución correspondiente que minimice una

función de costo del sistema que incluya E/S, CPU y costos de

• El éxito de la tecnología de bases de datos relacionales en

el procesamiento de datos se debe, en parte, a la

disponibilidad de lenguajes no procesales (es decir, SQL),

que pueden mejorar significativamente el desarrollo de

aplicaciones y la productividad del usuario final.

• Al ocultar los detalles de bajo nivel sobre la

organización física de los datos, los lenguajes de

bases de datos relacionales permiten la expresión

de consultas complejas de manera concisa y simple.

• En particular, para construir la respuesta a la

consulta, el usuario no especifica con precisión el

procedimiento a seguir. Este procedimiento en

realidad es ideado por un módulo DBMS,

generalmente llamado procesador de consultas.

• Esto libera al usuario de la optimización de

consultas, una tarea que lleva mucho tiempo y que

es mejor manejada por el procesador de consultas,

ya que puede explotar una gran cantidad de

información útil sobre los datos.

• Debido a que es un problema crítico de

rendimiento, el procesamiento de consultas ha

recibido (y continúa recibiendo) considerable

atención en el contexto de los DBMS centralizados y

• Sin embargo, el problema de procesamiento de

consultas es mucho más difícil en entornos

distribuidos que en los centralizados, porque un

mayor número de parámetros afecta el rendimiento

de las consultas distribuidas.

• En particular, las relaciones involucradas en una consulta

distribuida pueden fragmentarse y / o replicarse, lo que

induce costos generales de comunicación. Además, con

muchos sitios para acceder, el tiempo de respuesta de la

consulta puede ser muy alto.

• La función principal de un procesador de consultas

relacionales es transformar una consulta de alto

nivel (típicamente, en cálculo relacional) en una

consulta equivalente de nivel inferior (típicamente,

en alguna variación del álgebra relacional).

• La consulta de bajo nivel realmente implementa la

estrategia de ejecución para la consulta. Una

consulta de cálculo relacional puede tener muchas

transformaciones equivalentes y correctas en

• Dado que cada estrategia de ejecución equivalente

puede conducir a consumos muy diferentes de

recursos informáticos, la principal dificultad es

seleccionar la estrategia de ejecución que minimice

También podría gustarte