Vistas Materializadas - Optimización de Bases de Datos

Vistas Materializadas en la Optimización de

Bases de Datos
Wilmer Urueña Bejarano, Ruben Pinedo Guerra, Jeyson Acero Acero, Harlin Acero Acero
Optimización de Bases de Datos
Universidad de Bogotá Jorge Tadeo Lozano
rubenr.pinedog@utadeo.edu.co, wilmar.uruenab@utadeo.edu.co, jeyson.aceroa@utadeo.edu.co,
harlinf.acero@utadeo.edu.co

Resumen- La optimización o afinamiento de las bases de datos es su puesto, tales beneficios requieren también algunos
la tarea de mantener o mejorar el rendimiento del sistema para sacrificios, los cuales se presentan en las secciones
presentar la información solicitada en el menor tiempo posible. posteriores.
Para lograr este objetivo existen diferentes técnicas y
herramientas entre las que se encuentra el uso de las vistas
materializadas.
Una vista materializada es el resultado de una consulta que se
almacena de forma física en el motor de bases de datos. A
diferencia de las vistas comunes que almacenan únicamente la
estructura de una consulta y deben ejecutarse para reproducir el
resultado de la misma, las vistas materializadas utilizan un
espacio en caché, con el fin de almacenar el resultado de una
consulta y mantenerlo disponible.
Las vistas materializadas suelen utilizarse en el afinamiento de Beneficios de las Vistas Materializadas
bases de datos para reducir el tiempo de respuesta en consultas
frecuentes y costosas. Como se ya se ha mencionado, las vistas en general
En el presente documento se exponen las ventajas del uso de las proporcionan grandes beneficios entre los que se encuentran:
vistas materializadas en el contexto de la optimización de las
bases de datos.
● Acceso Restringido a los datos: El uso de una vista
permite a los usuarios conocer, si así se desea, solo algunas
I. INTRODUCCIÓN columnas o registros de una o unas tablas.

El crecimiento exponencial en la recolección de información
ha presentado un problema para el rendimiento de los motores
de bases de datos. Sin embargo, a la par del crecimiento de los
datos, se han desarrollado diferentes técnicas y herramientas
que ayudan a mitigar o solucionar dichos problemas.
En el mundo de las bases de datos, un objeto bastante común
son las vistas, las cuales almacenan la estructura de una
consulta y la presentan en forma de tabla virtual. Sin embargo,
existe un tipo especial de vistas, las vistas materializadas, que
difieren fundamentalmente de las primeras por que almacenan
el resultado de la consulta en una tabla en caché y que pueden
ser actualizadas a petición o por demanda a partir de la
información real de las tablas de origen.
II. CONCEPTO DE LAS VISTAS MATERIALIZADAS
A diferencia de las vistas comunes que solamente guardan los
la estructura de las consultas más no sus resultados, las vistas
materializadas almacenan, además de la sentencia SQL, el
resultado mismo de la consulta en el caché del servidor, lo que
permite un acceso más rápido a la información, pues al
ejecutar dicha vista, el motor no necesita ir hasta las tablas
originales para solicitar los datos, ni debe ejecutar los costosos
joins, en su lugar, el motor solo debe consultar una tabla, la
tabla que ha sido creada gracias a la vista materializada. Por
● Simplificación en el acceso a los datos: una consulta
que utiliza funciones, campos calculados y/o accesos a más de
una tabla, puede ser encapsulada dentro de una vista, de manera
tal que, cuando se necesite consultar dicho reporte, en lugar de
llamar nuevamente a las tablas de origen y hacer que el motor
vuelva a ejecutar este trabajo, se llame únicamente a la vista,
convirtiendo lo que pueden ser decenas o incluso centenas de
líneas, en una sola.
● Seguridad del modelo de bases de datos: el uso de las
vistas permite encapsular los detalles más relevantes de una
consulta a los ojos del usuario final. Así, en lugar de presentar
al usuario final el nombre de las tablas base y los campos que
las componen basta con exponer el nombre de la vista para que
solo usuarios permitidos puedan acceder a los resultados de la
consulta.
Ahora bien, a diferencia de las vistas comunes, las vistas
materializadas usan algunos conceptos diferentes como son:
● Almacenamiento real en memoria: Como se ha dicho
ya en párrafos anteriores, las Vistas Materializadas almacenan,
además de la sentencia, el resultado de la consulta, evitando
que el motor tenga que ir hasta las tablas base y hacer los
cálculos antes mencionados.
● Reducción del Plan de Ejecución: en el mismo
sentido del anterior párrafo, la consulta de una Vista
 Vistas Materializadas - Optimización de Bases de Datos

