MongoDB Перетяжка Разъяснение

Question

Просматривая использования capped collections с MongoDB вопрос пришел в голову над следующим утверждением:.

«Вы можете обновить документы в коллекции после их вставки Тем не менее, эти обновления не может заставляют документы расти. Если операция обновления приводит к тому, что документ будет расти за их первоначальный размер, операция обновления завершится неудачно ».

Это само по себе звучит разумно, если не полностью объяснить причины. И это заставляет меня задуматься: «Если я не хочу, чтобы документ расти, но, возможно, добавьте дополнительную информацию (то есть: $ push к массиву), то что было бы неправильно с заполнением документа до моего ожидаемого размера».

Итак, моя посылка звучит разумно (для меня в любом случае), вплоть до чтения этого фрагмента с FAQ on padding.

Предупреждение Не вручную вставляйте документы в ограниченную коллекцию. Применение руководства отступы к документу в закрытой коллекции могут нарушить репликацию. Кроме того, заполнение не сохраняется, если вы повторно синхронизируете экземпляр MongoDB.

И снова это поднимает мой вопрос: «Почему это так?» Или конкретно:

1. Зачем заполнять документ в закрытой коллекции в этой «разрывающей репликации»?

2. Есть пропущенный раздел документации с указанием очевидных причин для этого? Или это просто «Темная магия» в закрытой коллекции внутренней работы на работе? (Возможно, связанная с частью «заполнение не сохранилась»)

3. Или это просто очень пессимистично, и на самом деле нет причин, по которым вы не могли бы проложить такой способ? (По крайней мере, в последних версиях).

Был бы рад, если бы кто-то мог пролить свет на то, почему эти утверждения верны.

P.S Хотя это не строго программирования я рассматривал ручную набивку технику быть методом программирования, и, следовательно, оставил вопрос здесь.

Answer 1

Зачем заполнять документ в закрытой коллекции в этой «разрывающей репликации»?

Я думаю, что документация может быть немного перестраховкой (см. DOCS-1528) здесь.MongoDB не имеет никакого способа узнать, является ли поле padding_foobar используются для «ручного заполнения» или содержит системную критическую информацию, так что техника обычно работает, НО

предостережения это: MongoDB начальной репликации будет всегда аккуратно упакуйте данные, поэтому, когда начальная репликация происходит после, вы изменили размер документа, позже вы не сможете расти документ снова.

Пример (Примечание: я буду использовать только размер контента здесь, что это не правильно, так как имена полей, идентификаторы типа, терминаторы и длины строк также занимают место, но это только усиливает аргумент):

// 1. insert w/ 20 bytes of 'content' 
insert({"name" : "john", "pad" : "0000000000000000"}); 

// 2. now we're performing an update, removing 16 bytes of padding, adding 
// 3 bytes so we now have 7 bytes of 'content' 
update({"name" : "john"}, {$unset: {"pad": 1}, $set: {"foo" : "bar"}}); 

// 3. at this point, we can easily grow the document again, as long as it doesn't 
// grow past its original size of 20 bytes of content 
update({"name" : "john"}, {$set: {"foo" : "barfoobar"}}); 

Теперь, когда начальная репликация произошла после шага 2), документ реплицируется без поля заполнения, так что на реплике всего 7 байтов «размер содержимого». В этом случае операция в , шаг 3) завершится ошибкой, потому что она расширяет документ за «исходный размер» реплики документа, который не соответствует оригинальному размеру документа мастера.

Другими словами, техника прекрасна тогда и только тогда, когда ваши обновления строго сохраняют или уменьшают размер объекта. Можете ли вы убедиться, что в вашей логике приложения или нет (например, потому что есть только одно обновление для такого документа, когда-либо), вы можете только ответить.