Лучшие практики по управлению и сокращению использования дискового пространства MongoDB

MongoDB, популярная база данных документов NoSQL, известна своей гибкостью и масштабируемостью. Однако без проактивного управления использование дискового пространства может быстро расти, что приводит к снижению производительности, системным сбоям и увеличению затрат на инфраструктуру. Понимание того, как MongoDB использует дисковое пространство, и внедрение эффективных стратегий управления имеют решающее значение для поддержания здоровой и эффективной среды базы данных.

В этой статье рассматриваются комплексные стратегии управления и сокращения дискового пространства MongoDB. Мы изучим практические методы, такие как компактификация коллекций, оптимизация и обработка больших индексов, настройка параметров движка хранения для повышения эффективности и внедрение политик жизненного цикла данных. Следуя этим лучшим практикам, вы можете предотвратить ненужный рост диска, обеспечить стабильную работу и продлить срок службы ваших развертываний MongoDB.

Понимание потребления дискового пространства MongoDB

MongoDB использует дисковое пространство для нескольких компонентов:

Файлы данных: Хранят фактические документы BSON в коллекциях.
Файлы индексов: Хранят B-деревья индексов, созданные для поддержки эффективного выполнения запросов.
Файлы журнала (WiredTiger): Записывают операции записи до того, как они будут применены к файлам данных, обеспечивая сохранность данных. Они предварительно выделяются.
Oplog (Операционный журнал): Специальная ограниченная коллекция в репликационых наборах, которая записывает все операции записи. Важно для репликации.
Диагностические данные: Журналы, файлы процессов mongod и другая системная информация.

Со временем, из-за обновлений, удалений и роста документов (заполнения), коллекции и индексы могут стать фрагментированными или содержать неиспользуемое выделенное пространство, что приводит к неэффективному использованию диска. Это "белое пространство" не освобождается операционной системой немедленно, даже если база данных больше не нуждается в нем для активных данных.

Стратегии сокращения дискового пространства MongoDB

1. Компактификация коллекций и индексов

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

Компактификация коллекций

С движком хранения WiredTiger (по умолчанию с MongoDB 3.2) compact в основном освобождает свободное пространство от удаленных документов и дефрагментирует коллекции. Он не перестраивает файл данных коллекции с нуля, как это делала операция compact в MMAPv1.

db.runCommand({ compact: "myCollection" })

Соображения по поводу compact:

Операции compact могут быть ресурсоемкими (ЦПУ, ввод-вывод) и занимать значительное время, особенно для больших коллекций. Часто лучше всего выполнять их во время окон обслуживания или на вторичных членах репликационного набора.
Требуется свободное дисковое пространство, равное размеру компактифицируемой коллекции, так как данные перестраиваются в новом месте перед обменом.
Для шардированных кластеров выполняйте compact на каждом шарде независимо.

Перестроение индексов

Индексы также могут стать фрагментированными. Перестроение индекса может освободить пространство и потенциально улучшить производительность запросов.

db.myCollection.reIndex()

Соображения по поводу reIndex():

reIndex() является операцией, выполняемой онлайн, начиная с MongoDB 4.2 (требуется достаточное дисковое пространство для нового индекса). Для версий до 4.2 он блокирует запись в базу данных (не только в коллекцию), препятствуя всем другим операциям. Рекомендуется сначала выполнить reIndex() на вторичных членах, а затем понизить главный узел, чтобы выполнить его на новом главном.
Подобно compact, reIndex() требует дополнительного дискового пространства во время операции.

`repairDatabase` (Автономная операция)

При серьезной фрагментации или повреждении данных repairDatabase может перестроить все файлы данных. Это автономная операция, требующая остановки экземпляра mongod.

mongod --repair

Предупреждение: repairDatabase следует использовать в крайнем случае для освобождения пространства, поскольку это деструктивная операция, если не обращаться с ней осторожно, и она может занять очень много времени. Всегда имейте резервную копию.

2. Оптимизация индексов

Индексы имеют решающее значение для производительности, но могут потреблять значительное дисковое пространство. Неиспользуемые или избыточные индексы — это чистый накладной расход.

Определение и удаление ненужных индексов

Регулярно проверяйте свои индексы, чтобы убедиться, что они все еще нужны.

Перечислить все индексы для коллекции:
javascript db.myCollection.getIndexes()
Мониторинг использования индексов: Включите профилирование базы данных (db.setProfilingLevel(1)) или используйте db.collection.stats() для просмотра использования индексов. Инструменты облачного мониторинга часто предоставляют информацию об использовании индексов.
Определение дублирующихся или избыточных индексов: Например, индекс по { a: 1, b: 1 } делает индекс по { a: 1 } избыточным для запросов, которые могут использовать составной индекс. Индекс { a: 1, b: 1 } также покрывается индексом { a: 1, b: 1, c: 1 } для запросов, которые включают только a и b.

После определения удалите неиспользуемый индекс:

db.myCollection.dropIndex("indexName")

Совет: Всегда тестируйте влияние удаления индекса в тестовой среде перед применением к производственной.

Использование частичных индексов

Частичные индексы индексируют только документы в коллекции, которые соответствуют указанному выражению фильтра. Это уменьшает количество индексируемых документов, экономя дисковое пространство и улучшая производительность записи.

db.orders.createIndex(
   { customerId: 1, orderDate: -1 },
   { partialFilterExpression: { status: "active" } }
)

Этот индекс будет включать только документы, где status равен "active", значительно уменьшая его размер, если большинство заказов имеют "active"