Materializada ahorra el trabajo de ir hasta las tablas base y D. Uso

realizar los cálculos solicitados. En lugar de ello, el motor Las ecuaciones deben estar centradas y situadas en líneas
llama una única tabla y no realiza sobre ella ningún tipo de distintas. Cada ecuación debe ser numerada:
operación, a no ser que se solicite.
E  mc 2 (1)
A. Desventajas de las Vistas Materializadas
Para referenciar una ecuación, utilice Ec. 1.
El beneficio de obtener reportes complejos en un tiempo mejor
y la capacidad de proteger ciertos datos al usuario final requiere E. Ventajas
un costo respectivo: No aplique ningún elemento de numeración, pie o encabezado
de página. Estos elementos se añadirán en el proceso final de
Inconsistencia de los datos: El almacenamiento físico de una
confección de las actas. Por favor, deje la numeración tal como
consulta implica que dichos datos deben ser actualizados, y
está en el documento modelo.
aunque los motores ofrecen diferentes alternativas siempre
habrá posibilidad de no contar con los datos reales más
recientes. III. USO DE LAS VISTAS MATERIALIZADAS Y EJEMPLO

Costo de Actualización: en el momento de crear o modificar
una Vista Materializada, esta debe ejecutarse en el motor y
posterior a su resultado almacenar el mismo en una tabla. Por
tal motivo, al actualizar la Vista Materializada es necesario que
el motor ejecute de nuevo la sentencia y la almacene
nuevamente, lo que puede significa tiempo y carga para el
motor.
B. Desventajas de las Vistas Materializadas
A continuación se simulará un problema de la vida real con el
fin de mostrar a través de un ejemplo claro como el uso de las
vistas materializadas puede ser un instrumento de optimización
poderoso en una Base de datos.
Como

En primer lugar, dado que la Vista Materializada almacena el

resultado de una consulta en una tabla física y no virtual,
implica que dicho resultado no es siempre el más actual, en
otras palabras, es necesario actualizar el resultado de una vista
materializada para obtener la versión más actual de los datos.
Por otro lado, el almacenamiento físico de la vista
materializada requiere disponibilidad de espacio, lo que
significa un costo adicional para la memoria del servidor.
Sin embargo, Figura SEQ Figura \* ARABIC 2. Plan de ejecución
Básicamente, las vistas materializadas constituyen una consulta
esquema de ejemplo usaremos compleja
el esquema HR provisto por
solución rápida a los problemas de rendimiento en consultas ORACLE, poblaremos la tabla “EMPLOYEES” con dos (2)
que son usualmente ejecutadas y que no necesitan una millones de datos y crearemos una vista compleja que requiere
frecuencia de actualización con urgencia. de la unión de siete (7) tablas diferentes, un filtro por medio
del operador BETWEEN y un ordenamiento a través de dos
C. Estructura y Sintaxis (2) columnas diferentes.
La construcción de una vista materializada en realidad no
difiere mucho de la construcción de una vista común con unas
pequeñas diferencias.
En primer lugar, una vista materializada
La descripción de las figuras deberá ubicarse debajo de las
mismas, centrada, numerándose con cifras arábigas. Use la
abreviatura Fig. n tanto para etiquetar la figura o gráfico como
para referirse a ella.
La descripción de las tablas deberá ubicarse encima de las
mismas, numerándose con cifras romanas y con el texto en
versalitas. La etiqueta de la tabla (Tabla X) debe escribirse en
mayúsculas y encontrarse sola en una línea. Use Tabla X para Figura SEQ Figura \* ARABIC 1. Query consulta
referirse a una tabla. compleja
Los pies de las figuras y de las tablas deben seguir el formato Escenario
mostrado bajo la Fig. 1 y bajo la tabla 1. Si es posible, utilice
un formato vectorial (como EPS o PDF) para representar Supongamos que existe una organización especializada en
diagramas. Los formatos de tipo raster (como PNG o JPG) gestión humana, y dentro de ella una gran cantidad de usuarios
suelen generar ficheros muy grandes y pueden perder calidad que requiere consultar un reporte de los empleados con su
al ampliarlos. historial laboral de forma constante con el fin de generar
 Vistas Materializadas - Optimización de Bases de Datos
