MongoDB BSONドキュメントのサイズ制限について

MongoDBから決定的なガイド：

4MBを超えるドキュメント（BSONに変換した場合）は、データベースに保存できません。これはやや恣意的な制限です（将来的には引き上げられる可能性があります）。これは主に、スキーマ設計の不良を防ぎ、一貫したパフォーマンスを確保するためです。

私はこの制限を理解していません。これは、たまたま4MBを超える大量のコメントを含むブログ投稿を含むドキュメントを単一のドキュメントとして保存できないことを意味しますか？

また、ネストされたドキュメントもカウントされますか？

値の変更を監査するドキュメントが必要な場合はどうすればよいですか。（最終的には4MBの制限を超えて大きくなる可能性があります。）

誰かがこれを正しく説明してくれることを願っています。

MongoDB（私が学んでいる最初のnosqlデータベース）について読み始めたところです。

ありがとうございました。

最初に、これは実際には次のバージョン8MBまたは16MB... で上げられていますが、これを展望に入れて考えると、10genのEliot（MongoDBを開発した人）が最適です。

編集： サイズは正式に「引き上げ」られています16MB

したがって、ブログの例では、実際には4MBが大量です。たとえば、「War of the Worlds」の完全な非圧縮テキストは、わずか364k（html）です。http：//www.gutenberg.org/etext/36

あなたのブログの投稿がそのように多くのコメントで長くなるなら、私はそれを読むつもりはありません:)

トラックバックの場合、1MBを割り当てると、1万バイト以上（おそらく2万バイト近く）になる可能性があります。

本当に奇妙な状況を除いて、それは素晴らしい働きをします。例外的なケースやスパムの場合は、とにかく20MBのオブジェクトが必要だとは思いません。トラックバックを15k程度に制限することは、パフォーマンスに関係なく、大いに意味があると思います。それが起こるなら、少なくとも特別なケース。

-エリオット

私はあなたが限界に到達するためにかなり難しいと思うと思います...そして、時間が経つにつれて、アップグレードすると...あなたはますます心配する必要がなくなります。

制限の主なポイントは、サーバー上のすべてのRAMを使い果たしないようにすることです（MBクエリを実行するときにドキュメントのすべてのRAMをRAMにロードする必要があるため）。

したがって、制限は、一般的なシステムで通常使用可能なRAMの数％です...これは、年々成長し続けます。

MongoDBへのファイルの保存に関する注意

サイズが大きいドキュメント（またはファイル）を保存する必要16MBがある場合は、GridFS APIを使用して、データを自動的にセグメントに分割し、それらをストリームに戻します（これにより、サイズ制限/ RAMの問題を回避します）。

ファイルを単一のドキュメントに保存する代わりに、GridFSはファイルを複数の部分またはチャンクに分割し、各チャンクを個別のドキュメントとして保存します。

GridFSは2つのコレクションを使用してファイルを格納します。1つのコレクションはファイルチャンクを格納し、もう1つのコレクションはファイルメタデータを格納します。

この方法を使用すると、SQLデータベースと同じように、画像、ファイル、ビデオなどをデータベースに保存できます。これを使用して、数ギガバイトのビデオファイルを保存することもできます。

コミュニティの多くは、パフォーマンスに関する警告で制限なしを好みます。正当な理由がある議論については、このコメントを参照してください：https : //jira.mongodb.org/browse/SERVER-431? focusedCommentId=22283 & page=com.atlassian.jira.plugin 。 system.issuetabpanels：comment-tabpanel＃comment-22283

私の考えでは、リード開発者はこの問題について、初期の段階で重要な「機能」であると判断したため、頑固です。誰かがそれを疑問視したことで彼らの気持ちが傷ついたので、彼らはすぐにそれを変えるつもりはありません。個性と政治がオープンソースコミュニティの製品を損なうもう1つの例ですが、これは実際に問題となる問題ではありません。

Googleからここに誘導された人のために、ここに説明の回答を投稿します。

ドキュメントサイズには、サブドキュメント、ネストされたオブジェクトなど、ドキュメント内のすべてが含まれます。

だからのドキュメント：

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

最大サイズは16メガです。

Sbudocumentとネストされたオブジェクトはすべて、ドキュメントのサイズにカウントされます。

ドキュメント自体に保存されている大きなファイルを含まないという制限の問題はまだ見ていません。大きなファイルを格納/取得するのに非常に効率的なさまざまなデータベースがすでに存在します。それらはオペレーティングシステムと呼ばれます。データベースは、オペレーティングシステムのレイヤーとして存在します。パフォーマンス上の理由でNoSQLソリューションを使用している場合、アプリケーションとデータの間にDBレイヤーを配置することによって、データへのアクセスに追加の処理オーバーヘッドを追加したいのはなぜですか？

JSONはテキスト形式です。したがって、JSONを介してデータにアクセスしている場合、uuencode、16進数、またはBase 64でエンコードする必要があるため、バイナリファイルがある場合は特にそうです。変換パスは次のようになります。

バイナリファイル<> JSON（エンコード）<> BSON（エンコード）

ドキュメント内のデータファイルへのパス（URL）を配置し、データ自体をバイナリで保持する方が効率的です。

本当に長さが不明なこれらのファイルをDBに保持したい場合は、これらのファイルをGridFSに配置し、大きなファイルにアクセスするときに同時実行性を停止するリスクを負わない方がよいでしょう。

BSONドキュメントの入れ子の深さ： MongoDBは、BSONドキュメントの入れ子レベルを100レベルまでサポートしていません。

もっと詳しくvist

おそらく、ブログの投稿->コメントの関係を非リレーショナルデータベースに保存することは、実際には最良の設計ではありません。

とにかく、ブログの投稿にはコメントを別のコレクションに保存する必要があります。

[編集]

詳細については、以下のコメントを参照してください。

https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1によると

ブログ投稿が16Mbのドキュメント制限を超える可能性がある場合は、コメントを別のコレクションに抽出し、コメントからブログ投稿を参照して、アプリケーションレベルの結合を行う必要があります。

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]