Lo nuevo de MySQL 4.0

Cedido por MySQL Hispano.

La versión 4 de MySQL ha estado en desarrollo desde el 2001. Para cuando te encuentres leyendo este artículo, MySQL 4.0 debe ser una versión estable (o al menos estar en la última versión beta - no terminada aún, pero compatible para el trabajo de desarrollo que se suele requerir).

La mayoría del trabajo de desarrollo en 4.0 se ha enfocado en tres áreas: mejorar las características y la eficiencia existentes, agregar nuevas características, y cambiar la arquitectura del software de MySQL para estar preparados con el futuro crecimiento. Simplemente no tenemos el suficiente espacio aquí para discutir todos los cambios en MySQL 4.0, así que nos enfocaremos en señalar las mejoras más importantes y las nuevas características que acompañan a esta versión.

Antes de continuar, vale la pena mencionar que virtualmente todos los cambios en MySQL 4.0 son completamente transparentes. En la mayoría de los casos se podrán realizar actualizaciones sin cambiar el código de las aplicaciones (aún las primeras versiones de MySQL 4.0 pasaron una prueba extensiva de compatibilidad sin problemas).

Mejoras desde la versión 3.23

• El optimizador de consultas de MySQL es ahora más inteligente en el uso de índices para resolver las consultas. Algunas consultas que requieren un ordenamiento extra son ahora significantemente más rápidas.
• En MySQL 3.23, se necesitaba recompilar MySQL para ajustar las opciones de índices de texto completo, tales como la longitud mínima de una palabra. En 4.0, las opciones de índices de texto completo han sido movidas al archivo de configuración de MySQL, así que solamente se tienen que hacer las adecuaciones necesarias y reiniciar MySQL para que los cambios tengan efecto. Muchos fallos en las búsquedas de texto completo han sido corregidos también.
• Cambios al código de la caché de claves han producido un significante aumento en el tiempo de ejecución durante algunas consultas basadas en índices. Esto es especialmente útil en servidores que tienen demasiada carga.
• Si alguna vez has querido eliminar registros relacionados de múltiples tablas al mismo tiempo, ahora MySQL 4.0 dispondrá de borrados multi-tablas. Al especificar múltiples tablas y la cláusula WHERE correcta, MySQL hará sin problemas lo que esperas. También se pueden agregar opciones ORDER BY y LIMIT a las consultas DELETE, para obtener un mejor control sobre cuántos registros son eliminados y el orden en el que son eliminados dichos registros.
• El sistema de replicación de MySQL ha sido mejorado notablemente. Muchos de los cambios fueron hechos en anticipación del sistema de replicación fail-safe. En 4.0, el proceso mismo de replicación es multi-hilo en los servidores esclavos. Si el servidor principal llega a fallar, es ahora mucho más probable que cada esclavo tenga los datos necesarios para hacer por sí mismo una recuperación de los datos y trabajar como si fuera el servidor maestro. Los registros de replicación ahora contienen los marcadores de transacción necesarios para asegurarse que las transacciones son replicadas apropiadamente.
• El número de variables de estado en MySQL casi se ha duplicado. Ahora se puede tener un panorama mucho más claro y amplio de lo que está pasando dentro de MySQL. Muchas de las herramientas de administración de MySQL creadas por terceros han sido actualizadas para utilizar estas nuevas variables.

InnoDB: Transacciones ACID y más

MySQL, como el kernel de Linux, es modular. Se pueden deshabilitar y remover piezas que no se necesiten en MySQL. La modularidad proporcionada por MySQL es una ventaja muy importante sobre muchos otros sistemas de administración de bases de datos: en concreto, se puede elegir el tipo de una tabla al momento mismo de crearla. Si unas cuantas de las tablas necesitan fine-gained locking o transacciones, se puede elegir un tipo de tabla que mejor se acomode a las necesidades, es decir, no se necesita tener la sobrecarga de las transacciones en todas las tablas. Otros pocos sistemas de bases de datos relacionales ofrecen múltiples tipos de tablas.

En la versión 4.0 MySQL ha agregado InnoDB a la lista de tipos de tablas soportados en una instalación típica, o estándar. MySQL 4.0 soporta cinco tipos de tablas: MyISAM, ISAM, HEAP, BDB (Base de datos Berkeley), e InnoDB. BDB e InnoDB son ambas tipos de tablas transaccionales. Se puede utilizar la sentencia estándar BEGIN WORK seguida de varias consultas y finalizar con un COMMIT o ROLLBACK para completar la transacción. O, se pueden correr en modo AUTOCOMMIT, así que cada consulta es efectivamente una transacción separada.

