No creo ser la persona más capacitada para hablar de las vistas materializadas (materialized views), pero como me llamó la atención el tema lo haré, con el apoyo de algunos artículos y quizá mi amigo Pablo López de Guadalajara pueda complementar algo más tarde.
De manera introductoria les diré, que los tiempos como resultado de usar vistas materializadas en un proyecto donde teníamos reportes con consultas (queries) que duraban hasta más de 1 minuto, se redujeron a segundos.
En un Sistema de base de datos relacional (RDBMS) una vista es una tabla virtual que representa el resultado de un Query. Siempre que se consulta o se actualiza una vista normal, el RDBMS convierte estas operaciones en queries o actualizaciones de las tablas usadas para definir la vista.
Una vista materializada utiliza una enfoque diferente, ya que el resultado de la consulta se almacena en una tabla cache real, que será actualizada de forma periódica a partir de las tablas originales. Esto proporciona un acceso mucho más eficiente, a costa de un incremento en el tamaño de la base de datos y a una posible falta de sincronía, es decir, que los datos de la vista pueden estar potencialmente desfasados con respecto a los datos reales.
Esto es una solución muy utilizada en entornos de Datawarehousing donde el acceso frecuente a las tablas fuente resulta demasiado lento.
Además, dado que la vista se almacena como una tabla real, se puede hacer con ella lo mismo que con cualquier otra tabla, siendo especialmente importante la capacidad de crear indices en cualquier columna, lo cual puede aumentar significativamente la velocidad de las consultas.
En una vista normal, lo más común es que sólo se permita utilizar índices sobre aquellas columnas que ya tienen definido un índice en la tabla original; a veces ni siquiera se ofrece esa posibilidad.
Una sentencia típica de SQL para definir una Vista materializada:
CREATE MATERIALIZED VIEW nombre_vista
[TABLESPACE nombre_ts]
[PARALELL (DEGREE n)]
[BUILD {INMEDIATE|DEFERRED}]
[REFRESH {FAST|COMPLETE|FORCE|NEVER}|{ON COMMIT|ON DEMAND|[START WITH fecha_inicio] NEXT intervalo}]
[{ENABLE|DISABLE} QUERY REWRITE]
AS SELECT … FROM … WHERE …
Con la sentencia BUILD se establece la forma de carga de datos en la vista. Con la opción INMEDIATE (opción por defecto) se cargarán los datos justo después de crear la vista, mientras que con la opción DEFERRED se definirá la vista cuando se ejecute la sentencia SQL sin cargar ningún dato, que se cargarán cuando se realize el primer refresh de la vista.
Con la palabra REFRESH definimos el método y la frecuencia de actualización de los datos.
La palabra QUERY REWRITE establece si queremos que el optimizador de nuestra base de datos pueda reescribir las consultas. El optimizador, sabiendo que ya existe una determinada vista materializada, puede modificar internamente nuestra consulta sobre una determinada tabla, de tal forma que se mejore el rendimiento de la consulta devolviendo los mismos datos que la consulta original.
En el proyecto en cuestión, la base de datos es DB2, aunque diversos gestores de base de datos cuentan con esta funcionalidad. De hecho el RDBMS que lo introdujo fue Oracle.
Califica este articulo
(1 votes, average: 5 out of 5)
Loading ...
Dejenme incorporar un aporte viniendo de QlikView, para destacar un importante diferencial de la base asociativa de QlikView con respecto a las bases relacionales.
El documento explica claramente las ventajas en tiempo de consulta de contar con vistas materializadas. Sin embargo ello trae aparejados costos adicionales de administracion y de necesidades de almacenamiento. Es una de las causas de la explosion de la necesidd de disco de los DW.
Pero lo que esta oculto en el documento es la prueba dela incapacidad de las bases de datos relacionales para el manejo en tiempos de negocio de algunos queries.
QlikView, a traves de su base asociativa, resuelve en tiempo instantaneo esas consultas, sin necesidad de sumarizacion previa, sin necesidad de vistas materializadas.
La explicacion tecnica esta en la base asociativa: esta en memoria (es mucho mas rapido el acceso que cuando esta en disco), pero ademas los valores de todos los campos (no solamente las primary keys) estan asociados, por lo que instantaneamente QlikView detecta que registros se consideran en el “qlik”. Por otro lado la seleccion de criterios en QlikView es persistente en toda la aplicacion, por lo que QlikView responde dinamicamente no solo a ese query sino a todos los que fueron definidos en la aplicacion. Esa es la “magia” de la base asociativa.
Guillermo