Blog de Laura Berdasco

En el proyecto que estamos desarrollando necesitamos, antes que nada, una alta y fácil escalabilidad del sistema de datos y por eso, en el momento de escoger el tipo de sistema de bases de datos que íbamos a utilizar pensamos como primera opción en el cluster de MySQL. MySQL Cluster nos permitía tener esa flexibilidad, además de una simple replicación y transmisión de los datos… en un principio, creímos que la elección era acertada. Aún así, nos quedaban cosas por descubrir.

Intentamos trasladar la idea del Cluster y su montaje a un entorno EC2 de Amazon con su almacenamiento en nube (Elastic Compute Cloud) -más información sobre EC2 en los blogs de Santi y Xavi, o en la página oficial de Amazon EC2- y algo empezó a no cuadrar. Nos dimos cuenta, primeramente, que MySQL Cluster es un sistema cuyo uso es recomendado en redes locales que permitan una rápida velocidad y no es un sistema orientado a sistemas web; aún así, decidimos seguir adelante.

Otra piedra en el camino la encontramos unas horas más tarde, cuando leímos (en algún apartado de la documentación de MySQL Cluster) que la seguridad entre la comunicación de los nodos de datos dejaba bastante que desear ya que ésta no estaba encriptada y corrías el peligro de que pudieran interceptar informaciones del sistema. Es por eso que se recomendaba la proximidad entre nodos; nuestra idea era crear diferentes instancias en EC2 que sirvieran como nodos de datos independientes y Amazon no te garantiza ningún tipo de “proximidad” entre instancias (si es que puede hablarse de proximidad como una propiedad realmente física). Aún así, decidimos arriesgarnos a continuar con nuestra primera solución.

Algunos dicen que nuestro sistema, en papel, está muy bien organizado y una vez implementado la mitad de los elementos que aparecen en el modelo de datos desaparecen. Otros dicen que no es necesario el uso de Foreign Keys (claves foráneas) en el momento real de la implementación. Aún así, nosotros estamos en la convicción de que si que lo son y por eso queríamos que nuestro sistema de base de datos las tuviera en cuenta; no importa que digáis que esta es una reflexión demasiado metódica, somos estudiantes en su último año de carrera y apostamos por un sistema bien hecho desde el principio. Por esto, cuando vimos que el motor del Cluster (ndbcluster) no soportaba claves foráneas decidimos no jugar más con dicha estructura.

Nos estuvimos peleando durante varias horas barajando diferentes motores e información diversa de sistemas de bases de datos y finalmente nos dimos cuenta que el propio MySQL tiene un sistema de replicación master-slave que permite el uso de diferentes motores para el master y para el slave. Concretamente, podíamos tener en el master el motor de MySQL InnoDb que si que soporta el uso de claves foráneas (tan importantes en nuestro sistema) y utilizar el motor MyIsam para los slaves. Este sistema se puede montar fácilmente en un entorno EC2, guardando todos los datos en un volumen EBS y utilizando las instancias para montar el master-slave sin contener datos propios. Esta es la última deducción, ya veremos si finalmente es la acertada.

En los próximos días publicaremos las pruebas que vayamos haciendo en su construcción en EC2.

Esto es todo por hoy desde el zulo, pingüinos y manzanitas world! (hoy sin jefe…)