Project Voldemort (NoSQL Key-Value Datastore)サイトに入ったところ、何か面白いものがありました。
「MySQLレプリケーションとは異なり、読み取りと書き込みの両方が水平方向にスケーリングします」
このステートメントは、ValdemortをMySQLの従来のRDBMSと比較しようとしているようです。それでも、MySQLClusterはMySQLソリューションファミリーの一部でもあります。書き込みと読み取りを水平方向にスケーリングできます。
開示:私はMySQLCluster製品チームの一員です
255ノードの制限は、単一のクラスターに対するものです。これらの倍数でアプリケーションをサポートし、それらの間でレプリケーションを行うことができます。
ノードごとのパフォーマンスを考慮することも重要です。最近のテストでは、MySQLClusterは2つのソケットと24GBのRAM(つまり、低コスト、商品): http://mysql.com/why-mysql/benchmarks/mysql-cluster/
MySQL Clusterのシャーディングは自動です。これはデータベースレイヤーで行われ、デフォルトで主キーのハッシュに基づいています。これにより、範囲ベースのパーティショニングを使用する代替の自動シャーディングメカニズムよりも優れたシャード分散が得られる傾向があります。
ここには、アプリケーションとデータベースレベルのシャーディングを比較した適切な答えがあり、後者の利点は次のとおりです。 MySQLシャーディングとMySQL Cluster
AFAIK MySQL Clusterには拡張機能がありますが、実際には手動で拡張できます。実際、このようなスケーリングを行うには、より多くの計画とハードウェアが必要です。理由は次のとおりです。
「MySQLClusterを使用したWebデータベースのスケーリングに関するガイド」(2011年10月のホワイトペーパー)によると、小見出し「自動シャーディング」の下の5ページの段落4、5は次のとおりです。
MySQL Clusterは、アクティブ/アクティブなマルチマスターデータベースとして実装されているため、アプリケーションまたはSQLノードによって行われた更新は、クラスターにアクセスする他のすべてのノードですぐに利用できます。
テーブルは低コストのコモディティデータノードのプール全体で自動的にシャーディングされるため、データベースを水平方向に拡張して、SQLから、またはNoSQLAPIを介して直接アクセスされる読み取りおよび書き込みの多いワークロードに対応できます。最大255のノードがサポートされ、そのうち48はデータノードになります... MySQL Clusterは、集約パフォーマンスとノードごとのパフォーマンスの両方に優れており、使用率の低いハードウェアのラックをプロビジョニングおよび管理する必要がありません。
スケーリングは自動で行うことができますが、MySQLClusterアーキテクチャの範囲内です。
MongoDBは、シャードの前でmongosと呼ばれるルーティングプログラムを実行することで自動シャーディングできます。ルーターはデータの場所を認識しているため、アプリケーションはルーターに接続して通常どおりリクエストを発行できます。データを保存してリクエストを通信するサーバーの数に明らかな制限はありません。
MySQL ClusterをMongoDBと比較するだけで、両方で自動シャーディングを利用できることがわかります。主な違いは、MySQL Clusterインフラストラクチャ用に最大255台のサーバーを構成できるにもかかわらず、48個のデータノードに制限されていることです(残りの最大207個のノードはSQLノード[mysqldプロセスおよびその他のAPIを提供]と管理ノード[提供ndb_mgmdプロセス])。 MongoDBには、このようなアーキテクチャ上の制限はありません。 MySQL Clusterは、設計上、エルボールームを使い果たす可能性があります。
「読み取りと書き込みは水平方向にスケーリングする」と言うことは、これを内部で実行する製品にすぐに当てはまります。 MySQLレプリケーションを使用すると、このステートメントが当てはまります。どうして? MySQLレプリケーションは非同期です(MySQL 5.5でさえ半同期です)が、MySQL ClusterとMongoDB(および他のNoSQLデータベース)はACID準拠のバッキングと同期しています。