Jest dobre porównanie InnoDB i MySQL Cluster (ndb), które niedawno opublikowano w dokumentacji... warto rzucić okiem:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html
Architektura klastra składa się z puli serwerów MySQL, do których mają dostęp aplikacje; te serwery MySQL w rzeczywistości nie przechowują danych klastra, dane są podzielone na pulę węzłów danych poniżej. Każdy serwer MySQL ma dostęp do danych we wszystkich węzłach danych. Jeśli jeden serwer MySQL zmieni fragment danych, jest on natychmiast widoczny dla wszystkich innych serwerów MySQL.
Oczywiście ta architektura sprawia, że skalowanie bazy danych jest niezwykle łatwe. W przeciwieństwie do shardingu aplikacja nie musi wiedzieć, gdzie przechowywane są dane — może po prostu równoważyć obciążenie na wszystkich dostępnych serwerach MySQL. W przeciwieństwie do skalowania w poziomie za pomocą klastra replikacji MySQL, możesz skalować zapisy tak samo dobrze, jak odczyty. Nowe węzły danych lub serwery MySQL można dodać do istniejącego klastra bez utraty usług dla aplikacji.
Architektura nie współdzielona MySQL Cluster oznacza, że może on zapewnić niezwykle wysoką dostępność (99,999%+). Za każdym razem, gdy zmieniasz dane, są one synchronicznie replikowane do drugiego węzła danych; jeśli jeden węzeł danych ulegnie awarii, żądania odczytu i zapisu aplikacji są automatycznie obsługiwane przez zapasowy węzeł danych.
Ze względu na rozproszony charakter klastra MySQL niektóre operacje mogą być wolniejsze (na przykład JOIN, które mają tysiące wyników pośrednich – chociaż istnieje rozwiązanie prototypowe, które rozwiązuje ten problem), ale inne mogą być bardzo szybkie i bardzo dobrze skalować (np. podstawowe klucz czyta i zapisuje). Masz możliwość przechowywania tabel (a nawet kolumn) w pamięci lub na dysku i wybierając opcję pamięci (ze zmianami zaznaczonymi na dysku w tle) transakcje mogą być bardzo szybko.
Klaster MySQL może być bardziej skomplikowany w konfiguracji niż pojedynczy serwer MySQL, ale może uniemożliwić implementację shardingu lub dzielenia odczytu/zapisu w aplikacji. Huśtawki i karuzele.
Aby uzyskać najlepszą wydajność i skalowalność klastra MySQL, może być konieczne dostosowanie aplikacji (zobacz oficjalny dokument dotyczący dostrajania wydajności klastra:http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Jeśli jesteś właścicielem aplikacji, zwykle nie jest to wielka sprawa, ale jeśli używasz aplikacji innej osoby, której nie możesz modyfikować, może to być problem.
Ostatnia uwaga jest taka, że nie musi to być wszystko albo nic — możesz wybrać przechowywanie niektórych tabel w klastrze, a niektóre przy użyciu innych silników pamięci masowej, jest to opcja dla każdej tabeli. Możesz także replikować między klastrem a innymi silnikami pamięci masowej (na przykład użyj klastra do swojej bazy danych w czasie wykonywania, a następnie replikuj do InnoDB, aby generować złożone raporty).
