6

テラバイト規模のデータ ボリュームを処理でき、可用性が高い (ファイブ ナイン) MySQL データベースを提供するためのソリューションを検討する必要があります。データベースの各行には、タイムスタンプと最大 30 個の浮動小数点値が含まれる可能性があります。予想されるワークロードは最大 2500 挿入/秒です。クエリの頻度は低くなる可能性がありますが、おそらく単一のテーブルのみを対象としますが、サイズが大きくなる可能性があります (100Gb のデータが含まれる可能性があります)。

MySQL Cluster が HA 製品であることを考慮して、私は MySQL Cluster を見てきました。データ量が多いため、ディスク ベースのストレージを利用する必要があります。現実的には、メモリに保持できるのはタイムスタンプだけで、他のすべてのデータはディスクに保存する必要があると思います。

この規模のデータベースで MySQL Cluster を使用した経験のある人はいますか? それは実行可能ですか？ディスクベースのストレージはパフォーマンスにどのように影響しますか?

また、この量のデータに必要な可用性を実現する方法について、他の提案も受け付けています。たとえば、標準の MySQL インスタンスのクラスタリングを処理するために、Sequoiaのようなサードパーティのライブラリを使用する方がよいでしょうか? または、MySQL レプリケーションに基づくより単純なソリューションですか?

唯一の条件は、MySQL ベースのソリューションである必要があるということです。私たちが扱っているデータに MySQL が最適な方法だとは思いませんが、それは難しい要件です。

4

4 に答える 4

3

速度的には、それは処理できます。サイズに関しては、問題はデータのサイズではなく、インデックスがメモリ内に完全に収まる必要があるため、インデックスのサイズです。

より良い回答を提供できれば幸いですが、ハイエンド データベースの作業はタスクに大きく依存します。さらに役立つには、データで何が起こっているかについてもっと知る必要があります。

于 2009-05-11T22:17:46.843 に答える
2

さて、私はmySQL が難しい要件であるという部分を読みました。

そうは言っても、あなたが話しているワークロード-2500回の挿入/秒、まれなクエリ、データセット全体の最大10％の結果セットを持つ可能性が高いクエリ-はほぼ悲観的であることを最初に指摘させてください.あらゆるリレーショナル データベース システムに対応します。

(これはむしろ、9600 ボーの RS-422 回線を介して 100 メガバイトのプログラム データを 300 秒以内 (これも厳しい要件) でロードするという厳しい要件があったプロジェクトを思い起こさせます。 ) 1kbyte/sec × 300 秒 = 300kbyte は通信していなかったようです。)

それから「最大30個のフロートを含む」という部分があります。言い回しは、少なくとも、挿入あたりのサンプル数が可変であることを示唆しています。これは、正規化の問題を示唆しています。または、各行を 30 エントリ幅にして NULL を使用する必要があります。

しかし、そうは言っても、あなたは 300Kbytes/sec と 2500 TPS について話しているのです (これが実際には無関係なサンプルのシーケンスであると仮定して)。この一連のベンチマークは、少なくとも、可能性の範囲外ではないことを示唆しています。

于 2009-05-11T23:58:07.070 に答える
2

この記事は、大規模な MySQL データベースの速度を低下させる原因を特定するのに非常に役立ちます。

于 2009-05-12T00:01:16.877 に答える
1

おそらく、休止状態のシャードを試して、それぞれ 1/2 テラバイトの 10 ノードで MySQL を実行して、5 テラバイトを処理できるようにします;) 制限をはるかに超えていると思いますか?

于 2010-11-23T17:27:02.677 に答える