estadísticas diarias, para tal fin necesitan que el reporte esté
actualizado con información del día inmediatamente anterior.
Siempre que un usuario necesita acceder al reporte debe
generarlo a través del sistema y esperar aproximadamente 14
minutos para su despliegue, este tiempo puede ser ligeramente
menor o mayor dependiendo de si el reporte ya había sido
generado durante el día por otro usuario o si varios usuarios
intentan generar al mismo tiempo.
A. Definición del Problema
Dado que el reporte es consultado por varios usuarios
simultáneamente y de manera constante durante el transcurso
del día, y cada consulta tiene un alto costo de procesamiento,
el desempeño de la base de datos tiende a disminuir, afectando
no solo a los usuarios que deben esperar 14 minutos por un
reporte, sino a otros usuarios que están realizando actividades
diferentes y que seguramente sufrirán problemas de bloqueos
a causa de los eventos de espera que se generan.
B. Meta de afinamiento
Reducir el tiempo y por consiguiente el costo de generación
del reporte para cada usuario en un 80% y disminuir el número
de eventos de espera que ocurren en la base de datos.
C. Análisis del Plan de Ejecución Antes de la Creación
de la Vista Materializada
En la figura No. 2 podemos observar el resultado del plan de
ejecución retornado durante la ejecución de la vista que sirve
como base para el reporte.
El plan trazado por el optimizador refleja que se realizaron
doce (12) operaciones para poder llevar a cabo la consulta,
dentro de ellas el acceso completo a las tablas employees,
job_history, departments, locations, el acceso a la tabla
countries y a la tabla jobs a través de sus índices, la realización
de cinco (5) operaciones JOIN y el uso de una operación de
ordenamiento.
Árbol de ejecución
1. Operación SORT ORDER BY:
El motor calcula que la operación de ordenamiento se realiza
en un tiempo de 14:23 minutos, genera un consumo de
recursos de I/O, CPU y red de 78.921 y tiene una cardinalidad
de 2’018.002 filas ya que debe ordenar uno a uno los registros
que se van a desplegar.
Retirar la cláusula ORDER BY del query podría optimizar el
desempeño de la consulta en gran medida.
2. Operaciones HASH JOIN RIGHT OUTER:
Debido a la gran cantidad de datos, el optimizador gestiona
todas las operaciones JOIN a través de combinaciones Hash
accediendo a las tablas más pequeñas y sondeando cada fila
con su correspondiente par.
De esta forma para cada una de las cuatro operaciones JOIN se
obtiene una cardinalidad igual al número de registros de la
tabla employees, con un costo calculado promedio de 6.270 y
un tiempo de espera también promedio para cada uno de 01:16
minutos.
3. Operaciones INDEX FULL SCAN:
El optimizador accede a las tablas jobs y countries a través de
sus respectivos índices, el costo calculado es de 19 y 25
respectivamente y el tiempo de espera de 1 segundo para cada
una.
4. Operación TABLE ACCESS FULL:
Las demás tablas de la consulta son accedidas de manera
completa, la lectura de employees qué es la que mayor cantidad
de registros contiene genera costo calculado es de 6.250 y un
tiempo de espera de 1:15 minutos.
Sección de notas
Además del plan de ejecución propiamente dicho, el
optimizador genera información adicional correspondiente a
las condiciones lógicas empleadas para el acceso a todas las
tablas y el filtro que se aplica por medio de la claúsula
“WHERE”.
Figura SEQ Figura \* ARABIC 1. Query consulta
compleja
Estadísticas
● Se necesitaron 887 llamadas recursivas para poder
completar la consulta.
● El bloque de datos se solicitó 10 veces desde el
BufferCaché.
● Se solicitaron un total de 23.290 entradas coherentes
en la SGA para obtener los datos.
● Se realizaron 62.145 lecturas físicas para retornar el
resultado.
● Se procesaron 2’018.002 filas.
Figura SEQ Figura \* ARABIC 1. Query consulta
compleja
 Vistas Materializadas - Optimización de Bases de Datos
