私の mongoDB コレクション内のすべてのドキュメントには、整数の配列があります。各整数に 32 ビットを超える必要はなく、整数配列の長さは各ドキュメントで同じになります。
私のアプリケーションのクライアントは、配列内の個々のフィールドを頻繁に更新します。
256 個の整数の配列を持つ 5000 から 10000 のドキュメントがある場合、mongo db はスペースを浪費しますか?配列の内容を整数以外のデータ型に変更したり、配列の長さを変更したりするために準備する必要があるからです。
mongoDB の設計により、従来のリレーショナル データベースと比較して、配列内の個々の整数の更新が非常に非効率になりますか?
ここで説明する更新配列構文を使用していると仮定します: http://docs.mongodb.org/manual/applications/update/#update-arrays
配列の内容を非整数データ型に変更したり、配列の長さを変更したりする準備が必要なため、mongo db はスペースを浪費しますか?
いいえ、スペースを無駄にしません。データ型を変更したり、配列の長さを変更したりする機能の観点からこれを考えるのではなく、ドキュメントが大きくなる傾向があるかどうかを適応的に学習するMongoDB のパディング ファクターに集中します。ドキュメント サイズは非常に似ているため、パディング ファクターは 1 に近づく傾向があります (つまり、ドキュメント サイズに追加のパディングはほとんど追加されません)。
mongoDB の設計により、従来のリレーショナル データベースと比較して、配列内の個々の整数の更新が非常に非効率になりますか?
埋め込み配列には正確に対応するリレーショナルがないため、比較は明確ではありません。リレーショナルに相当するものはJOIN. JOINこの場合、 aには独自のコストがあるため、MongoDB の方が高速になると思います。
補足として、MongoDB が処理できるデータ量を考えると、5,000 から 10,000 のドキュメントはごくわずかです。更新時にインデックス付き基準 (_id など) を指定している限り、ここで心配するスペースやパフォーマンスの考慮事項はありません。ただし、ドキュメントは小さくないため、検索クエリでドキュメント全体を一度に読み込もうとすることに注意してください。特定のフィールドに対してのみ検索クエリを投影することをお勧めします。配列をクエリするときは、$sliceを検討することをお勧めします。