Recomendaciones con MySQL Cluster

Tiempo hace que suelo “pelearme” con MySQL Cluster y, hay que decir que, como casi todo en esta vida, tiene cosas buenas y cosas no tan buenas.

No voy a evaluarlo pero se puede decir que en general es un buen motor de bases de datos, siempre y cuando se utilice en un contexto adecuado. Este sistema está pensado para sistemas en cluster, donde prima la disponibilidad de los datos a la velocidad de acceso a los mismos, con consultas sencillas. Cuando las consultas SQL son complejas, como podría ser al obtener informes, MySQL Cluster puede presentar problemas de rendimiento. Sin embargo, en otros contextos, este motor puede ser tan rápido como otro cualquiera con la ventaja de un cluster de datos. Un buen diseño de la aplicación es, por tanto, fundamental.

Aunque en su nombre esté la palabra “MySQL” no hay que confundirlo con el motor de bases de datos MySQL. Quien piense que es igual y se programa igual ya se equivoca y, seguro, no obtendrá los resultados que espera.

Podríamos decir que para trabajar con MySQL Cluster, desde el punto de vista de la programación, habría que tener en cuenta los siguientes factores:

  1. MySQL Cluster no es el “MySQL normal”. Por tanto, se le debe prestar atención a las particularidades de un cluster de datos, con diferentes máquinas.
  • Consultas simples. Las consultas complejas están desaconsejadas, incluso según indican White Papers de MySQL. Esto es por la propia naturaleza del cluster, que necesita tener la información replicada.
  • A más nodos mejor rendimiento. Al menos en teoría. Ya que se guarda la información repartida por diferentes nodos, a más nodos se debería repartir la carga de trabajo.
  • Buen diseño de bases de datos. Poner mucha atención al diseño de la base de datos. Realizar un diseño correcto de la misma que minimice el número de Joins es fundamental. Es muy corriente que un programador se deje llevar a la hora de diseñar una base de datos por lo fácil, pero hay que tener en cuenta, tanto para MySQL Cluster como para cualquier otro motor, que un buen diseño de la base de datos te puede salvar de futuros problemas de rendimiento.
  • Particionar los datos. Si el rendimiento es fundamental, se pueden repartir los datos en función de claves primarias por los diferentes nodos de tal forma que todos las tuplas relativas a una misma clave primaria siempre se encuentre en el mismo nodo, lo que optimiza las consultas.
  • Uso adecuado de índices. A diferencia de MySQL, me encuentro muy a menudo que MySQL Cluster no elije de forma correcta el índice de búsqueda. Por tanto, se hace indispensable el uso de sentencias USE INDEX que mejoren los resultados.
  • Analizar consultas adecuadamente. Las consultas no son cualquier cosa. Escribir unas consultas de una forma o de otra puede llegar a mejorar hasta en un 100% el rendimiento de la misma. Por tanto, el uso de la sentencia EXPLAIN es necesaria, sobre todo cuando las consultas se complican.
  • Dividir consultas. Si el rendimiento no es el adecuado, siempre es mejor lanzar muchas consultas sencillas que una compleja.
De entre todas, las más importantes diría que son el uso adecuado de índices y un buen diseño de la base de datos y, por tanto, de la aplicación.