Arquitectura de MySQL

La arquitectura de MySQL1 tiene como caracterstica ms notable el separar el motor de almacenamiento (que se encarga de los detalles de entrada-salida y representacin de la informacin en memoria secundaria) del resto de los componentes de la arquitectura. Es decir, el diseo del gestor est preparado para que se pueda cambiar el gestor de almacenamiento. Esto permite incluso crear nuevos motores de almacenamiento especializados para ciertas tareas o tipos de aplicaciones.

Arquitectura lgica de MySQL

La siguiente figura es una visin abstracta de la arquitectura lgica de MySQL. La figura hace una divisin entre los componentes que conforman el servidor, las aplicaciones cliente que lo utilizan y las partes del sistema operativo en las que se basa el almacenamiento fsico.

Figura 1

Las utilidades y herramientas de MySQL son los programas y aplicaciones que se incluyen con la distribucin del gestor, o que pueden instalarse como aplicaciones adicionales. Estas incluyen las herramientas de backup, el navegador de consultas (QueryBrowser), las aplicaciones administrativas de interfaz grfico y la herramienta de diseo MySQL Workbench, entre otras.

Motores de almacenamiento
El elemento ms notable de la arquitectura de MySQL es la denominada arquitectura de motores de almacenamiento reemplazables (pluggable storage engine architecture). La idea de esa arquitectura es hacer una interfaz abstracta con funciones comunes de gestin de datos en el nivel fsico. De ese modo, el gestor de almacenamiento puede intercambiarse, e incluso un mismo servidor MySQL puede utilizar diferentes motores de almacenamiento para diferentes bases de datos o para diferentes tablas en la misma base de datos. Esto permite utilizar el motor de almacenamiento ms adecuado para cada necesidad concreta. Tambin permite que terceros puedan implementar motores de almacenamiento nuevos para necesidades especficas, o adaptar el cdigo de los existentes a ciertos requisitos de almacenamiento. As, las interfaces definidas por MySQL aslan el resto de los componentes de la arquitectura de las complejidades de la gestin fsica de datos, facilitando el mantenimiento de los motores de almacenamiento. Tambin esto permite que ciertos motores de almacenamiento no implementen parte de los servicios, lo cual les hace inapropiados para algunas aplicaciones pero ms eficientes para otros. Por ejemplo, un motor de almacenamiento que no implementa bloqueos en la base de datos no debe utilizarse en aplicaciones multi-usuario, pero la ausencia de sobrecarga de procesamiento en la gestin de los bloqueos para el acceso concurrente lo har mucho ms eficiente para una aplicacin monousuario. En consecuencia, una primera tarea de diseo fsico en MySQL es la de decidir el motor de almacenamiento ms apropiado. Los elementos que puede implementar un motor de almacenamiento son los siguientes:

Concurrencia. Es responsabilidad del motor implementar una poltica de bloqueos (o no implementar ninguna). Una estrategia de bloqueos por fila permite una mayor concurrencia, pero tambin consume ms tiempo de procesamiento en aplicaciones en las que la concurrencia no es realmente grande.

Soporte de transacciones. No todas las aplicaciones necesitan soporte de transacciones. Comprobacin de la integridad referencial, declarada como restricciones en el DDL de SQL. Almacenamiento fsico, incluyendo todos los detalles de la representacin en disco de la informacin. Soporte de ndices. Dado que la forma y tipo de los ndices depende mucho de los detalles del almacenamiento fsico, cada motor de almacenamiento proporciona sus propios mtodos de indexacin (aunque algunos como los rboles B casi siempre se utilizan).

Cachs de memoria. La eficiencia de los cachs de datos en memoria depende mucho de cmo procesan los datos las aplicaciones. MySQL implementa cachs comunes en el gestor de conexiones y la cach de consultas, pero algunos motores de almacenamiento pueden implementar cachs adicionales.

Otros elementos para ayudar al rendimiento, como puede ser el uso de mltiples hilos para operaciones paralelas o mejoras de rendimiento para la insercin masiva.

