MongoDB BSONドキュメントサイズの制限の理解

StackOverflow https://stackoverflow.com/questions/4667597

  •  10-10-2019
  •  | 
  •  

質問

Mongodbから決定的なガイド：

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

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

また、これはネストされた文書もカウントしますか？

変更を値に監査するドキュメントが必要な場合はどうなりますか。 （最終的には成長し、4MBの制限を超えます。）

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

MongoDB（最初のNOSQLデータベースを学んでいる）について読み始めました。

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

役に立ちましたか？

解決

まず、これは実際に次のバージョンで提起されています 8MB また 16MB ...しかし、私はこれを視野に入れると思います、10gen（Mongodbを開発した）のEliotはそれを最高に置いています：

編集： サイズはあります 公式に 「育てられた」 16MB

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

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

トラックバックの場合、1MBを専用している場合、10k以上（おそらく20kに近い）を簡単に入れることができます。

ですから、本当に奇妙な状況を除いて、それはうまく機能します。そして、例外の場合やスパムでは、とにかく20MBのオブジェクトが必要だとは思いません。パフォーマンスのために何があっても、15k程度のキャッピングトラックバックは非常に理にかなっていると思います。または、少なくとも特別なケーシングが発生した場合。

- エリオット

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

制限の主なポイントは、サーバー上のすべてのRAMを使用しないようにすることです（すべてをロードする必要があるため MBあなたがそれを照会するとき、ドキュメントのs。）

したがって、制限は、一般的なシステム上の通常の使用可能な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

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

Googleがここに監督する人のために、ここに明確な回答を投稿するため。

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

したがって、ドキュメント：

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

最大サイズは16megです。

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

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

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

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

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

これらのファイルをDBに本当に保持したい場合は、おそらくこれらをGridfに入れて、大きなファイルにアクセスしたときに同時性を殺す危険を冒してはいけません。

BSON文書のネストされた深さ：MongoDBは、BSONドキュメントのネスティング100レベル以下をサポートしています。

詳細情報眺め

おそらくブログ投稿を保存する - >コメント 関係 非関係データベースでは、実際には最高のデザインではありません。

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

編集

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

によると 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')
  }
]
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top