Rendimiento y disponibilidad

Una base de datos que lleva meses funcionando no rinde igual que el día que se estrenó, y casi nunca es porque el hardware se haya vuelto lento. Lo que ocurre es que el espacio se fragmenta, los índices se degradan, las estadísticas con las que el optimizador decide sus planes se quedan viejas y las consultas que antes iban bien empiezan a elegir mal el camino.

La reparación de tablas merece un aviso, porque explica por qué el motor importa. Las tablas MyISAM son susceptibles de corromperse ante un apagón o una parada brusca, precisamente porque no son transaccionales y no garantizan las propiedades ACID: si el servidor cae en mitad de una escritura, el fichero puede quedar a medias y hay que repararlo a mano. Con un motor transaccional el gestor se recupera solo leyendo su registro.

Para diagnosticar en caliente, el administrador tiene dos vistas complementarias. Una es la instantánea de qué se está ejecutando ahora mismo, que en MySQL da la lista de procesos y que sirve para encontrar la consulta que está bloqueando a las demás. La otra es el histórico de consultas lentas, del que se saca el listado de las que más tardan. Del análisis fino de una consulta concreta se ocupa el plan de ejecución, que se estudia en el tema de SQL: aquí lo que importa es que ese plan depende de unas estadísticas que hay que mantener al día.

Antes de tocar una consulta, comprobar que las estadísticas están al día. Un plan malo suele ser un plan tomado con información vieja, no una consulta mal escrita.

Una vista normal no guarda datos: es una consulta con nombre que se vuelve a ejecutar cada vez que alguien la usa. Una vista materializada sí los guarda: es una foto del resultado en el momento en que se creó, almacenada como si fuera una tabla. Para quien la consulta es transparente, pero por dentro la diferencia es total, porque ya no hay que recalcular nada.

Es una herramienta de administración típica de los cuadros de mando y de los informes: consultas que agregan millones de filas, que tardan minutos y que se piden cien veces al día. Se calculan una vez, se guardan y se sirven al instante. La condición para que compense es que el dato de origen cambie poco o que se pueda vivir con un resultado de hace unas horas.

CREATE MATERIALIZED VIEW resumen_tema
  REFRESH FORCE
AS SELECT tema_id,
          COUNT(*)      AS intentos,
          AVG(aciertos) AS media_aciertos
     FROM intento
    GROUP BY tema_id;

Lo que hay que decidir al crearla es cómo se refresca, y ahí están los nombres que se preguntan.

La vista normal recalcula cada vez; la materializada guarda el resultado y hay que refrescarlo. El precio de la velocidad es que el dato puede estar desfasado.

El problema clásico de un gestor con muchos usuarios a la vez es qué hacer cuando uno lee justo lo que otro está modificando. La solución antigua era bloquear: quien escribe cierra la fila y quien quiere leerla espera. Funciona, pero convierte cualquier informe largo en un freno para toda la operativa.

Los gestores modernos resuelven el mismo problema guardando varias versiones de cada fila. Cuando una transacción empieza, se queda con una foto coherente de los datos en ese instante y trabaja sobre ella; si otra transacción modifica una fila, se crea una versión nueva y la anterior sigue disponible para quien ya la estaba viendo. El resultado es que las lecturas no esperan a las escrituras ni al revés, y los bloqueos se reducen muchísimo.

PostgreSQL trabaja así de serie. SQL Server incorpora el mismo comportamiento en su modo de aislamiento por instantánea, que es el nombre con el que aparece en su documentación y en las preguntas. Que un producto ofrezca este modelo es lo que en los temarios se llama concurrencia avanzada.

El coste de administración es el que ya se vio: si hay versiones antiguas de las filas, alguien tiene que limpiarlas. En PostgreSQL esa limpieza es VACUUM, y por eso el mantenimiento de este gestor no es opcional sino consecuencia directa de su modelo de concurrencia.

Con versiones múltiples, leer no bloquea escribir. El precio es que hay versiones viejas que hay que limpiar, y de ahí sale la necesidad de VACUUM.

El nombre técnico del mecanismo es control de concurrencia multiversión, que se abrevia MVCC. La idea completa es que cada transacción trabaja sobre una imagen propia del contenido, tomada en un instante distinto al de las demás, y que al terminar se integran los resultados de todas.

Lo que hace posible ese aislamiento es que cada versión de una fila lleva marcado en qué transacción nació y en cuál dejó de ser válida. Cuando una transacción va a leer, el gestor compara esas marcas con las suyas y decide qué versión le corresponde ver. Dos transacciones concurrentes pueden por tanto estar viendo dos contenidos distintos de la misma fila, y las dos están viendo un estado coherente.

La consecuencia sobre los bloqueos es la que interesa al administrador: al aislar cada transacción con una foto propia, las esperas se reducen drásticamente y desaparecen los atascos en cadena que provocaba el bloqueo de lectura. Lo que no desaparece es el conflicto real entre dos escrituras sobre la misma fila, que sigue teniendo que resolverse esperando o abortando una de las dos.

Replicar es mantener otro servidor con los mismos datos, alimentado continuamente desde el principal. Sirve para tres cosas a la vez: tener un relevo listo si el principal cae, descargar en la réplica las consultas de solo lectura, y disponer de un sitio donde lanzar informes pesados sin castigar a la operativa. El esquema clásico, el de un servidor principal que escribe y uno o varios secundarios que copian, es el que en los temarios aparece con los nombres de maestro y esclavo.

El mecanismo es siempre el mismo y se apoya en el registro de cambios que ya se conoce del subtema de copias: el principal anota lo que hace en un fichero de registro y el secundario lo lee y lo reproduce.

Que la replicación sea asíncrona tiene una consecuencia directa sobre la política de continuidad: el secundario va siempre un poco por detrás. Si el principal se pierde de golpe, lo que aún no había viajado se pierde con él. Por eso la replicación reduce el tiempo de recuperación pero no sustituye a las copias de seguridad, que además protegen de algo que la replicación no cubre: un borrado por error se replica igual de rápido que cualquier otro cambio.

La réplica protege del fallo de la máquina; la copia de seguridad protege del error humano. No son intercambiables.

Cuando el servicio no puede caerse, la replicación se queda corta y se pasa a arquitecturas de clúster, donde varias máquinas dan el mismo servicio a la vez. Es la parte de la seguridad que en el catálogo de funciones del DBA aparece aplicada a los servicios: disponibilidad y arquitectura de alta disponibilidad.

Merece la pena fijar la idea central de RAC porque es la que se pregunta: una sola base de datos, varias instancias. Encaja exactamente con la distinción de «El oficio del DBA» entre los ficheros del disco y la memoria con los procesos, y es la razón de que esa distinción no sea un tecnicismo.

En RAC la base de datos es una y está en el almacenamiento compartido; lo que se multiplica son las instancias que la abren.