Motores de almacenamiento de MySQL

mysql_100x52-64.gifComo bien sabrás, querido picacódigo, MySQL es una base de datos relacional de licencia GPL, ésto implica que usa tablas para guardar los datos, visto desde su representación lógica (como lo vemos nosotros, los usuarios). Pero, por dentro, usa un motor de almacenamiento (storage engine) que será el encargado de guardar de verdad los datos a ficheros, según una determinada estrategia. Este motor es totalmente clave a la hora de evaluar la rápidez y las funcionalidades que puede tener el SGBD. MySQL tiene la opción (para cada tabla que se vaya a crear) de establecer explicitamente qué motor usar.

  • MyISAM, el motor por defecto, permite lo típico, pero no permite transacciones, toda las consultas se realizan con autocommit. Por lo demás no hay mucho que comentar, como curiosidad decir que los BLOB o TEXT pueden ser indices, e incluso un campo que sea indice puede tomar valor NULL. Usa Arboles B internamete para los indices (separado de los datos) y tiene herramientas para chequeo y reparación de tablas.
  • BLACKHOLE: si tiene un nivel de inglés tan patetico como el mio (o superior) fijo que descubres que hace este motor (blackhole = agujero negro). Sería el equivalente a /dev/null mayormente. Y dirás, ¿y esto para que cojones lo quiero yo?, pues puede llegar a ser útil, pues cuando realizas una transacción con este motor, auque no se guardan los datos, ni te va a devolver nada, si que crea LOG de la sentencia SQL que se “ha ejecutado”. El caso típico podría ser establecer un servidor esclavo para que de ese modo guardará el log de lo que pasa en el master
  • CSV, motor completamente trivial, que guarda cada tabla en un fichero y cada fila de datos es una linea con los datos separados por comas. Queda claro, no?. Para hacer la gracia decir que no soporta indices (imagina buscar en ficheros… coste secuencial! O(n) OMFG!). Este formato sería usado mas bien para crear archivos listos para ser importados por otros programas.
  • ARCHIVE, el motor almacen almacen, solo soporta INSERT’s y SELECT’s, es decir un almacen!. Además, siempre que escribes datos se comprimen (con zlib), así que es el motor típico para una base de datos histórica o cuando vamos a tener una cantidad realmente enorme de datos (quizás sea la idonea para GIS?, habría que meditarlo…). Decir que si se realizan muchos SELECT a la vez que se realizan INSERT provocaría que el motor se hiciese la picha un lio, ¿por qué? Porque cuando se hace un INSERT los datos van a un buffer (para no tener que recomprimir, con zlib, para cada puta linea que se inserta supongo…) y éstos datos serán flusheados cuando se realice el SELECT, ahora piensa cientos de INSERT y SELECT en paralelo. Da miedo, eh?
  • EXAMPLE, este no sirve para nada, jaja. Es solo un ejemplo de motor, para poder mirar su código y crear motores hechos y derechos
  • FEDERATED, motor nuevo que se incorporó en la versión 5 de MySQL, para poder crear bases de datos federadas, esto significa que estaremos consultando a una bases de datos remota, es decir en nuestro servidor creamos la tabla pero le decimos, oye que esta tabla esta en otro lado, si eso, le preguntas, que fijo que te responde. Este modelo tiene ciertas limitaciones, no permite ALTER’s ni transacciones.
  • MERGE, este es facil, si tienes dos tablas con motor MyISAM y con la misma estructura, al crear una tabla MERGE, juntarás los datos de ambas tablas. Un caso para el cual puede ser útil este motor, podría ser, por ejemplo, diferentes tablas de log en diferentes servidores y te creas en uno de ellos tablas FEDERATED de esas tablas (que serán MyISAM) y entonces creas una tabla de “log_principal” (usando MERGE) que tendrá el log de todos los servidores. arrr marinero.
  • MEMORY, tablas que se guardan en memoria, es decir, cuando reinicies MySQL, adios datos. No le encuentro ninguna utilidad la verdad, si quieres un almacenamiento temporal, que sentido tiene entonces usar un SGBD? Pues ninguno!.
  • Berkeley DB (BDB para los friends), una de las bases de datos openSource más famosa y utilizada. El motor es independiente de MySQL, con las ventajas e inconvenientes que esto pueda acarrear. Permite transacciones (COMMIT & ROLLBACK) y solo puede ejecutarse en sistemas operativos soportados (Linux x86 y Windows, si; Mac OS X feo y Linux AMD64/Alpha, no). Como curiosidad decir que su organización de ficheros se basa en solo dos, puesto que utiliza árboles B donde, en cada nodo, están tanto los datos como el índice primario (lo cual implica que será algo más lento a la hora de recorrerlo secuencialmente)
  • InnoDB, es el motor más avanzado (junto con BDB) en cuanto a opciones y funcionalidad. Permite transacciones seguras (COMMIT y tal) y está orientado a manejar grandes cantidad de datos. Realiza el bloqueo usando como granualidad la fila (BDB lo hace a nivel de página, es decir mayor salvo casos raros de filas enormes) e incluso soporta lecturas consistentes tanto bloqueantes como no bloqueantes.

