Zookeeper / rechoncha web frente a MySql NDB

Question

He estado leyendo el periódico Paxos, el FLP teorema etc. recientemente y evaluación de Apache Zookeeper para un proyecto. También he estado yendo a través rechoncha (servicio de bloqueo distribuidos de Google) y la diversa bibliografía sobre el mismo que está disponible en línea. Mi caso de uso fundamental para Zookeeper es implementar la replicación y la coordinación general de un sistema distribuido.

Me preguntaba sin embargo, ¿cuál es la ventaja específica de que Zookeeper o un sistema de bloqueo distribuido rechoncha como pone sobre la mesa. Básicamente Me pregunto por qué no puedo utilizar un NDB Cluster MySQL. Sigo escuchando que MySQL tiene una gran cantidad de problemas de replicación. Tenía la esperanza de algunos con más experiencia en el tema podría arrojar algo de luz sobre ella.

Gracias de antemano ..

Una lista simplista de mis requisitos:

• I tiene un sistema distribuido homogénea.
• I necesita un método para mantener el estado consistente a través de todos mis nodos.
• Mi sistema expone un servicio, y la interacción con los clientes dará lugar a un cambio en el estado colectivo de mi sistema.
• La alta disponibilidad es un objetivo, por tanto, un nodo que va abajo no debe afectar al servicio.
• espero que el sistema de servicio de al menos un par de 1000 req / seg.
• espero que el estado colectivo de que el sistema sea limitado en tamaño (básicamente inserciones / eliminaciones serán transitorios ... pero en estado estacionario, i esperar un montón de actualizaciones y lee)

Answer 1

Depende del tipo de datos que están manejando y la tolerancia de escala y culpa que va para.

Me puede responder desde el punto de vista ZooKeeper. Antes de empezar debo mencionar que ZooKeeper no es un clon rechoncha. Específicamente no lo hace directamente cerraduras. También está diseñado con diferentes requisitos del pedido de precisión y exactitud.

En ZooKeeper toda la copia del estado del sistema es residente en memoria. Los cambios se replican utilizando un protocolo de difusión atómica y se sincronizan en el disco (usando un diario de cambios) por la mayoría de los servidores ZOOKEEPER antes de ser procesados. Debido a esto ZooKeeper tiene un rendimiento determinista que puede tolerar fallos, siempre y cuando la mayoría de los servidores están en marcha. Incluso con un gran corte de luz, como un corte de energía, siempre y cuando la mayoría de los servidores vienen de nuevo en línea, se preservará el estado del sistema. La información almacenada es ZooKeeper por lo general se considera la verdad de tierra del sistema por lo que este tipo de consistencia y durabilidad garantías son muy importantes.

Las otras cosas que ZooKeeper da lo que tiene que ver con el seguimiento de los Estados coordinación dinámica. efímeras nodos permiten que haces para la detección de fallos fácil y pertenencia al grupo. Las garantías de pedidos le permiten hacer elección de líder y el bloqueo del lado del cliente. Por último, los relojes le permiten supervisar el estado del sistema y responder rápidamente a los cambios en el estado del sistema.

Así que si usted necesita para gestionar y responder a la configuración dinámica, detectar fallos, elegir líderes, etc. ZooKeeper es lo que busca. Si necesita almacenar gran cantidad de datos o necesita un modelo relacional para que los datos, MySQL es una opción mucho mejor.

Answer 2

MySQL con InnoDB ofrece una buena solución de propósito general, y es probable que mantenerse al día con los requisitos de rendimiento muy fácilmente en el hardware no muy caro. Se puede manejar fácilmente muchos miles de actualizaciones por segundo en un cuadro de doble núcleo cuádruple con discos decentes. El incorporada en la replicación asíncrona le conseguirá la mayor parte del camino para sus requisitos de disponibilidad -, pero es posible que pierda el valor de los datos de unos segundos si falla el primario. Algunos de estos datos perdidos podría ser recuperable al reparar la primaria, o podría ser recuperable a partir de sus registros de la aplicación: si se puede tolerar esto depende de cómo funciona el sistema. A menos pérdidas - pero más lento - alternativa es usar MySQL InnoDB con disco compartido entre las unidades principales y de conmutación: en este caso, la unidad de conmutación por error se hará cargo del disco cuando el principal falla, sin pérdida de datos - siempre y cuando la primaria no tener algún tipo de catástrofe disco. Si el disco compartido no está disponible, DRBD puede ser utilizado para simular esto copiando de forma sincrónica bloques de disco a la unidad de conmutación por error, ya que están escritos:. Que esto podría tener un impacto en el rendimiento

El uso de Innodb y una de las soluciones de replicación anteriores se consiguen los datos copiados a la unidad de conmutación por error, que es una gran parte del problema de recuperación resuelto, pero el pegamento adicional es necesario volver a configurar el sistema para que la unidad de conmutación por error en línea . Esto se realiza generalmente con un sistema de clúster como RHCS o marcapasos o un latido del corazón (en Linux) o la materia MS Cluster para Windows. Estos sistemas son conjuntos de instrumentos, y que se dejan a ensuciarse las manos la construcción de ellos en una solución que se ajuste a su entorno. Sin embargo, para todos estos sistemas hay un breve periodo de parada mientras que los avisos del sistema que el principal ha fallado, y vuelve a configurar el sistema para utilizar la unidad de conmutación por error. Esto podría ser decenas de segundos:. Tratar de reducir esto puede hacer que su sistema de detección de fallos demasiado sensible, y usted podría encontrar su sistema que se ha conmutado por error innecesariamente

Moverse hacia arriba, MySQL NDB se pretende reducir el tiempo de recuperación, y en cierta medida en la escala ayuda a su base de datos para mejorar el rendimiento. Sin embargo, MySQL tiene un NDB bastante estrecho rango de aplicabilidad. El sistema asigna una base de datos relacional a una tabla de dispersión distribuida, y es así que para consultas complejas que involucran múltiples se une a través de tablas, hay un poco de tráfico entre el componente de MySQL y los componentes de almacenamiento (los nodos NDB) realizar consultas complejas correr lento. Sin embargo, las consultas que se ajustan bien corren muy rápido de hecho. He mirado en este producto un par de veces, pero mis bases de datos existentes han sido demasiado complicado encajar bien y requeriría una gran cantidad de rediseño para obtener un buen rendimiento. Sin embargo, si usted está en la etapa de diseño de un nuevo sistema, NDB que funcionan bien si se puede cargar con sus limitaciones en mente a medida que avanza. Además, es posible encontrar que necesita un buen número de máquinas para proporcionar una buena solución NDB: un par de nodos de MySQL más 3 o más nodos NDB - aunque los nodos MySQL y NDB pueden coexistir si sus necesidades de rendimiento no son demasiado extremas.

A pesar de MySQL NDB no puede hacer frente a la pérdida total del sitio - fuego en el centro de datos, errores de administración, etc. En este caso, normalmente es necesario otro flujo de replicación corriendo a un sitio DR. Esto normalmente se realiza de forma asíncrona para que repuntes de conectividad en el enlace entre sitios no se cala toda su base de datos. Esto se proporciona con la opción de replicación geográfica del NDB (en la versión de pago para telecomunicaciones), pero creo que MySQL 5.1 y superior puede proporcionar de forma nativa.

Por desgracia, sé poco acerca de Zookeeper y rechoncha. Esperemos que alguien más puede recoger estos aspectos.