Pero esto es sólo el comienzo. InnoDB es un motor de bases de datos muy completo que ha sido embebido dentro de MySQL. InnoDB también proporciona lo siguiente:

• Recuperación autómatica ante fallas. Si MySQL se da de baja de una forma anormal, InnoDB autómaticamente completará las transacciones que quedaron incompletas..
• Integridad referencial. Ahora se pueden definir llaves foráneas entre tablas InnoDB relacionadas para asegurarse de que un registro no puede ser eliminado de una tabla si aún está siendo referenciado por otra tabla.
• Bloqueo a nivel de filas. Al usar tablas MyISAM, y tener consultas muy grandes que requieren de mucho tiempo, simplemente no se podían ejecutar más consultas hasta que terminarán las consultas que estaban en ejecución. En cambio, las tablas InnoDB usan bloqueo a nivel de filas para mejorar de manera impresionante el rendimiento.
• SELECTs sin bloqueo. Como si el bloqueo a nivel de filas no fuera suficiente, el motor InnoDB usa una técnica conocida como multi-versioning (similar a PostgreSQL) que elimina la necesidad de hacer bloqueos en consultas SELECT muy simples. Ya no será necesario molestarse porque una simple consulta de sólo lectura está siendo bloqueada por otra consulta que está haciendo cambios en una misma tabla.

Crear tablas InnoDB es tan simple como crear otro tipo de tablas. Sólo se tiene que especificar Type = InnoDB al final de la sentencia CREATE TABLE como se muestra en la Figura Uno. Para más información, visitar el sitio web de InnoDB.

CREATE TABLE algunaTabla(
   campoX   INTEGER UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   campoY   INTEGER NOT NULL,
   campoZ   VARCHAR(255) NOT NULL
) Type = InnoDB;

Soporte SSL

Para entender como se usa SSL en MySQL es necesario explicar brevemente algunos conceptos básicos de SSL y X509. Por default, MySQL usa conexiones no encriptadas entre el cliente y el servidor, lo que significa que alguién puede ver, y aún modificar los datos que están siendo enviados o recibidos entre el cliente y el servidor. En algunos casos esta situación es inadmisible debido a que la información que se maneja es muy valiosa, y se desea en todo momento mantener la integridad y la confiabilidad de los datos.

SSL es un protocolo que usa diferentes algoritmos de encriptación para asegurarse de que los datos que viajan a través de una red pública (ej. Internet) pueden ser fiables. Éste tiene un mecanismo para detectar cualquier cambio o pérdida de los datos, además de incorporar algoritmos para la verificación de identidad usando el estándar X509.

X509 es el estándar que hace posible identificar a alguién en Internet. Éste es usado comúnmente en aplicaciones de comercio electrónico. En términos simples, debe haber una compañia que asigne certificados electrónicos a cualquiera que necesite de ellos. Estos certificados se basan en un algoritmo que tiene dos llaves de encriptación (una llave pública, y una llave secreta). El dueño de un certificado puede probar su identidad al mostrar su certificado a la otra parte. Este certificado consiste de su llave pública. Cualquier dato que se haya encriptado con esta llave pública pueden ser desencriptado únicamente con la correspondiente llave secreta, que debe pertenecer al dueño del mismo certificado.

La versión 4.0 de MySQL tiene soporte nativo de SSL. Ya no será necesario configurar un canal seguro con SSH, o usar stunnel para establecer una conexión encriptada entre un servidor y un cliente MySQL. El soporte para SSL fue agregado al sistema de privilegios estándar de MySQL, por lo que hay algunas opciones nuevas en el comando GRANT.

Para forzar a un usuario a usar SSL para conectarse al servidor, simplemente se tiene que agregar la opción REQUIRE SSL al comando GRANT que se usa normalmente. Por ejemplo:

GRANT ALL PRIVILEGES ON bd_abc.* TO juancho@"%"
IDENTIFIED BY 'holahola' REQUIRE SSL

El comando GRANT de arriba requiere que el usuario "juancho" con la contraseña "holahola" tenga que conectarse vía SSL. Si "juancho" intenta establecer una conexión sin encriptar al servidor, MySQL rechazará la conexión.

MySQL permite ser más riguroso. En el ejemplo anterior se permite que cualquiera que conozca la contraseña de "juancho" se conecte al servidor y pueda manipular los datos. El único requisito es que la conexión se establezca a través una conexión SSL. Si realmente la seguridad es un asunto sumamente importante, se puede forzar a que "juancho" tenga un certificado X509 para probar su identidad.

GRANT ALL PRIVILEGES ON bd_abc.* TO juancho@"%"
IDENTIFIED BY 'holahola' REQUIRE X509

