Il y a une bonne comparaison d'InnoDB et de MySQL Cluster (ndb) récemment publiée dans la documentation... ça vaut le coup d'œil :http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html
L'architecture de cluster consiste en un pool de serveurs MySQL auxquels accèdent les applications ; ces serveurs MySQL ne stockent pas réellement les données du cluster, les données sont partitionnées sur le pool de nœuds de données ci-dessous. Chaque serveur MySQL a accès aux données de tous les nœuds de données. Si un serveur MySQL modifie une donnée, elle est instantanément visible par tous les autres serveurs MySQL.
De toute évidence, cette architecture facilite extrêmement la mise à l'échelle de la base de données. Contrairement au sharding, l'application n'a pas besoin de savoir où se trouvent les données - elle peut simplement équilibrer la charge sur tous les serveurs MySQL disponibles. Contrairement à la mise à l'échelle avec la réplication MySQL, le cluster vous permet de mettre à l'échelle les écritures aussi bien que les lectures. De nouveaux nœuds de données ou serveurs MySQL peuvent être ajoutés à un cluster existant sans perte de service pour l'application.
L'architecture sans partage de MySQL Cluster signifie qu'il peut offrir une disponibilité extrêmement élevée (99,999 %+). Chaque fois que vous modifiez des données, elles sont répliquées de manière synchrone sur un deuxième nœud de données ; si un nœud de données tombe en panne, les demandes de lecture et d'écriture des applications sont automatiquement gérées par le nœud de données de sauvegarde.
En raison de la nature distribuée de MySQL Cluster, certaines opérations peuvent être plus lentes (par exemple, les JOIN qui ont des milliers de résultats intermédiaires - bien qu'il existe une solution prototype disponible qui résout ce problème), mais d'autres peuvent être très rapides et peuvent évoluer extrêmement bien (par exemple, clé lit et écrit). Vous avez la possibilité de stocker des tables (ou même des colonnes) en mémoire ou sur disque et en choisissant l'option de mémoire (avec des modifications pointées sur le disque en arrière-plan), les transactions peuvent être très rapide.
MySQL Cluster peut être plus complexe à configurer qu'un seul serveur MySQL, mais cela peut vous éviter d'avoir à implémenter le sharding ou le fractionnement en lecture/écriture dans votre application. Balançoires et manèges.
Pour obtenir les meilleures performances et l'évolutivité de MySQL Cluster, vous devrez peut-être modifier votre application (voir le livre blanc sur le réglage des performances du cluster :http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Si vous possédez l'application, ce n'est normalement pas un gros problème, mais si vous utilisez l'application de quelqu'un d'autre que vous ne pouvez pas modifier, cela pourrait être un problème.
Une dernière note est qu'il n'est pas nécessaire que ce soit tout ou rien - vous pouvez choisir de stocker certaines de vos tables dans Cluster et d'autres en utilisant d'autres moteurs de stockage, il s'agit d'une option par table. Vous pouvez également répliquer entre Cluster et d'autres moteurs de stockage (par exemple, utiliser Cluster pour votre base de données d'exécution, puis répliquer vers InnoDB pour générer des rapports complexes).
