70.000レコード/秒で大きなデータボリュームを書き込むのはどうですか？

Question

おそらく誰かがこれについての意見を共有できますか？私は現在、1日あたり5億〜40億レコードをデータベースの1つ（または2つ）のテーブルに保存するソリューションを検討しています。最小書き込みレートは70,000レコード/秒です。レコードには約30の変数が含まれています。私たちは、CPU、メモリ、IOに関してマシンの最大容量までデータを毎時、並列に（データを分割して）ロードしたいと考えています。書き込み中は、照会が可能でなければならず、書き込み操作中には受け入れ可能なパフォーマンスを維持する必要があります。

私はウェブを閲覧して、他の人がこれらの数量をMySQLデータベースに並列に書き込もうとしているのかどうかを確認していますが、何も特定されていません。ほとんどの場合、トランザクションは1秒あたりのトランザクションを調べますが、ここで扱っているトランザクションではありません。私たちは生データを読み込んでおり、速く、並列で、停止時間ゼロで（つまり、ユーザーは利用可能なデータを照会できる必要があります）必要があります。この仕事をするためにMySQLを調べる価値があるのですか、ハードウェアで膨大な量を費やしていないのであれば、それを考慮してはいけませんか？

注：ディスクスペースは、マルチコア64ビット128GBサーバーで使用可能なGBit FC経由のSANストレージには問題ありません。私は詳細な技術的解決策を探しているのではなく、おそらく専門家の視点から実現可能性を探っています。

洞察力を評価してください。

---

コメントへの返信

各レコードは個別にカウントし、各変数は、可能な候補検索基準です。詳細はこちらから（10Dまで）

• 昨日のと古いデータは、カスタムAPIを介して
• データアクセス好ましくありません（SQLは、それは簡単ですために素晴らしいことだ）むしろのようなオープンスタンダードを好む照会可能である必要があります
• データ消費には、エンドユーザーのレポート作成のために上位レベルの履歴テーブルに格納されている（深夜以降、また統計的に最小/最大/平均に関係する時間も部分的に毎時）が含まれます。これと先に言及した問題/アドホック分析の生データの検索。
• 10日間のサイクルの終わりに1日分のデータを簡単に削除する必要があります。
• もう一度ハイライトしてください：配信は毎晩行われ、配信に追いつき、深夜のバックログは作成されません。要約は長時間延期することはできません。
• 検索結果は即時である必要はありませんが、10日間のボリューム全体で+/- 15分を超えないことが好ましいです。

Answer 1

このデータ量では、NoSQL（MongoDB、Cassandra、HBaseなど）を調べてみるべきだと思います。 MySQLでは、サーバーを大幅に拡張する必要があります。 〜1200インサート/秒を実行しようとしましたが、MySQLが失敗しました（またはハードウェアが失敗しました）。解決策はXCacheを使用していました（memcachedはその時点でも失敗しました）。 NoSQLを見てみると、あなたはそれを好きになるでしょう。

Answer 2

4B行×30×4バイトは約1/2TBです。私はあなたがこれを1台のマシンに入れておくことはできないと思っています。あなたのSANにも問題があるかもしれません。私はカサンドラを高い書き込み量のために構築しているので見ています。

Answer 3

私があなただったら、ソリューションをデータ収集サーバーとデータ分析サーバーに分けます。これはかなり一般的なパターンです。データウェアハウス（データ収集システムに異なるスキーマを使用できる可能性があります）に対してクエリとレポートが実行されます。 ETL（抽出、変換、ロード）プロセスを使用してデータウェアハウスにデータをロードします。このプロセスは非常に簡単です。

毎秒70Kの書き込みをどのようにサポートするかについては、専任のチームとインフラストラクチャーがなければ、ほとんどのRDBMSサーバーの能力をはるかに上回っていると言えます。あなたが仕事で学びたいことではありません。

NoSQLがより適しているようです。