Розуміння обмеження розміру документа MongoDB BSON

Від MongoDB Остаточний посібник:

Документи розміром більше 4 Мб (при перетворенні в BSON) не можуть бути збережені в базі даних. Це дещо довільна межа (і може бути підвищена в майбутньому); здебільшого це запобігає поганому проектуванню схеми та забезпечить послідовну продуктивність.

Я не розумію цього обмеження, чи означає це, що Документ, що містить допис у блозі з безліччю коментарів, який просто більший за 4 Мб, не може зберігатися як один документ?

Чи враховує це також вкладені документи?

Що робити, якщо я хотів документ, який перевіряє зміни у значенні. (Врешті-решт це може зрости, перевищивши ліміт 4 Мб.)

Сподіваюся, хтось це правильно пояснить.

Я щойно почав читати про MongoDB (перша база даних nosql, про яку я дізнаюся).

Дякую.

По-перше, це насправді піднімається в наступній версії до 8MBабо 16MB... але я думаю, щоб поставити це на перспективу, Еліот з 10gen (який розробив MongoDB) вважає це найкращим:

EDIT: Розмір офіційно "підвищений" до16MB

Отже, на прикладі вашого блогу, 4 Мб - це фактично багато. Наприклад, повний розтиснутий текст "Війни світів" становить лише 364 к (html): http://www.gutenberg.org/etext/36

Якщо ваша публікація в блозі така довга з такими багатьма коментарями, я, наприклад, не збираюся її читати :)

Для зворотних треків, якщо ви виділили їм 1 Мб, ви могли легко отримати більше 10 Кб (можливо, ближче до 20 Кб)

Тож крім справді химерних ситуацій, це буде чудово. І у випадку винятку чи спаму, я дійсно не думаю, що ви хочете, щоб ви хотіли об'єкт 20 Мб. Я думаю, що обмеження трекбеків становить 15 кб або більше має багато сенсу незалежно від продуктивності. Або принаймні спеціальний кожух, якщо він коли-небудь трапиться.

-Еліот

Я думаю, що вам буде досить важко натиснути, щоб досягти межі ... і з часом, якщо ви будете модернізувати ... вам доведеться турбуватися все менше і менше.

Основний пункт обмеження полягає в тому, щоб ви не використовували всю оперативну пам’ять на своєму сервері (так як вам потрібно завантажити всі MBдокументи документа в оперативну пам’ять при запиті.)

Таким чином, обмеження становить деякий% від звичайної корисної оперативної пам’яті в загальній системі… яка буде постійно зростати з року в рік.

Примітка щодо зберігання файлів у MongoDB

Якщо вам потрібно зберігати документи (або файли) більше, ніж 16MBви можете використовувати API GridFS, який автоматично розбиває дані на сегменти та передаватиме вам назад (таким чином, уникаючи проблеми з обмеженням розміру / ОЗУ.)

Замість того, щоб зберігати файл в одному документі, GridFS розділяє файл на частини або фрагменти і зберігає кожен фрагмент як окремий документ.

GridFS використовує дві колекції для зберігання файлів. Один збірник зберігає фрагменти файлів, а інший зберігає метадані файлу.

Ви можете використовувати цей метод для зберігання зображень, файлів, відео тощо в базі даних, наскільки це можливо в базі даних SQL. Я використовував це для навіть збереження мультигабайтних відеофайлів.

Багато хто в громаді вважають за краще не обмежуватись попередженнями про ефективність, дивіться цей коментар для обґрунтованого аргументу: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: коментар-вкладка # 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, hexadecimal або Base 64. Шлях конверсії може виглядати як

двійковий файл <> JSON (закодований) <> BSON (закодований)

Було б більш ефективно поставити шлях (URL) до файлу даних у вашому документі та зберегти самі дані у двійковій формі.

Якщо ви дійсно хочете зберегти ці файли невідомої довжини у вашій БД, вам, ймовірно, буде краще розмістити їх у GridFS і не ризикувати вбивати ваші сукупності, коли доступ до великих файлів.

Вкладена глибина для документів BSON: MongoDB підтримує не більше 100 рівнів вкладеності для документів BSON.

Більше інформації vist

Можливо зберігання в блозі -> коментарі відносини в НЕ реляційну базу даних насправді не найкращий дизайн.

Ви, ймовірно, повинні зберігати коментарі в окремій колекції до публікацій блогу.

[редагувати]

Дивіться коментарі нижче для подальшого обговорення.

Відповідно до https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Якщо ви очікуєте, що публікація в блозі може перевищити ліміт документа на 16 Мбіт, слід витягнути коментарі до окремої колекції та віднести посилання на коментар до коментаря та зробити приєднання на рівні програми.

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

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