2 millions de bases de données ? Je suppose que vous vouliez dire "lignes".
Quoi qu'il en soit, concernant les limitations :l'une des choses les plus importantes à garder à l'esprit est que NDB/MySQL Cluster n'est pas une base de données à usage général. Plus particulièrement, les opérations de jointure, mais aussi les sous-requêtes et les opérations de plage (requêtes telles que :commandes créées entre maintenant et il y a une semaine), peuvent être considérablement plus lentes que ce à quoi vous pourriez vous attendre. Cela est dû en partie au fait que les données sont réparties sur plusieurs nœuds. Bien que certaines améliorations aient été apportées, les performances de Join peuvent toujours être très décevantes.
D'un autre côté, si vous devez gérer de nombreuses transactions simultanées (de préférence petites) (généralement des mises à jour/insertions/suppressions de lignes uniques par clé primaire) et que vous devez conserver toutes vos données en mémoire, cela peut être très solution évolutive et performante.
Vous devriez vous demander pourquoi vous voulez un cluster. Si vous voulez simplement votre base de données ordinaire que vous avez maintenant, sauf avec une disponibilité supplémentaire de 99 999 %, vous risquez d'être déçu. Certes, le cluster MySQL peut vous offrir une grande disponibilité et une grande disponibilité, mais la charge de travail de votre application peut ne pas être très bien adaptée aux choses pour lesquelles le cluster est bon. De plus, vous pourrez peut-être utiliser une autre solution de haute disponibilité pour augmenter la disponibilité de votre base de données par ailleurs traditionnelle.
BTW - voici une liste des limitations selon la doc :http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
Mais quoi que vous fassiez, essayez le cluster, voyez si c'est bon pour vous. Le cluster MySQL n'est pas "MySQL + 5 nines". Vous le saurez en essayant.