Aunque es muy fácil generar un certificado con las herramientas que vienen con OpenSSL, es más recomendable usar un certificado firmando por alguna autoridad certificadora. La sintaxis REQUIRE ISSUER permite hacer esto. También se puede usar REQUIRE CIPHER para poner una lista de ciphers que serán permitidos.

Caché de consultas

Teniendo en cuenta que MySQL es usado en un gran número de sistemas web como PostNuke y Slashcode, los desarrolladores de MySQL implementaron una caché de consultas para acelerar las consultas que son ejecutadas comúnmente. Esta caché simplemente almacena las consultas SELECT ejecutadas recientemente y sus resultados en memoria. Es posible configurar la cantidad de memoria asignada a la caché al ajustar la variable query_cache_size en el archivo de configuración de MySQL.

En un sitio web que proporciona historias, o noticias breves, tal como LinuxToday, se puede pensar que una consulta como la siguiente se ejecuta cada vez que un usuario visita este sitio web:

SELECT titulo, introduccion, fecha, autor FROM noticias 
ORDER BY fecha DESC LIMIT 10

Esta consulta obtiene la información de las 10 noticias agregadas recientemente. Pero las noticias no son agregadas muy frecuentemente -tal vez 20 ó 30 veces por día. Con la caché de consultas habilitada, MySQL no se esforzará en ejecutar esta consulta a menos que los datos hayan sido cambiados recientemente. En vez de ello, MySQL tomará los datos que tenga en la memoria. El cliente no verá la diferencia entre los datos que están en la caché, de los que no lo están, sin embargo, puede notar una mejora en el rendimiento.

MySQL está al pendiente de las tablas que tienen datos en la caché de consultas, y cuando se ejecuta alguna consulta que cambia cualquiera de los datos de estas tablas, MySQL invalida los correspondientes segmentos de la caché de consultas que ocupaban estos datos.

Nota importante:

Las consultas que son comparadas necesitan ser exactamente las mismas, esto es

SELECT * FROM TABLAX

y

Select * from tableX

son consideradas diferentes para la caché de consultas. Es más, una consulta puede considerse diferente entre varios clientes si por ejemplo están usando un nuevo formato en el protocolo de comunicación, o un conjunto de caracteres diferente.

Las consultas que usan diferentes bases de datos, que usan diferentes versiones del protocolo de comunicación, o usan un conjunto de caracteres diferente son consideradas consultas diferentes y se almacenan en la caché de manera separada.

Uniones

Una característica bastante solicitada son las uniones. UNION es la manera estándar en que se combinan los resultados de múltiples consultas SELECT en un sólo conjunto de resultados. Hasta ahora, se tenían que ejecutar múltiples consultas de manera separada, recuperar los resultados, y combinarlos uno mismo.

SELECT id, balance FROM cuentas WHERE fecha_est = '2002-10-04'

SELECT id, balance FROM cuentas_anteriores WHERE fecha_est = '2002-10-04'

Usando la sentencia UNION, se pueden combinar estas dos consultas en algo como esto:

(SELECT id, balance FROM cuentas WHERE fecha_est = '2002-10-04')
UNION
(SELECT id, balance FROM cuentas_anteriores WHERE fecha_est = '2002-10-04')

Las consultas individuales en una UNION pueden contener cláusulas ORDER BY o LIMIT, incluso se pueden aplicar estas mismas cláusulas al resultado de la UNION.

Hacia la versión 4.1

Las siguientes características están planeadas para incluirse en la versión 4.1 de MySQL, pero no son únicas debido a que existen desarrolladores trabajando en diferentes proyectos, y podría haber muchas otras características adicionales. Existe también alguna posibilidad de que algunas de estas características sean incorporadas en la versión 4.0. Algo del trabajo en MySQL 4.1 ya está en progreso.

• Subconsultas.
• Ayuda para todos los comandos desde el cliente mysql.
• Nuevo formato para la definición de tablas. Permitirá agregar nuevos tipos para las columnas, más opciones para claves, y posiblemente guarde definiciones FOREIGN KEY.
• SHOW COLUMNS FROM nombreTabla (usado en el cliente mysql) ya no debe abrir la tabla, únicamente el archivo de definición de la tabla.
• Llaves foráneas para tablas MyISAM, incluyendo eliminación de registros en cascada.
• Replicación fail-safe.
• Respaldos en línea sin decrementar la eficiencia del servidor.
• Soporte más estable para OpenSSL ( El soporte SSL en la versión 4.0 no está 100% probado).
• Implementación del comando RENAME DATABASE.