Write amplification: почему база записывает в разы больше, чем вы думаете

Прямой ответ

Write amplification (WA, усиление записи) — отношение объёма данных, фактически записанных на носитель, к объёму, который запросило приложение. Значение 5 означает, что на каждый гигабайт полезных данных устройство записало пять.

Коэффициент всегда больше единицы, потому что запись происходит блоками, а данные обновляются частями. Источники усиления складываются:

1. Уровень устройства (SSD). Память NAND организована в страницы (типично 4–16 КБ) и блоки (несколько МБ). Перезаписать можно только страницу, а стирать — только блок целиком. Изменение одной страницы в заполненном блоке требует переноса остальных страниц в новый блок, затем стирания старого. Это garbage collection, основной источник WA внутри накопителя.

2. Уровень файловой системы. Журналируемые файловые системы пишут метаданные и данные в журнал, а затем в основное расположение. Выравнивание раздела относительно границ блоков устройства тоже влияет: невыровненная запись затрагивает два блока вместо одного.

3. Уровень СУБД. В PostgreSQL обновление строки записывает новую версию строки, записи в затронутые индексы и записи в журнал предзаписи — см. WAL. Одно обновление одной колонки может дать несколько страниц записи.

4. Уровень структуры хранения. В LSM-tree компакция перезаписывает данные при переходе между уровнями: коэффициент равен сумме коэффициентов слияний. В B-tree split узла переписывает обе половины и родителя — см. B-tree.

Практическая оценка для типичного сценария «PostgreSQL на SSD»:

Ресурс накопителя задаётся параметром TBW (terabytes written) или DWPD (drive writes per day). Для потребительского SSD на 1 ТБ с TBW 600 ресурс при записи 100 ГБ в день составит примерно 16 лет, а при 1 ТБ в день — около полутора лет.

# сколько реально записано на устройство (Linux, атрибуты SMART NVMe)
sudo smartctl -a /dev/nvme0 | grep -Ei "data units written|percentage used|available spare"

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

1. Уменьшайте объём полезной записи. Самый эффективный приём. Батчинг транзакций, отказ от обновлений на каждый запрос, кэширование счётчиков, хранение телеметрии в отдельном хранилище — всё это снижает нагрузку сильнее, чем подбор железа.

2. Оставляйте запас места (over-provisioning). Garbage collection работает дешевле, когда на устройстве есть свободные блоки. Заполненный под завязку диск демонстрирует рост WA и падение скорости записи. Практический ориентир — держать 10–20 % раздела свободными.

3. Используйте TRIM. Команда сообщает устройству, какие блоки больше не заняты, и снижает работу сборщика мусора. В Linux это fstrim.timer или опция монтирования discard (последняя может добавлять задержки в момент удаления).

4. Выбирайте структуру хранения под нагрузку. Для потоковой записи больших объёмов LSM-подход даёт последовательную запись и меньшее усиление, чем дерево с обновлением на месте; подробности в статье про LSM-tree.

5. Следите за размером страницы. Запись мелких случайных фрагментов — наихудший сценарий. Увеличение объёма одной операции записи почти всегда снижает WA.

6. Мониторьте износ. Процент израсходованного ресурса и объём записанных данных — метрики, которые стоит собирать наравне с загрузкой CPU. Рост темпа записи виден по ним раньше, чем по деградации отклика.

Рекомендации:

1. Считайте бюджет записи до выбора накопителя. Оцените суточный объём полезной записи, умножьте на ожидаемое усиление и сравните с TBW. Для баз с интенсивной записью выбирают накопители корпоративного класса с высоким TBW.
2. Разделяйте журнал и данные. WAL пишет последовательно, страницы данных — случайно. Разные устройства позволяют каждому работать в своём оптимальном режиме.
3. Не измеряйте производительность на пустом диске. Поведение заполненного устройства заметно отличается; нагрузочное тестирование стоит проводить на предварительно заполненном томе.
4. Проверяйте влияние автовакуума. Массовая очистка создаёт всплески записи; для таблиц с частыми обновлениями агрессивные настройки увеличивают WA, но предотвращают разрастание — это осознанный компромисс.
5. Помните про сжатие. Некоторые устройства и файловые системы сжимают данные до записи, что снижает фактический объём. Эффект зависит от характера данных и его нужно измерять.

Практический сценарий: деградация записи через восемь месяцев эксплуатации

Контекст: сервер с PostgreSQL стал отвечать медленнее в пиковые часы. Изменений в приложении не было.

1. Диагностика. Задержка записи на устройство выросла с 0,3 мс до 4 мс в пике. По SMART: записано 210 ТБ при TBW 600, израсходованный ресурс около 35 %, но заполнение раздела — 96 %.
2. Причина 1. Раздел был заполнен почти полностью, поэтому сборщику мусора не хватало свободных блоков: WA вырос, запись стала дороже.
3. Причина 2. fstrim.timer был отключён после установки системы, и устройство не знало об освобождённых блоках.
4. Действия. (а) Архивные данные вынесли в объектное хранилище, заполнение раздела снизили до 74 %; (б) включили периодический fstrim; (в) перевели запись событий на батчи, что снизило полезный объём записи примерно на 40 %; (г) добавили метрики: темп записи в ГБ/сутки, заполнение раздела, израсходованный ресурс.
5. Результат. Задержка записи вернулась к 0,4 мс, темп записи снизился с 320 до 180 ГБ в сутки, прогноз по TBW вырос с двух до пяти лет.

Вывод: усиление записи — не абстракция, а конкретный расход ресурса, который зависит от заполнения диска, работы сборщика мусора и шаблона записи приложения. Все три фактора управляемы.

FAQ

Можно ли измерить усиление записи точно? Только частично. Сравнение объёма, записанного устройством по SMART, с объёмом, отправленным операционной системой, даёт представление о вкладе устройства. Вклад СУБД оценивают по статистике записанных страниц и объёму журнала.

Правда ли, что SSD «боятся» записи? Современные накопители рассчитаны на сотни терабайт записи. Реальный риск возникает при нагрузках баз данных, где суточный объём измеряется сотнями гигабайт, и при отсутствии запаса свободного места.

Что хуже: много мелких записей или одна большая того же объёма? Множество мелких случайных записей. Они затрагивают больше страниц и блоков, увеличивают работу сборщика мусора и хуже используют последовательный ввод.

Влияет ли шифрование на усиление записи? Само по себе — незначительно: объём данных не меняется. Но шифрование исключает дедупликацию и сжатие на уровне устройства, поэтому в системах, где они работали, фактический объём записи может вырасти.

Источники: PostgreSQL docs (WAL), RocksDB docs, Wikipedia (write amplification) — ссылки в шапке.