web-dev-qa-db-ja.com

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

MongoDB The Definitive Guideから：

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

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

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

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

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

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

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

mongodbbson
136
saint

最初に、これは実際に次のバージョンで8MBまたは16MBに上げられます...しかし、これを遠近法に入れたいと思います。

EDIT：サイズは 公式に '_raised' to 16MB

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

あなたのブログ投稿がそんなに多くのコメントでそれほど長い場合、私はそれを読むつもりはありません:)

トラックバックの場合、1MBをトラック専用にすると、簡単に10k以上（おそらく20k近く）になります

本当に奇妙な状況を除いて、それはうまく機能します。例外的なケースやスパムの場合、とにかく20MBのオブジェクトが必要になるとは思いません。パフォーマンスに関係なく、トラックバックの上限を15k程度に制限することは理にかなっていると思います。または、少なくとも特別なケースが発生した場合。

-エリオット

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

制限の主なポイントは、サーバー上のすべてのRAMを使い果たさないようにすることです（すべてのMBsをクエリすると、RAMにドキュメントが挿入されます。）

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

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

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

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

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

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

117
Justin Jenkins

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

私の考えでは、リード開発者はこの問題について頑固です。なぜなら、彼らはそれが重要な「機能」であると早期に判断したからです。誰もが質問したことで感情が傷つくため、すぐに変更することはありません。人格と政治がオープンソースコミュニティの製品を損なう別の例ですが、これは実際に重大な問題ではありません。

31
marr75

ここで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メガバイトです。

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

25
Sammaye

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

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

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

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

DBに未知の長さのこれらのファイルを本当に保持したい場合は、おそらくこれらをGridFSに配置し、大きなファイルにアクセスしたときに同時実行性を損なう危険を冒さない方がよいでしょう。

4
Chris Golledge

BSONドキュメントのネストの深さ：MongoDBは、BSONドキュメントのネストを100レベル以下サポートします。

詳細情報ビスト

4
user2903536

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

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

[編集]

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

2
Mchl

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

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

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

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