Vistas Materializadas en Oracle (pl/sql) – Que son y para que usarlas

Vistas Materializadas en Oracle (pl/sql) – Que son y para que usarlas

Base de datos

Primero para entender porque, como usarlas y sus opciones, vamos a arrancar con la definición de que es una vista materializada.

Que es una Vista Materializada (VM)

Una VM no es más que una vista, con la diferencia de que además de almacenarse su definición se almacenan los datos que retorna.

Esto es especialmente útil cuando la vista en cuestión se va a llamar constantemente y se necesita una buena performance.

La contra es que salvo que se defina como actualizable al hacer commit en las tablas referenciadas (poco común) una vez creada la VM los datos van a ser estáticos hasta su actualización, que puede ser tanto manual como automática.

Porque usar una VM si no voy a tener el contenido actualizado?

Hay muchos casos en que no hace falta tener el contenido actualizado, por ejemplo cuando se desean ver datos consolidados al día anterior (en algunos tipos de dashboard).

Es decir el negocio y la aplicación definirá si nos sirve utilizar una VM, en cuyo caso se va a ganar muchísimo a nivel performance.

Como alternativa esta utilizar una VM que se actualice a nivel datos con cada commit realizado a las tablas referenciadas, hay que tener cuidado en este caso que no genere un inconveniente en la operación cuando se dispara el refresh.

Como se actualizan los datos de una VM?

La VM puede ser actualizada de tres formas:

– En forma automática al realizar un commit a alguna de las tablas referenciadas

– En forma automática en un horario determinado

– En forma manual

En los dos primeros casos (especialmente el segundo) hay que tener mucho cuidado que dicha actualización no genere un cuello de botella, ya que hace una especie de bloqueo temporal de las tablas implicadas en la vista.

Es decir lo ideal sería o realizarlo en forma manual (por ejemplo como parte del proceso de consolidación de datos) o que se ejecute en forma automática en un horario en que no pueda afectar la operación (de noche, o de madrugada previo al inicio del día laboral).

Solo es recomendable realizar una actualización “on commit” (primer caso) si el flujo de datos actualizados es chico.

Tipos de actualizaciones de una VM

– Complete: la actualización complete implica que todos los datos de la VM van a ser borrados y luego creados (insert) nuevamente.

– Fast: a través de la creación de un log, la actualización de la VM va a ser incremental, es decir solo se va a modificar lo que cambio, y se van a insertar los datos nuevos.

El inconveniente con el método fast es que tiene muchas limitaciones en el tipo de consulta que se puede definir en la VM, por ende tiende a no ser posible utilizarlo.

– Force: la actualización se realizará en forma fast si es posible, en caso contrario en forma complete.

Porque la actualización complete demora tanto? Delete vs Truncate

Cuando realizamos una actualización de tipo complete, los datos se van a borrar y luego insertar nuevamente.

Para esto podemos definir la forma en que hará el borrado, es decir a través de un delete (atómico) o de un truncate.

En caso de no especificarlo va a realizar el método delete-insert.

En principio salvo que haya alguna limitación de por medio, por temas de performance siempre es más conveniente realizar el resfresh forzando el truncate de la VM.

Sintaxis y ejemplos

Crear una VM:

CREATE MATERIALIZED VIEW vista_materializada

[TABLESPACE nuestro_tablespace]

[BUILD {IMMEDIATE | DEFERRED}]

[REFRESH {ON COMMIT | ON DEMAND | [START WITH fecha_inicial] NEXT intervalo_tiempo } |

{COMPLETE | FAST | FORCE | NEVER} ]

[{ENABLE|DISABLE} QUERY REWRITE]

AS SELECT tabla1.campo_a, tabla2.campo_b

FROM tabla1 , tabla2

WHERE tabla1.campo_a = tabla2.campo_a...

En la creación de la vista es conveniente definir si se van a generar los datos al ejecutar la creación o si va a ser en forma posterior

(IMMEDIATE o DEFERRED), especificar cuando hacer el refresh (ON COMMIT | ON DEMAND | START WITH) y como (COMPLETE | FAST | FORCE | NEVER).

Un ejemplo de una VM que genere/almacene los datos al crearla, que haga el refresh a demanda, y en forma completa sería:

CREATE MATERIALIZED VIEW vista_materializada

   TABLESPACE ejemplo_tablespace

   PARALLEL 4

   BUILD IMMEDIATE

   REFRESH COMPLETE ON DEMAND

   AS SELECT tabla1.campo_a, tabla2.campo_b

    FROM tabla1 , tabla2

    WHERE tabla1.campo_a = tabla2.campo_a...

Y para invocar el refresh forzando el truncate usaríamos:

exec dbms_mview.refresh( 'vista_materializada', atomic_refresh=>false);

Alguna duda? en caso contrario, a aprovechar la mejora de performance de una buena implementación de vistas materializadas.

Chau Servidores dedicados, hola AWS (o en su defecto google cloud, azure)

Chau Servidores dedicados, hola AWS (o en su defecto google cloud, azure)

IT Cloud

Hoy en día las empresas y los proyectos exitosos crecen en forma acelereda, y necesitan de una infraestructura que los acompañe y no frene su operatoria.

Los servidores dedicados son fiables, pero son difíciles de escalar, de configurar, más costosos, y en general se suelen necesitar muchas herramientas complementarias para monitorear y controlar en forma correcta.

Con AWS (o sus competidores) todo esto ya no es un impedimento, escalar una instancia implica hacer un par de clicks para cambiar las especificaciones de la misma.

A su vez para escalar el entorno se pueden hacer imagenes y levantar nuevas instancias, clonar, o directamente definir grupos de auto-scalling.

Para monitorear se cuenta con herramientas incorporadas a la consola (por ejemplo cloudwatch) donde a su vez se pueden definir alertas ante ciertas acciones, o niveles.

En nuestro caso (Myne) montamos en AWS todo nuestro futuro entorno productivo en 1 día. Configuramos grupos de seguridad, aproximadamente 13 instancias (EC2) con sus respectivas ip privadas, e ip públicas, instancias RDS, buckets S3, scripts en lambda, procesos en beanstalk, load balancers, y alertas entre otras cosas.

Por supuesto para que todo funcione correctamente, luego de configurar toda la infraestructura durante algunos días hicimos pruebas de carga y ajustamos cosas, pero es un ejemplo de la flexibilidad, velocidad y posibilidades que brindan estas soluciones.

Es decir tanto con AWS, como Google Cloud, o Azure vas a lograr:

  • Flexibilidad
  • Escalabilidad
  • Balanceo de carga (facilmente configurable)
  • Menores costos
  • Menores tasas de fallas
  • Mayor control y monitoreo

Que esperas para sumarte al cloud computing?

PD: juro que no soy empleado de AWS.