1

これは私の最後の質問に関連しています。

ユーザーごとに大量のデータを保存しているアプリがあります。データの性質上、以前はユーザーごとに新しいデータベースを作成することにしました。これには大きなノーが必要だったでしょう。データベースの数 (おそらく数百万) -- 誰かがコメントで指摘したように、これは設計が間違っていることを示しています。

そこでデザインを変更し、現在は各ユーザーのすべての情報を 1 つのコレクションに格納することを考えています。これは、1 つのコレクションが 1 人のユーザーに正確にマップされることを意味します。データベースごとに 12,000 のコレクションを使用できるため、DB ごとに 12,000 人のユーザーを格納できます (この制限は増やすことができます)。

しかし、今私の質問は - ノーに制限はありますか? コレクションが保持できるドキュメントの数。ユーザーごとにデータを保存する必要があるため、膨大な数 (極端な場合は数千万) のデータが必要になると予想されます。ドキュメントごとのドキュメントの。それはMongoDBと設計上は問題ありませんか?

編集

答えてくれてありがとう。コレクションごとに多数のドキュメントを使用しても問題ないと思います。

このアプリは、専門の在庫管理システムです。各ユーザーには大きな番号があります。それらに関連する小さな情報の断片。各情報にはカテゴリがあり、そのカテゴリの下に関連するものがあります。さらに、2 つのコレクションが互いのデータを参照する必要はありません。したがって、複数のコレクションにアクセスするインデックスは必要ありません。

4

2 に答える 2

2

持つことができるコレクション/インデックスの数を調整するには（〜24kが制限です-デフォルトで_idインデックスがあるため、〜12kがコレクションに対して言われていますが、コレクションにさらにインデックスがある場合は、名前空間も使用します)、mongod を起動するときに --nssize オプションを使用できます。

コレクションには数十億のドキュメントがある実装がたくさんあります（そして、数兆のドキュメントがあると確信しています）ので、「数千万」は問題ないはずです。返されるカウントなど、64 ビットの制約がある数値がいくつかあるため、2^64 のドキュメントにヒットすると、いくつかの問題が見つかる可能性があります。

どのような種類のクエリと更新の負荷を調べますか?

于 2012-04-18T05:56:57.607 に答える
1

あなたのデザインはまだあまり意味がありません。各ユーザーを個別のコレクションに保存するのはなぜですか?

データにはどのようなインデックスがありますか? すべてのユーザーに共通するコンテンツを持つフィールドでインデックスを作成している場合、1 つのインデックスを持つ 1 つのコレクションを持つことで、合計インデックス サイズを大幅に節約できます。

多くの場合、パフォーマンスに関しては、データベースの合計サイズではなく、インデックス サイズが制限要因になります。

ユーザーごとにこれほど多くのドキュメントがあるのはなぜですか? それらはどのくらいの大きさですか？

Craigslist は 20 億以上のドキュメントを MongoDB に配置しているため、それをサポートするハードウェアがあり、インデックスが非効率的でなければ問題にはなりません。

ここにスキーマをもっと投稿すると、おそらくより良いアドバイスが得られるでしょう。

于 2012-04-18T05:56:46.570 に答える