実際、あなたの質問には実際の調査が欠けているため、不明確でトピックから少し外れていますが、このトピックについていくつかの指針を示します。多分彼らはあなたを助けるでしょう。
はい、MySQL、MSSQL、または Postgre SQL と同様に、MongoDB はこのワークロードを処理できます。このデータセットは、データベースにとって目新しいものではありません。はい、1 秒間に 9,000 件のツイートと 1 日あたり 5 億件のツイート ( http://yearinreview.twitter.com/en/tps.html ) を保存している場合は、テクノロジの選択を非常に慎重に検討する必要があると思います (Twitter が行ったように)彼らが NoSQL ルートを選択したとき) しかし、保存しているのはそれよりはるかに少ないです。ただし、このシナリオでも、適切なセットアップ (Facebook はこちら) を使用すれば、MySQL はそのような負荷も処理できることが証明されています。
したがって、これは問題ではありません:このデータベースはこれを処理できますか? それは、私のデータベースがこれをどのように処理できるかという問題です。
最初に言及することは、サーバー クラスターが MongoDB でどのように構築されているかについてさらに調査を行うことです。レプリカ ( http://docs.mongodb.org/manual/replication/ ) とシャード ( http:/ /docs.mongodb.org/manual/sharding/ ) 2 つ以上のサーバーが必要になります。
これに関する私の個人的な意見が本当に必要な場合は、大規模なインスタンスなどのリソースの重いサーバーを使用しないことを選択し、はるかに多数の小規模なサーバーを使用することにしました. それらはより安価であり、長期的には実際に管理が容易であることが証明されています.
ここで、データベースがこれをどのように処理できるかについて話します。シャーディングとレプリカ セットを導入しました。これら 2 つの部分は、データベースをクラスターに適切にスケーリングし、データの一貫性と可用性を維持するために非常に重要ですが、これは 1 つの部分にすぎません。また、適切なワーキング セット、適切なインデックス、および適切なスキーマも必要です (英語の間違いではなく、多くの権利があります - 意図的なものです)。
これには2つのコレクションがあります。コレクションuser
とtweet
、おそらく_id
ユーザーuser_id
とtweet
. これらをシャード キーにするだけでなく、tweet
コレクションを分割しuser_id
て、グローバルなスキャッター アンド ギャザー操作を行う代わりに、1 台のコンピューターにクエリを実行するだけで、複数のコンピューターにまたがるユーザーのツイートをすばやく範囲指定できるようにします。ただし、時間操作も行う必要がある場合があることを考えると (x と y の日付の間のツイートを取得する)、代わりに時間ベースのシャード インデックスを調べたいと思うかもしれません。これはテスト用です。
これで、ユース ケースの MongoDB の検討と調査を開始できるはずです。
それが役に立てば幸い、