Блог

У меня есть разделенный и реплицированный MongoDB с десятками миллионов записей. Я знаю, что Mongo записывает данные с некоторым коэффициентом заполнения, чтобы обеспечить быстрое обновление, и я также знаю, что для репликации базы данных Mongo должен хранить журнал операций, который требует некоторого (на самом деле, большого) пространства. Даже с этими знаниями я понятия не имею, как оценить фактический размер, требуемый Mongo, учитывая размер типичной записи базы данных. К настоящему времени у меня есть дефицит с коэффициентом 2-3 между еженедельными ремонтами.

Итак, вопрос в следующем: как оценить общий размер хранилища, требуемый MongoDB, учитывая средний размер записи в байтах?

Короткий ответ таков: вы не можете, не основываясь исключительно на avg. размер документа (по крайней мере, не совсем точный).

Чтобы объяснить более подробно:

Необходимое пространство на диске зависит не просто от среднего размера документа. Также есть место, необходимое для любых создаваемых вами индексов. Тогда есть пространство, необходимое, если вы запускаете эти перемещения (несмотря на заполнение, это происходит) — это пространство помещается в список для повторного использования, но в зависимости от данных, которые вы впоследствии вставляете, повторно использовать это пространство может быть или не быть возможным.

Вы также можете добавить к тому факту, что предварительное выделение будет означать, что иногда несколько документов увеличивают использование вашего дискового пространства на ~ 2 ГБ по мере выделения нового файла данных. Конечно, при достаточном количестве данных это будет, по сути, ошибкой округления, но это стоит иметь в виду.

Единственный способ оценить соотношение этого типа данных к размеру, предполагая согласованный шаблон использования, — это изменить его с течением времени для вашего конкретного варианта использования и отследить использование дискового пространства в зависимости от вставленных данных (количество документов может быть больше объема данных в зависимости от изменчивости размера документа).

Аналогично, если вы отслеживаете частоту вставок, размер документа и пространство, полученное в результате повторной синхронизации / восстановления. К вашему сведению — вы можете повторно синхронизировать дополнительный сервер с нуля, чтобы получить «свежую» копию файлов данных, а не запускать восстановление, которое может быть менее разрушительным и занимать меньше места в зависимости от ваших настроек.