Adems de lo anterior, los motores de almacenamiento pueden implementar caractersticas no comunes, como la gestin de tipos de datos geoespaciales, o cualquier funcin adicional especfica de cierto tipo de aplicaciones. La implementacin de un gestor de almacenamiento implica escribir un software con una interfaz en lenguaje C, que implemente una biblioteca de funciones (storage engine API) que es la que el servidor MySQL invoca para pedir los servicios al gestor. Por ejemplo, si estamos implementando un gestor de almacenamiento, una de las funciones es la que crea una nueva tabla, que tiene la siguiente signatura.

int ha_tina::create(const char *name, TABLE *table_arg, HA_CREATE_INFO *create_info) { ... }

El parmetro name es, como cabe esperar, el nombre de la nueva tabla, y TABLE es una estructura que representa el esquema de la tabla. Las opciones de creacin estn encreate_info, que incluye, por ejemplo, la asociacin con ndices, restricciones en el tamao de la tabla, etc. MySQL crea una representacin del esquema de las tablas independiente del motor de almacenamiento, en ficheros denominados nombretabla.frm, uno por cada tabla del esquema. TABLE es una referencia a esa representacin.

Cmo seleccionar el motor de almacenamiento?

No hay una receta nica que permita definir el motor de almacenamiento. La seleccin debe hacerse una vez tenemos el modelo lgico de la base de datos y conocemos los requisitos de rendimiento y no funcionales de la aplicacin o aplicaciones que vamos a construir. La sentencia SHOW ENGINES nos muestra la lista de motores en MySQL, incluyendo el motor por defecto y los que no estn disponibles con la configuracin actual. El resultado para MySQL 5.1. es el siguiente:

Engine MyISAM MEMORY InnoDB BerkeleyDB BLACKHOLE

Support Comment YES YES Default engine as of MySQL 3.23 with great performance Hash based, stored in memory, useful for temporary tables

DEFAULT Supports transactions, row-level locking, and foreign keys NO YES Supports transactions and page-level locking /dev/null storage engine (anything you write to it disappears)

EXAMPLE ARCHIVE CSV ndbcluster FEDERATED

NO YES NO NO YES

Example storage engine Archive storage engine CSV storage engine Clustered, fault-tolerant, memory-based tables Federated MySQL storage engine Collection of identical MyISAM tables Obsolete storage engine

MRG_MYISAM YES ISAM TABLA 1 NO

De la tabla anterior solo podemos tener nociones iniciales del tipo de gestor, y dirigirnos a alguno de ellos para casos concretos, por ejemplo, ndbcluster tiene caractersticas nicas si necesitamos soporte para alta disponibilidad. No obstante, hace falta conocer ms en profundidad las caractersticas de cada uno para tomar decisiones, y en ocasiones es necesario hacer pruebas de rendimiento con varios de ellos para compararlos y seleccionar el que mejor se ajusta a nuestras necesidades.

Los conectores
Los conectores son bibliotecas en diferentes lenguajes de programacin que permiten la conexin (remota o local) con servidores MySQL y la ejecucin de consultas. Por ejemplo, el conector Connector/J permite conectarse a MySQL desde cualquier aplicacin programada en lenguaje Java, y utilizando el Java Database Connectivity (JDBC) API.

El gestor de conexiones
La gestin de conexiones es responsable de mantener las mltiples conexiones de los clientes. Un gestor de conexiones inexistente o laxo simplemente creara una conexin por cada cliente conectado. No obstante, las conexiones consumen recursos de mquina, y crearlas y destruirlas son tambin procesos costosos. Por eso, el gestor de conexiones de MySQL puede configurarse para limitar el nmero de conexiones concurrentes, y tambin implementa un pool de conexiones. La idea es que muchas aplicaciones abren una conexin y la mantienen abierta y ociosa durante mucho tiempo (por ejemplo, durante toda la sesin de un usuario, que de vez en cuando se levanta para diferentes tareas mundanas como tomar caf), y solo de vez en cuando se utiliza un hilo de ejecucin para ejecutar una consulta, que adems, tpicamente tarda como mucho unos milisegundos. No tiene sentido mantener una conexin ociosa para cada usuario. De aqu proviene la idea de los pools de conexiones: hay un nmero de conexiones disponibles, y cada vez que una aplicacin hace una solicitud, se le asigna una conexin del pool que no est ocupada. Lgicamente, la aplicacin cliente no es consciente de este mecanismo. En trminos por ejemplo, de las interfaces JDBC, esto quiere decir que cada vez que enviamos una sentencia con llamadas como Statement.executeQuery()realmente puede que se cree una nueva coleccin, o quiz se

