Zookeeper/Chubby -vs- MySql NDB

Question

J'ai récemment lu l'article de Paxos, le théorème de FLP, etc. et j'évaluais Apache Zookeeper pour un projet. Je suis également passé par Chubby (service de verrouillage distribué de Google) et la littérature à ce sujet qui est disponible en ligne. Mon principe de base pour Zookeeper est d'implémenter la réplication et la coordination générale pour un système distribué. Je me demandais juste, cependant, quel est l'avantage spécifique que Zookeeper ou un système de verrouillage distribué de type Chubby apporte à la table. Fondamentalement, je me demande juste pourquoi je ne peux pas simplement utiliser un cluster NDB MySQL. Je n'arrête pas d'entendre que MySQL a beaucoup de problèmes de réplication. J'espérais que certains ayant plus d'expérience sur le sujet pourraient nous éclairer.

Merci à l'avance ..

Une liste simpliste de mes exigences:

• J'ai un système distribué homogène.
• J'ai besoin de moyens pour maintenir un état cohérent sur tous mes nœuds.
• Mon système expose un service, et l'interaction avec les clients entraînera des changements dans l'état collectif de mon système.
• La haute disponibilité est un objectif, donc un nœud en panne ne doit pas affecter le service.
• Je m'attends à ce que le système réponde au moins à quelques 1000 req/sec.
• je me attends à l'état collectif du système à limité en taille (essentiellement insertions/suppressions seront transitoires ... mais dans l'état d'équilibre, je pense beaucoup de mises à jour et lit)

Answer 1

Cela dépend du type de données que vous gérez et de l'échelle et de la tolérance de panne que vous recherchez.

Je peux répondre du point de vue ZooKeeper. Avant de commencer je dois mentionner que ZooKeeper n'est pas un clone Chubby. Plus précisément, il ne fait pas de verrous directement. Il est également conçu en fonction de différentes exigences de commande et de performance.

Dans ZooKeeper, l'intégralité de l'état du système est résident en mémoire. Les modifications sont répliquées à l'aide d'un protocole de diffusion atomique et synchronisées sur disque (à l'aide d'un journal des modifications) par une majorité de serveurs ZooKeeper avant d'être traitées. À cause de cela, ZooKeeper a des performances déterministes qui peuvent tolérer des échecs tant que la majorité des serveurs sont en hausse. Même avec une grosse panne, comme une panne de courant, tant que la majorité des serveurs reviennent en ligne, l'état du système sera préservé. L'information stockée est ZooKeeper est généralement considéré comme la vérité du système de sorte que les garanties de cohérence et de durabilité sont très importantes.

Les autres choses que ZooKeeper vous donne concernent la surveillance de l'état de coordination dynamique. Les noeuds éphémères vous permettent de détecter facilement les échecs et d'appartenir à un groupe. Les garanties de commande vous permettent d'effectuer l'élection du responsable et le verrouillage côté client. Enfin, les montres vous permettent de surveiller l'état du système et de réagir rapidement aux changements d'état du système. Donc, si vous avez besoin de gérer et de répondre à la configuration dynamique, de détecter les échecs, d'élire des leaders, etc. ZooKeeper est ce que vous cherchez. Si vous avez besoin de stocker beaucoup de données ou si vous avez besoin d'un modèle relationnel pour ces données, MySQL est une bien meilleure option.

Answer 2

MySQL avec InnoDB offre une bonne solution polyvalente, et répondra probablement assez facilement à vos exigences de performance sur du matériel pas trop cher. Il peut facilement gérer plusieurs milliers de mises à jour par seconde sur une boîte quadricœur double avec des disques décents. La réplication asynchrone intégrée vous permettra d'obtenir la plupart de vos besoins en termes de disponibilité, mais vous risquez de perdre quelques secondes de données si le serveur principal échoue. Certaines de ces données perdues peuvent être récupérées lorsque le primaire est réparé, ou peuvent être récupérées à partir des journaux de vos applications: si vous pouvez tolérer cela dépend du fonctionnement de votre système. Une alternative moins difficile - mais plus lente - consiste à utiliser MySQL Innodb avec un disque partagé entre les unités Primary et Failover: dans ce cas, l'unité Failover prendra en charge le disque lorsque le Primary échoue sans perte de données - tant que le Primary n'a pas eu une sorte de catastrophe de disque. Si le disque partagé n'est pas disponible, DRBD peut être utilisé pour simuler ceci en copiant de manière synchrone des blocs de disque dans l'unité de basculement telle qu'elle est écrite: cela peut avoir un impact sur les performances. L'utilisation de Innodb et de l'une des solutions de réplication ci-dessus permet de copier vos données dans votre unité de basculement, ce qui représente une grande partie du problème de récupération résolu, mais vous devez ajouter de la colle pour reconfigurer votre système. ligne. Ceci est généralement effectué avec un système de cluster comme RHCS ou Pacemaker ou Heartbeat (sur Linux) ou MS Cluster pour Windows. Ces systèmes sont des boîtes à outils, et il vous reste à vous salir les mains pour les intégrer dans une solution adaptée à votre environnement. Cependant, pour tous ces systèmes, il y a une brève période de panne pendant laquelle le système remarque que le primaire a échoué et reconfigure le système pour utiliser l'unité de basculement. Cela peut prendre plusieurs dizaines de secondes: essayer de réduire cela peut rendre votre système de détection des pannes trop sensible et vous risquez de voir votre système basculer inutilement. MySQL Le NDB est conçu pour réduire le temps de récupération et, dans une certaine mesure, pour améliorer la performance de votre base de données. Cependant, MySQL NDB a une gamme d'applicabilité assez étroite.Le système mappe une base de données relationnelle sur une table de hachage distribuée. Par conséquent, pour les requêtes complexes impliquant plusieurs jointures entre les tables, le trafic entre le composant MySQL et les composants de stockage (les nœuds NDB) est lent. Cependant, les requêtes qui vont bien vont très vite. J'ai regardé ce produit quelques fois, mais mes bases de données existantes ont été trop compliquées pour bien s'adapter et nécessiteraient beaucoup de refonte pour obtenir de bonnes performances. Cependant, si vous en êtes à l'étape de la conception d'un nouveau système, le NDB fonctionnerait bien si vous pouviez garder ses contraintes à l'esprit au fur et à mesure. En outre, vous pourriez avoir besoin de plusieurs machines pour fournir une bonne solution NDB: deux nœuds MySQL et trois nœuds NDB ou plus - bien que les nœuds MySQL et NDB puissent coexister si vos besoins de performance ne sont pas trop extrêmes.

Même MySQL NDB ne peut pas faire face à la perte totale de site - incendie au centre de données, erreur d'administration, etc. Dans ce cas, vous avez généralement besoin d'un autre flux de réplication vers un site de reprise. Cela se fera normalement de manière asynchrone, de sorte que la connectivité blips sur le lien inter-site ne bloque pas toute votre base de données. Ceci est fourni avec l'option de réplication géographique du NDB (dans la version payante de telco), mais je pense que MySQL 5.1 et les versions supérieures peuvent le fournir de manière native.

Malheureusement, je connais peu de Zookeeper et Chubby. J'espère que quelqu'un d'autre peut prendre ces aspects.