D. Implementación de la Vista Materializada
Como parte del proceso de afinamiento sobre la base de datos,
se recurre al uso de una vista materializada.
La Vista se actualizará diariamente en horas de la noche para
no impactar el trabajo de los usuarios durante el día.
El cambio será transparente pues los usuarios podrán consultar
la información histórica de los registros con información del
día inmediatamente anterior.
En la figura No. 5 se anexa el script de creación de la vista
materializada:
Figura SEQ Figura \* ARABIC 1. Query consulta
compleja
E. Análisis del Plan de Ejecución Después de la
Creación de la Vista Materializada
En la figura No. 6 podemos observar el resultado del plan
retornado durante la ejecución de la vista materializada.
Figura SEQ Figura \* ARABIC 1. Query consulta
Árbol de ejecución compleja
A comparación del árbol de ejecución de la consulta anterior,
el nuevo plan permite apreciar que únicamente se lleva a cabo
una operación para obtener los datos, esto disminuye
drásticamente el consumo de recursos, el costo de
procesamiento y por lo tanto el tiempo de espera.
La única operación que se lleva a cabo es el acceso a la vista
completa, no se requieren procesos adicionales de
ordenamiento y/o unión ya que los datos que se solicita
obtener están ya almacenados de manera física en la base de
datos.
De esta forma, con la misma cardinalidad, el consumo de
recursos de I/O, CPU y red disminuye de 78.921 a 7791 y el
tiempo de espera de 14:23 a 01:34 minutos, esto equivale a
una optimización cercana al 90%.
Estadísticas
En la figura No. 7 se aprecian las estadísticas de la consulta:
Figura SEQ Figura \* ARABIC 1. Query consulta
compleja
● El número de llamadas recursivas para poder
completar la consulta se redujo de 887 a 1.
● El bloque de datos no se solicitó desde el
BufferCaché.
● Se realizaron 28.457 lecturas físicas y no 62.145 para
retornar el resultado.
● Se procesaron 2’018.002 filas.
F. Resultados de la Consulta
Como resultado de la creación de la vista materializada se
cumple la meta de afinamiento propuesta sin intervenir con los
procesos de los usuarios.
De ahora en adelante siempre que los usuarios de la compañía
ejecuten el reporte, no se realizará la lectura completa de siete
(7) tablas y las respectivas operaciones de unión y
ordenamiento que se venían llevando a cabo, sino la lectura de
un conjunto de datos físico.
IV. CONCLUSIONES
El seguimiento de las normas indicadas permitirá que su
trabajo resulte visualmente atractivo. Esta misma plantilla se
puede encontrar en formato LATEX, en la dirección web
oficial de las jornadas (http://www.jitel.org).
AGRADECIMIENTOS
Los agradecimientos deberán ubicarse al final del trabajo,
justo antes de las referencias, en una sección sin numerar.
REFERENCIAS
[1] J. Díaz-Verdejo, "Ejemplo de bibliografía", En Actas de las XI
Jornadas de Ingeniería Telemática, vol. 1, n. 1, pp. 1-5, 2013.