16.9. Mapa de desarrollo de MySQL Cluster

MySQL 5.0

16.9. Mapa de desarrollo de MySQL Cluster

En esta sección, discutimos los cambios en la implementación de MySQL Cluster en MySQL 5.0 comparadas con MySQL 4.1. También discutiremos nuestra planificación para futuras mejoras en MySQL Cluster planeadas para MySQL 5.1.

En el pasado hemos recomendado que los usuarios de MySQL Cluster no usen la versión 5.0 de MySQL ya que MySQL Cluster en las series 5.0.x no estaba completamente testeada. A partir de MySQL 5.0.3-beta la funcionalidad de clustering de MySQL 5.0 es comparable a la de MySQL 4.1. MySQL 4.1 es la recomendada para producción por ahora; sin embargo, MySQL 5.0 es de alta calidad también, y le animamos a testear Cluster en MySQL 5.0 si piensa que está interesado en usarla cuando enter en producción a finales de 2005. Hay pocos cambios entre implementaciones NDB Cluster en MySQL 4.1 y en 5.0, así que la actualización es relativamente sencilla y rápida.

Desde que MySQL 5.0.3-beta está disponible, casi todas las nuevas características significativas desarrolladas para MySQL Cluster van al árbol de MySQL 5.1 . Proporcionamos algunas pistas acerca de lo que Cluster en MySQL 5.1 incluirá en el final de esta sección (consulte Sección 16.9.2, “Mapa de desarrollo de MySQL 5.1 para MySQL Cluster”).

16.9.1. Cambios de MySQL Cluster en MySQL 5.0

MySQL 5.0.3-beta y posterior contiene un número de nuevas características que son de interés:

  • Condiciones Push-Down: Una consulta como

    SELECT * FROM t1 WHERE non_indexed_attribute = 1;
    

    usará un escaneo de toda la tabla y la condición se evaluará en los nodos de datos del cluster. Por lo tanto no es necesario enviar el registro a la red para evaluación. (Esto es, la transporte de función se usa, en lugar del transporte de datos.) Para este tipo de consultas debe observar un factor de incremento de velocidad de 5-10. Tenga en cuenta que esta característica actualmente está desactivada por defecto (pendiente de más testeo), pero debería funcionar en la mayoría de casos. Esta característica puede estar activada mediante el comando . Alternativamente, puede ejecutar mysqld con esta característica activada arrancando MySQL server con la nueva opción .

    Puede usar para determinar cuándo se usan las condiciones push-down .

    Un beneficio principal de este cambio es que las consultas se ejecutan en paralelo. Esto significa que las consultas contra columnas no indexadas pueden mejorar de 5 a 10 veces, veces por el número de nodos de datos, más rápido que préviamente, ya que CPUs múltiples pueden funcionar en la consulta en paralelo.

  • Decrementado uso de : En MySQL 5.0, cada registro consume aproximadamente 25 bytes de memoria índice, y cada índice único usa 25 bytes por registro de memoria índice (además de alguna memoria de datos ya que se almacena en una tabla separada). Esto es porque no hay almacenamiento de la clave primaria en la memoria índice.

  • Caché de consulta activada para MySQL Cluster: Consulte Sección 5.12, “La caché de consultas de MySQL” para información acerca de configurar el uso de la caché de consulta.

  • Nuevas optimizaciones: Una optimización que merece atención particular es que una interfaz de lectura batch se usa ahora en algunas consultas. Por ejemplo, considere la siguiente consulta:

    SELECT * FROM t1 WHERE  IN (1,2,3,4,5,6,7,8,9,10);
    

    Esta consulta se ejecutará 2 o 3 veces más rápido que en versiones anteriores de MySQL Cluster debido al hecho que todas las 10 búsquedas de clave se envían en un batch único en lugar de uno cada vez.

  • Límite en número de objetos de metadatos : En MySQL 4.1, cada base de datos de Cluster puede contener un máximo de 1600 objetos de metadatos, incluyendo tablas de base de datos, tablas de sistema, índices y BLOBs. En MySQL 5.0, esperamos incrementar este número a 20,320. Esperamos implementar esta mejora en MySQL 5.0.6 beta a mediados de 2005.

16.9.2. Mapa de desarrollo de MySQL 5.1 para MySQL Cluster

Aquí se habla de un reporte de estado basado en recientes commits en el árbol fuente MySQL 5.1 . Debería tenerse en cuenta que todo el desarrollo 5.1 está sujeto a cambio.

Actualmente hay 4 nuevas funcionalidades mayores en desarrollo para MySQL 5.1:

  1. Integración de MySQL Cluster con MySQL Replication: Esto hará posible actualizar desde cualquier MySQL Server en el cluster y tener MySQL Replication tratada por uno de los MySQL Servers en el cluster y la instalación de un esclavo consistente.

  2. Soporte para registros basados en disco: Los registros en disco se soportarán. Los campos índice incluyendo el índice hash de clave primaria debe almacenarse en RAM pero todos los otros campos pueden estar en disco.

  3. Registros de tamaño variable: Una columna definida como actualmente usa 260 bytes de almacenamiento independiente de lo que se almacena en un registro particular. En tablas MySQL 5.1 Cluster sólo la porción del campo tomada por el registro se almacena. Esto hará posible una reducción de los requerimientos de espacio para tales columnas por un factor de 5 en muchos casos.

  4. Partición definida por el usuario: Los usuarios serán capaces de definir particiones basadas en las partes de los campos de la clave primaria. El MySQL Server será capaz de descubrir si es posible de eliminar algunas de las particiones de la cláusula . La partición basada en , , , y será posible, así como subparticiones. Esta característica debe estar disponible para otros criterios.

Además, estamos trabajando para incrementar el límite de tamaño de 8k para los registros que contienen columnas de tipos distintos a BLOB o TEXT en tablas cluster. Esto es debido al hecho que los registros están fijados en tamaño y el tamaño de página es de 32,768 bytes (menos 128 bytes para la cabecera del registro.) Esto significa actualmente que si permitimos más de 8k por registro, cualquier espacio que quede (hasta aproximandamente 14,000 bytes) quedaría vacío. En MySQL 5.1, planeamos para arreglar esta limitación para que use más de 8k en un registro dado no resulta en que se gaste lo que queda de la página.