大量のユーザー (約 100,000) を処理するために MongoDb (64 ビット バージョン) を使用してシステムを設計しており、各ユーザーには大量のデータ (約 100 万レコード) が含まれます。
最適な設計戦略とは?
単一コレクション内のすべてのレコードをダンプする
ユーザーごとにコレクションを用意する
ユーザーごとにデータベースを用意します。
どうもありがとう、
14882 次
3 に答える
19
つまり、1,000 億レコード (100 万レコード * 100,000 ユーザー) の領域のどこかを見ています。
大量のデータを処理するための推奨される方法は、mongo クライアントを介して単一の論理ユニットとして提示される複数のサーバーにデータを分割するシャード クラスターを作成することです。
したがって、あなたの質問に対する答えは、すべてのレコードを単一のシャード コレクションに入れることです。
必要なシャードの数とクラスターの構成は、データのサイズと、読み取りと書き込みの量と分散などのその他の要因に関連しています。これらの質問に対する答えは、おそらくあなたの固有の状況に非常に固有のものであるため、私はそれらを推測しようとはしません.
私ならまず、その数のマシンのクラスターでシステムをセットアップしてテストするために、時間とマシンを利用できるシャードの数を決定することから始めます。そのパフォーマンスに基づいて、クラスター内のシャードを増やすか減らすかを決定できます
于 2012-12-18T17:11:35.003 に答える
8
では、10 万人のユーザーに対して全体で 1 億件の詳細レコードを探していますか?
多くの人が理解していないように見えるのは、MongoDB が水平スケーリングに優れているということです。水平方向のスケーリングは、通常、巨大なクラスター内の多くの (多数の) サーバーにわたって巨大な単一のデータ コレクションをスケーリングすることとして分類されます。
したがって、共通データに単一のコレクションを使用する場合 (つまり、1 つのコレクションが呼び出されuser、もう 1 つが呼び出されるdetail)、MongoDB のコアの目的とビルドに適しています。
他の人が述べたように、MongoDB は多くのコレクションにまたがる垂直方向のスケーリングがあまり得意ではありません。そもそも nssize の制限があり、実際には 12K の初期コレクションが推定されますが、インデックス サイズのために、データベース内に 5K のコレクションしか持つことができません。
したがって、ユーザーごとのコレクションはまったく実現不可能です。そのコア原則に反して MongoDB を使用することになります。
ユーザーごとにデータベースを持つことは、ユーザーごとに単一のコレクションを持つことと同じか、それ以上の問題を伴います。
最適化されたセットアップで、MongoDB を数十億または数千億近く (またはそれ以上) にスケーリングできない人に遭遇したことはありませんが、なぜそれができないのかわかりません。結局、Facebook は MySQL を 1 ユーザーあたり数億 (32,000 以上のシャード) にスケールすることができ、シャーディングの概念は 2 つのデータベース間で類似しています。
したがって、これを行う理論と可能性はそこにあります。適切なスキーマとシャードの概念とキー (およびサーバーとネットワークなど) を選択することがすべてです。
問題が発生した場合は、アーカイブ コレクションを分割したり、アイテムをメイン コレクションから削除したりすることができますが、それはやり過ぎだと思います。代わりに、巨大なデータセットの各セグメントが特定の時点でどこにあるかを MongoDB が認識できるようにする必要があります。マスターで時間内にこのデータが常にホットであることを確認してください。そうすれば、グローバルでスキャッターOPを実行しないクエリは非常に高速になるはずです。
于 2012-12-18T20:45:22.960 に答える
4
各ユーザーのコレクションについて:
デフォルトの構成では、MongoDB は 12k コレクションに制限されています。--nssizeでこのサイズを増やすことができますが、無制限ではありません。そして、この 12k にインデックスをカウントする必要があります。（mongoのドキュメントで「名前空間」の概念を確認してください）。
各ユーザーのデータベースについて:
モデルの観点からすると、それは非常に興味深いことです。技術的には、mongo に制限はありませんが、おそらくファイル記述子に制限があります (OS/設定からの制限)。
@Rohitが言うように、最後の2つは良くありません。たぶん、あなたのケースについてもっと説明する必要があります。おそらく、ユーザーをさまざまなコレクションに分割できます (例: 名前の最初の文字ごとに 1 つ、または会社のサービスごとに 1 つ...)。そして、もちろんshardingを使用します。
編集: MongoDb はユースケースに最適なデータベースではない可能性があります。
于 2012-12-18T17:10:15.517 に答える