Como reflexión final decir que los únicos motores que soportar transacciones seguras son BDB e InnoDB. BDB es externo a MySQL (se usa en muchos otros proyectos, como OpenLDAP por ejemplo…) y fue comprado por ORACLE hace unos meses (febrero)… lo mosqueante es que InnoDB también ha sido comprado por ORACLE (antes de la compra de BDB), por lo que así a lo tonto, ORACLE se ha hecho con el control de los únicos motores de MySQL que soportan transacciones, intrigante… y quizás preocupante… Y con esto y un bizcocho…

8 Thoughts on “Motores de almacenamiento de MySQL

  1. Interesante, no conocía los diferentes motores. ¿Los dos últimos al ser de Oracle hay que pagarlos o son gratis?

  2. siguen siendo software libre 100% (gratuitos y puedes bajar el código), pero como ahora ambas empresas que desarrollaban estos motores (Sleepycat e InnoBase) pertenecen a Oracle, da que pensar… a efectos prácticos y directos no tiene ninguna repercusión, salvo, quizás, que Oracle será quien mande ahora sobre la linea de desarrollo a seguir en ambos motores.

  3. Pingback: meneame.net

  4. Antes de nada, gracias por el sumario, muy esclarecedor.
    Sobre Berkeley DB, decir que además de organización en BTree, también soporta Hash, recno y queue. Para saber más pues en la página explican qué es cada una.
    Por lo demás hay que decir que si un producto lo sacas con licencia libre, si la siguiente versión la quieres sacar con licencia privativa, puedes, porque para eso es tuyo, pero la versión anterior sigue siendo SL. Y esto incluye compras entre compañías. Oracle ha comprado SleepyCat y eso significa que está en su mano el futuro de siguentes versiones e incluso del mantenimiento de las actuales, pero cualquiera puede comenzar un proyecto a partir de la última versión libre del producto, como se hizo con XFree y xorg.
    Lo que está claro, que mosquea, es que quiere poner travas a la expansión de MySQL, es normal, así que ya veremos lo que ocurre, pero que no cunda el pánico, la comunidad de SL siempre encuentra un camino, ¡¡usa la fuerza mysql…..!!
    Un saludo!

  5. mcamel on 26 September, 2006 at 10:59 said:

    El motor MEMORY es útil para realizar “cálculos” temporales rápidos.

    P.e., ciertas subconsultas en MySQL 4.1 son muy lentas o directamente no se pueden hacer, por lo que tendremos que realizar un SELECT “grande” y filtrar en el cliente la información.

    Una alternativa puede ser hacer un INSERT INTO temp_tbl SELECT FROM tabla_principal_tbl… y después hacer un segundo SELECT FROM temp_tbl…

    De todas formas yo le he usado para otro propósito:

    Tenía que procesar una colección de registros en el cliente, y en función del resultado, marcarlos con un 1 o un 0, para posteriormente hacer una consulta sobre la tabla original enlazando con los registros previamente marcados con 1.

    Como “truco” usé una tabla temporal en memoria de la que fui eliminando aquellos registros marcados con 0:

    a) CREATE TEMPORARY TABLE temp_tbl…
    b) INSERT INTO temp_tbl SELECT FROM tabla_principal_tbl…
    c) DELETE FROM temp_tbl WHERE…
    d) SELECT FROM tabla_principal_tbl INNER JOIN temp_tbl ON…

    También puede ser útil añadir columnas nuevas a temp_tbl donde almacenar resultados parciales de los cálculos.

  6. En el caso que comentas podría ser una solución válida apoyarte en el motor MEMORY, pero tengo mis dudas si no sería mejor hacer el primer select y luego ya tratar los datos desde fuera de MySQL…

  7. Anonymous on 19 February, 2009 at 3:28 said:

    esto no sirve para nada

  8. Muy buena explicacion. Entendi todo perfectamente 😀

Post Navigation