高度な同時書き込み、高書き込みDBのインフラストラクチャ

私の要件は次のとおりです。

• 3000接続
• 70-85％の書き込みと読み取り

現在、700の接続でHigh-CPU、エクストララージインスタンスを最大化しています。8コアすべてが最大化されています。メモリが十分であるため、同時接続の数だと思います。書き込み自体は非常に単純です（検証によって処理が遅くなります）。3000に拡張するには、現在のオプションである複数のサーバーに移動する必要があります。

• MySQLシャーディング
• MongoDBクラスター
• カサンドラ
• HadoopとMySQL（Hadoopキャッシュ、MySQLへの単一ダンプ）
• MongoDBとMySQL（Hadoopの代わりに、mongoをキャッシュに使用します）

この数の接続を処理するには、いくつかの質問があります。

1. MySQL Shardingは同時接続を処理できますか？
2. 単一のマスターがこれらの同時接続を処理できますか、またはMongoのようなマルチヘッドがより良いオプションですか？

問題をうまく説明していない場合は謝罪します。質問してください。

MySQLをメインデータベースとして使用している場合は、MySQLレプリケーション経由でスタートポロジを使用することを検討できます。

さて、あなたがUGHHH、ROFL、OMGをMySQLレプリケーションに言う前に、私に聞いてください。

スター型トポロジを使用すると、1つのDBサーバー（Distribution Mster [DM]と呼ばれる）に書き込み、SQLコマンドを複数のDBサーバーに送信できます。このようなDBインフラストラクチャをどのようにセットアップしますか？

ここに説明があります

5つのDBサーバー（サーバーA、B、C、D、E）がある

サーバーA

• MySQL Replicationセットアップでは、マスターになります
• DMとして特別な役割を果たす
• サーバーのマスターB、C、D、E
• すべてのテーブルはストレージエンジンBLACKHOLE（/ dev / null）を使用します
• バイナリログのみを保存します
• ベアメタルマシン
• 利点
  • DM上のすべてのテーブルがBLACKHOLEを使用するため、非常に高速な書き込み
  • 読み取りはDBアクティビティの15〜30％であるため、ネットワーク遅延は問題になりません。
  • すべてのスレーブはDMから厳密に更新されます

サーバーB、C、D、E

• Aの奴隷
• 重いSELECTの基盤となるサーバー
• サーバーは仮想またはベアメタルにすることができます
• ユーザーテーブルがストレージエンジンInnoDBを使用するすべてのサーバー
  • ウォームスタンバイDBサーバーとしてサーバーできます。
  • それに対して非侵入型バックアップを実行できます
• ユーザーテーブルがストレージエンジンMyISAMを使用するすべてのサーバー
  • 読み取り専用オプションを設定します
  • テーブルは、読み取りを高速化するために行フォーマットをやり直すことができます

以前にこれについての記事を書いたことがあります

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

MySQLレプリケーションを常に最高の状態に保つには

• MySQL 5.5を使用する
• 準同期レプリケーションを使用する
• InnoDBを調整してより多くのCPUを使用する

MySQL Clusterはシャーディングに対する別のアプローチかもしれません。こちらの投稿を確認してください。

私もCassandraの大ファンですが、データモデルと実行するクエリに大きく依存します。Cassandraは、ディスク上で常にシーケンシャルであるため、書き込みが非常に高速です。

マルチヘッド（3Kのアクティブな接続が本当に必要な場合に必要になる可能性があります）に進む場合は、おそらくRiakまたはCassandraを検討します。これらがどれだけうまく適合するかは、アプリが何をするかに大きく依存しますが、説明したことから、Riakのようなものに収まると思います。

そうは言っても、データをセグメント化するための適切な方法を見つけることができ、クロスシャードの必要性を最小限に抑えることができれば、シャードアプローチはかなり実行可能です。私はmysqlの指輪/星/ mmmから離れて、まっすぐなシャーディングに固執するだけです。実際、Postgresを使用する場合は、herokuなどのスキーマを使用して非常に簡単にプロトタイプを作成し、個々のノードの成長を開始するときにデータベースを分岐および分割できます。

ああ、私はあなたがこのようなものを垂直にスケーリングすることを試みることができると思いますが（すべての3K接続を処理する単一ノード）、クラウドでそれを行うことができるとは思いません。

特定のアプリケーションのオプションである場合は、非同期の方法を使用してデータベースにデータを書き込み（ワークキュー、バッチ挿入...）、および/またはいくつかのプロキシを前に置いてデータベースから多くのクライアント接続をシフトすることができます。

シャーディングを使用すると、通常はうまくスケーリングできます（2x db-servers == 2x接続）。ただし、データセットの性質とシャードに分割する方法に大きく依存します。

個人的には、管理のしやすさ、スケーラビリティ、一般的な使いやすさからMongoDBを好みます。また、実際にRDBMSが必要でない限り、no-SQLを使用します。

とはいえ、アプリケーションにとって最も意味のあるデータベースを選択してください。トランザクションが必要な場合、または結合なしでアプリを設計できない場合（または単純にそれらを使用する方が理にかなっている場合）、RDBMS（MySQL、PostGresなど）を使用します

私は個人的にMongoDBを好んでいますが、MySQLがスケーリングしないか、高いレートのトランザクションを処理できないという考えは、まったく間違っています。Facebookエンジニアリングチーム（およびその内部のMySQLチーム）は、詳細を詳しく説明しています。Etsy Opsチームのブログもご覧ください。MySQLも大好きです。

最後に、MySQLキャッシュにMongoDBを使用しません。そのためにMemcachedを使用します。

Redisは、特定のユースケースの処理に適したRAM内のキー値ストアでもあります。blog.agoragames.comには、いくつかのユースケースを説明するいくつかのブログエントリがあります。

No-SQLを検討している場合は、CouchDBもチェックアウトする必要があります。ただ、それは通常のmaintのが必要であることを認識して、それのディスク使用率ダウンを維持します。（Disk utilの速度と利便性を引き換えに...）

最後に、容量計画を予測するのは簡単ではありません。可能な限り現実的な条件でテストし、表示内容に基づいて修正する準備をする必要があります。悲しいことに、「コンピューターサイエンス」は科学と同じくらい芸術です。