web-dev-qa-db-ja.com

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

私の要件は：

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

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

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

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

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

私の問題をうまく説明していないとすみません。質問してください。

mysqlreplicationmongodbcassandra
18
Justin

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

UGHHH、ROFL、およびOMGをMySQLレプリケーションと言う前に、私に聞いてください。

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

ここに説明があります

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

サーバーA

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

サーバーB、C、D、E

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

私は以前にこれについて投稿したことがあります

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

5
RolandoMySQLDBA

MySQL Clusterは、シャーディングへの別のアプローチかもしれません。 ここで投稿を確認してください 。

私はまた、Cassandraの大ファンですが、それはデータモデルと実行するクエリに大きく依存します。 Cassandra書き込みは非常に高速です。なぜなら、それらは常にディスク上で連続しているからです。

2
gsb

マルチヘッドにする場合（本当に3Kのアクティブな接続が必要な場合に必要になるでしょう）おそらく、Riakまたは多分Cassandraを調べます。これは実際にアプリがどのように適合するかによって異なりますが、あなたが述べたことから、Riakのようなものに適合すると思います。

そうは言っても、データをセグメント化する良い方法を見つけることができ、クロスシャードの必要性を最小限に抑えることができれば、シャードアプローチはかなり実行可能のようです。私はmysqlのリング/スター/ mmmのものから離れて、ストレートシャーディングに固執します。実際、Postgresを使用するつもりであれば、herokuなどのスキーマを使用して簡単にプロトタイプを作成し、個々のノードを超えてデータベースをフォークして分割することができます。

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

2
xzilla

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

そうは言っても、アプリケーションにとって最も意味のあるDBを選択してください。トランザクションが必要な場合、または結合なしでアプリを設計できない場合（または、結合を使用した方がわかりやすい場合）、RDBMS（MySQL、PostGresなど）を使用します。

私は個人的にはMongoDBを好みますが、MySQLはスケーリングしないか、高率のトランザクションを処理できないという考えは純粋に誤りです。 Facebookエンジニアリングチーム（およびその中のMySQLチーム）は、これについて非常に詳しく説明しています。また、Etsy Opsチームのブログもご覧ください。 MySQLも大好きです。

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

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

No-SQLを考えている場合は、CouchDBもチェックしてください。ただ 通常のメンテナンスが必要なことに注意してください ディスクの使用率を抑えるためです。 （Disk utilの速度と利便性を犠牲にしています...）

最後に、キャパシティプランニングは予測が容易ではありません。できる限り現実的な条件でテストし、表示に基づいて修正する準備をする必要があります。残念ながら、「コンピュータサイエンス」は科学と同じくらいアートです。

1
gWaldo

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

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

1
powo