メッセージング システムがあるとします。このシステムには、何百万ものエントリが送信されて報告されており、その数は 1 時間ごとに 100K ずつ増加しています。2 つのサービスが db にアクセスします。1 つは送信者、もう 1 つはレポーターです。では、最大のパフォーマンスを得るために何を提案しますか? データベースはどのように設計できますか?
また、この大量のデータベースをフルフィルするために、mysql、postgresql、mongodb などの中でどのオープンソース RDBMS を提案しますか?
ありがとう
予想されるデータ量に関するいくつかのコメントを除いて、要件に関する多くの情報を実際に提供していません。大量のデータを単純に保存するだけでは、真の本質的な価値はありません。真の価値をもたらすのは、そのデータにアクセスできる能力です。したがって、データベースから情報を取得する方法を知ることは、保存するデータの量よりも重要です。
これらのメッセージは本当に MongDB のようなドキュメント データベースを必要としますか、それとも Postgresql や MySQL のような単純な RDBMS を使用するのに十分な構造になっていますか。全文検索機能が必要ですか? このメッセージ データに対して実行されるクエリの頻度と種類は? 自分のTwitterを書こうとしていますか？
それらが現在のデータ ボリュームである場合は、復元力のために db レプリケーションを使用することを検討してください。おそらく投稿された日付ごとに、メッセージ テーブルを分割することを検討してください。Konerakが提案したように、マスター/スレーブ（またはマルチマスター/マルチスレーブ）を使用してください。照会される可能性は低いが、まだ使用可能な古いメッセージのアーカイブ テーブルの可能性を調べてください。オラクルのような商用データベースが提供できるものを見てください。SO のようなサイトで無料のアドバイスを求めるだけでなく、専門家にデータベースのパフォーマンスの調整を手伝ってもらいましょう。
ハードウェアも考慮してください...ボリュームを支援するための複数の負荷分散サーバー (純粋に新しいメッセージを受け入れるための 14 台の専用サーバーと、データのクエリ用に調整された 3 台の高性能サーバーがあります)。