164

MongoDBから決定的なガイド：

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

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

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

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

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

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

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

4

7 に答える 7

134

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

編集： サイズは公式に「引き上げられた」16MB

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

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

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

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

-エリオット

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

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

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

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

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

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

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

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

于 2011-01-12T10:31:37.063 に答える
37

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

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

于 2012-07-10T19:47:35.683 に答える
36

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

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

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

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

最大サイズは16MBです。

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

于 2013-10-16T11:08:25.613 に答える
6

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

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

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

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

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

于 2013-06-20T21:07:41.777 に答える
6

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

詳細情報ビスト

于 2016-04-17T05:14:44.927 に答える
1

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

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

[編集]

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

于 2011-01-12T10:25:08.157 に答える
1

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')
  }
]
于 2019-04-24T03:10:43.187 に答える