tome una del pool. Es decir, las llamadas a Driver.getConnection() y a Connection.close() no siempre determinan el tiempo de vida de una conexin real en MySQL. Adems de la reduccin en el tiempo de establecimiento de conexin (si se reusa una conexin ya creada del pool), la tcnica permite limitar el nmero de conexiones simultneas. Dado que las conexiones consumen recursos, es mejor limitar este nmero que llevar a una carga excesiva en el servidor, que podra acabar en una cada del sistema o un comportamiento impredecible. Ntese que gracias a los pools de conexiones, puede darse servicio a muchas conexiones concurrentes con un nmero limitado de conexiones que se reutilizan. El gestor de conexiones tambin se ocupa de la autentificacin de los usuarios. La autentificacin por defecto se basa en el nombre de usuario, la mquina desde la que se conecta y la password. El servidor puede tambin configurarse para soportar certificados X.509.

El procesamiento y optimizacin de consultas

Cada vez que una consulta llega al gestor de MySQL, se analiza sintcticamente y se produce una representacin intermedia de la misma. A partir de esa representacin, MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos ndices, o la re-escritura de la consulta en una forma ms eficiente. Existe la posibilidad de utilizar ciertas clusulas en las consultas para ayudar al optimizador en su tarea, o bien podemos pedirle al servidor ciertas explicaciones sobre cmo ha planificado nuestras consultas, para entender mejor su funcionamiento. Dado que la optimizacin de las consultas depende de las capacidades del gestor de almacenamiento que se est utilizando, el optimizador pregunta al gestor si soporta ciertas caractersticas, y de este modo, puede decidir el tipo de optimizacin ms adecuado.

La cach de consultas
MySQL implementa un cach de consultas, donde guarda consultas y sus resultados enteros. De este modo, el procesador de consultas, antes ni siquiera de plantear la optimizacin, busca la consulta en la cach, para evitarse realizar el trabajo en el caso de que tenga suerte y encuentre la consulta en la cach.

El Control de Concurrencia
El control de concurrencia en un gestor de bases de datos es simplemente el mecanismo que se utiliza para evitar que lecturas o escrituras simultneas a la misma porcin de datos terminen en inconsistencias o efectos no deseados. El mecanismo que se utiliza para controlar este acceso es el de los bloqueos (locks). La idea es muy simple, cada vez que una aplicacin quiere acceder a una porcin de los datos, se le proporciona un bloqueo sobre los mismos. Lgicamente, varias aplicaciones que quieran leer simultneamente no tienen ningn problema en hacerlo, de modo que para la lectura se proporcionan bloqueos compartidos (shared locks). Sin embargo, varios escritores o un escritor simultneo con lectores puede producir problemas. Por eso, para la escritura se proporcionan bloqueos exclusivos (exclusive locks).

Aunque la idea parece simple, hay que tener en cuenta que la obtencin y liberacin de los bloqueos se realiza continuamente, y esto produce una sobrecarga en el procesamiento dentro del servidor. Adems, hay diferentes polticas de bloqueo, por ejemplo, es mejor bloquear cada tabla completa afectada o solo las filas de la tabla a las que quiere acceder una consulta?. Dada la existencia de diferentes tcnicas, el control de concurrencia en MySQL se divide entre el servidor y cada gestor de almacenamiento.

La gestin de transacciones y recuperacin

La gestin de transacciones permite dotar de semntica todo o nada a una consulta o a un conjunto de consultas que se declaran como una sola transaccin. Es decir, si hay algn problema y parte de la consulta o algunas de las consultas no consiguen llevarse a cabo, el servidor anular el efecto parcial de la parte que ya haya sido ejecutada. La recuperacin permite volver hacia atrs (rollback) partes de una transaccin. Para complicarlo an ms, puede que una transaccin implique ms de una base de datos, y en ocasiones, a ms de un servidor (transacciones distribuidas). MySQL proporciona soporte para todos estos tipos de transacciones, siempre que los gestores de almacenamiento utilizados en las bases de datos implicadas tambin lo soporten.