Mysql
 sql >> Datenbank >  >> RDS >> Mysql

MySQL Cluster (NDB) vs. MySQL Replication (InnoDB) für Rails 3-Apps:Vor-/Nachteile?

Es gibt einen guten Vergleich von InnoDB und MySQL Cluster (ndb), der kürzlich in den Dokumenten veröffentlicht wurde ... es lohnt sich, einen Blick darauf zu werfen:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

Die Cluster-Architektur besteht aus einem Pool von MySQL-Servern, auf die die Anwendung(en) zugreifen; Diese MySQL-Server speichern die Cluster-Daten nicht wirklich, die Daten werden über den unten stehenden Pool von Datenknoten verteilt. Jeder MySQL-Server hat Zugriff auf die Daten in allen Datenknoten. Wenn ein MySQL-Server ein Datenelement ändert, ist es sofort für alle anderen MySQL-Server sichtbar.

Offensichtlich macht es diese Architektur extrem einfach, die Datenbank zu skalieren. Im Gegensatz zum Sharding muss die Anwendung nicht wissen, wo sich die Daten befinden – sie kann einfach die Last auf alle verfügbaren MySQL-Server verteilen. Anders als beim Scale-out mit MySQL Replication Cluster können Sie Schreibvorgänge genauso gut skalieren wie Lesevorgänge. Neue Datenknoten oder MySQL-Server können zu einem bestehenden Cluster hinzugefügt werden, ohne dass der Dienst für die Anwendung verloren geht.

Die Shared-Nothing-Architektur von MySQL Cluster bedeutet, dass es eine extrem hohe Verfügbarkeit (99,999 %+) liefern kann. Jedes Mal, wenn Sie Daten ändern, werden diese synchron auf einen zweiten Datenknoten repliziert; Wenn ein Datenknoten ausfällt, werden die Lese- und Schreibanforderungen der Anwendungen automatisch vom Backup-Datenknoten verarbeitet.

Aufgrund der verteilten Natur von MySQL Cluster können einige Operationen langsamer sein (z. B. JOINs, die Tausende von Zwischenergebnissen haben – obwohl es eine Prototyplösung gibt, die dies angeht), aber andere können sehr schnell sein und extrem gut skalieren (z. B. primäre Schlüssel liest und schreibt). Sie haben die Möglichkeit, Tabellen (oder sogar Spalten) im Arbeitsspeicher oder auf der Festplatte zu speichern, und durch Auswahl der Speicheroption (mit Checkpoints auf der Festplatte im Hintergrund) können Transaktionen sehr sein schnell.

MySQL Cluster kann komplexer einzurichten sein als ein einzelner MySQL-Server, aber es kann verhindern, dass Sie Sharding oder Lese-/Schreib-Splitting in Ihrer Anwendung implementieren müssen. Schaukeln und Kreisverkehre.

Um die beste Leistung und Skalierbarkeit aus MySQL Cluster herauszuholen, müssen Sie möglicherweise Ihre Anwendung optimieren (siehe Whitepaper zur Cluster-Leistungsoptimierung:http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Wenn Sie die Anwendung besitzen, ist dies normalerweise keine große Sache, aber wenn Sie die Anwendung einer anderen Person verwenden, die Sie nicht ändern können, könnte dies ein Problem darstellen.

Eine letzte Anmerkung ist, dass es nicht alles oder nichts sein muss – Sie können einige Ihrer Tabellen im Cluster speichern und einige andere Speicher-Engines verwenden, dies ist eine Option pro Tabelle. Sie können auch zwischen Cluster und anderen Speicher-Engines replizieren (verwenden Sie beispielsweise Cluster für Ihre Laufzeitdatenbank und replizieren Sie dann zu InnoDB, um komplexe Berichte zu erstellen).