Der er en god sammenligning af InnoDB og MySQL Cluster (ndb), der for nylig blev sendt til docs...værd at tage et kig på:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html
Cluster-arkitekturen består af en pulje af MySQL-servere, der tilgås af applikationen/applikationerne; disse MySQL-servere gemmer faktisk ikke Cluster-dataene, dataene er opdelt over puljen af dataknudepunkter nedenfor. Hver MySQL-server har adgang til dataene i alle dataknuderne. Hvis en MySQL-server ændrer et stykke data, er det øjeblikkeligt synligt for alle de andre MySQL-servere.
Naturligvis gør denne arkitektur det ekstremt nemt at udskalere databasen. I modsætning til sharding, behøver applikationen ikke at vide, hvor dataene opbevares - den kan blot indlæse balance på tværs af alle tilgængelige MySQL-servere. I modsætning til udskalering med MySQL-replikering giver Cluster dig mulighed for at skalere skrivninger lige så godt som læsninger. Nye dataknuder eller MySQL-servere kan føjes til en eksisterende klynge uden tab af service til applikationen.
MySQL Clusters shared-nothing-arkitektur betyder, at den kan levere ekstrem høj tilgængelighed (99,999%+). Hver gang du ændrer data, replikeres det synkront til en anden datanode; hvis en dataknude fejler, håndteres applikationernes læse- og skriveanmodninger automatisk af backupdataknuden.
På grund af den distribuerede karakter af MySQL Cluster kan nogle operationer være langsommere (for eksempel JOINs, der har tusindvis af foreløbige resultater - selvom der er en prototypeløsning tilgængelig, som adresserer dette), men andre kan være meget hurtige og kan skaleres ekstremt godt (f.eks. primær nøgle læser og skriver). Du har mulighed for at gemme tabeller (eller endda kolonner) i hukommelsen eller på disk, og ved at vælge hukommelsesindstillingen (med ændringer markeret til disk i baggrunden) kan transaktioner være meget hurtigt.
MySQL Cluster kan være mere kompleks at konfigurere end en enkelt MySQL-server, men det kan forhindre dig i at skulle implementere sharding eller læse/skriveopdeling i din applikation. Gynger og rundkørsler.
For at få den bedste ydeevne og skalerbarhed ud af MySQL Cluster skal du muligvis finjustere din applikation (se hvidbogen om Cluster-ydeevnejustering:http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Hvis du ejer applikationen, er dette normalt ikke en stor sag, men hvis du bruger en andens applikation, som du ikke kan ændre, kan det være et problem.
En sidste bemærkning er, at det ikke behøver at være alt eller intet - du kan vælge at gemme nogle af dine tabeller i Cluster og nogle ved at bruge andre storage-motorer, dette er en per-table mulighed. Du kan også replikere mellem Cluster og andre storage-motorer (brug f.eks. Cluster til din runtime-database og derefter replikere til InnoDB for at generere komplekse rapporter).