new - ruby on rails mysql configuration

MySQL Cluster(NDB) vs MySQL Replication(InnoDB) para aplicaciones Rails 3: pros/contras?

Question

Estamos haciendo una descripción general de nuestros sistemas actuales, tratando de determinar si podemos mejorar el rendimiento y la confiabilidad.

Actualmente ejecutamos un montón de aplicaciones internas de Rails y nuestro sitio web basado en Rails. Algunos ya son Rails 3, algunos se están convirtiendo a Rails 3. Todos se conectan a la siguiente configuración de MySQL.

mysql01 ( master server) => mysql02 (slave) => (copias de seguridad de base de datos diarias en una unidad de disco, que se respalda diariamente, semanalmente, mensualmente y semestralmente).

Todas las escrituras ocurren en mysql01 y la mayoría de las lecturas breves también lo incluyen, algunas "lecturas que consumen más recursos" (como informes mensuales / semanales que tardan entre 3 y 10 minutos en ejecutar y volcar datos en csv o copias de seguridad) van al servidor mysql02. Recibimos aproximadamente 3-5,000 visitas por día a nuestro sitio, y tenemos entre 20 y 30 usuarios internos, que usan varias aplicaciones a diario para inventarios, procesamiento de pedidos, etc. Por lo tanto, estos servidores no están particularmente bajo cargas pesadas, aparte de los informes, que Ejecución del esclavo de todos modos.

Todos los servidores se ejecutan en un grupo de virtualized XEN en las máquinas virtuales de Debian Lenny.

Así que estamos haciendo una revisión de los sistemas, y alguien lanzó una sugerencia de cambiar a la configuración de MySQL Cluster (NDB) . Lo sé en teoría, pero en realidad nunca lo he ejecutado. Entonces, ¿alguien que tenga experiencia sabe de pro / contras contra nuestra configuración actual, y de cualquier advertencia particular cuando se trata de aplicaciones de Ruby / Rails?

Answer 1

Hay una buena comparación de InnoDB y MySQL Cluster (ndb) publicados recientemente en los documentos ... vale la pena echar un vistazo: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

La arquitectura del clúster consiste en un grupo de servidores MySQL a los que acceden las aplicaciones; estos servidores MySQL en realidad no almacenan los datos del clúster, los datos se dividen en el grupo de nodos de datos a continuación. Cada servidor MySQL tiene acceso a los datos en todos los nodos de datos. Si un servidor MySQL cambia una parte de los datos, entonces es instantáneamente visible para todos los otros servidores MySQL.

Obviamente, esta arquitectura hace que sea extremadamente fácil escalar la base de datos. A diferencia de la fragmentación, la aplicación no necesita saber dónde se guardan los datos: puede cargar el equilibrio entre todos los servidores MySQL disponibles. A diferencia de la ampliación con la replicación de MySQL, Cluster le permite escalar las escrituras tan bien como las lecturas. Se pueden agregar nuevos nodos de datos o servidores MySQL a un clúster existente sin pérdida de servicio para la aplicación.

La arquitectura compartida de MySQL Cluster significa que puede ofrecer una disponibilidad extremadamente alta (99.999% +). Cada vez que cambia los datos, se replican sincrónicamente en un segundo nodo de datos; si un nodo de datos falla, el nodo de datos de respaldo maneja automáticamente las solicitudes de lectura y escritura de aplicaciones.

Debido a la naturaleza distribuida de MySQL Cluster, algunas operaciones pueden ser más lentas (por ejemplo, JOINs que tienen miles de resultados provisionales, aunque hay una solución prototipo disponible que soluciona esto) pero otros pueden ser muy rápidos y pueden escalar extremadamente bien (ej. clave lee y escribe). Tiene la opción de almacenar tablas (o incluso columnas) en la memoria o en el disco y al elegir la opción de memoria (con los cambios marcados en el disco en el backgoround) las transacciones pueden ser muy rápidas.

MySQL Cluster puede ser más complejo de configurar que un solo servidor MySQL pero puede evitar tener que implementar fragmentación o división de lectura / escritura en su aplicación. Columpios y rotondas.

Para obtener el mejor rendimiento y escalabilidad de MySQL Cluster, es posible que necesite modificar su aplicación (consulte el documento técnico de ajuste del rendimiento del clúster: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Si posee la aplicación, esto normalmente no es un gran problema, pero si está utilizando la aplicación de otra persona que no puede modificar, entonces podría ser un problema.

Una nota final es que no necesita ser todo o nada: puede optar por almacenar algunas de sus tablas en Cluster y otras usando otros motores de almacenamiento, esta es una opción por tabla. También puede replicar entre Cluster y otros motores de almacenamiento (por ejemplo, use Cluster para su base de datos en tiempo de ejecución y luego replíquelo a InnoDB para generar informes complejos).