Почему хранение данных дорожает: пять скрытых источников

Счёт растёт, хотя данные почти не прибавляются

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

Разберём, как искать такие расходы в S3-подобном хранилище и PostgreSQL 16. Тарифы облаков и условия хранения меняются, поэтому ниже — не сравнение цен, а карта того, что проверять в счёте и метриках.

За что на самом деле выставляют счёт

У хранения нет единой универсальной единицы стоимости. В зависимости от облака и тарифа отдельно учитывают занятый объём, операции, чтение данных, сетевую передачу, репликацию и резервирование. Даже внутри одного сервиса цена может зависеть от класса хранения или региона. Поэтому сравнивать только цену за гигабайт недостаточно.

Для начала разделите расходы на три группы: объём, движение данных и избыточность. Затем сопоставьте их с тем, что бизнес действительно использует: активными файлами, нужными сроками хранения и допустимым временем восстановления.

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

Пять мест, где незаметно растут расходы

1. Версии объектов и незавершённые загрузки

Включённое версионирование помогает восстановить перезаписанный или удалённый файл, но удаление текущей версии не всегда удаляет предыдущие. Они продолжают занимать место. Отдельно проверьте незавершённые multipart-загрузки: пока их части не удалены, они могут оставаться в хранилище и учитываться в объёме. Ищите метрики по версиям, незавершённым загрузкам и фактически занятому объёму, а не только количество видимых файлов.

2. Запросы и чтение из архивных классов

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

3. Сеть, репликация и копии в других регионах

Копирование между регионами, выгрузка к клиентам и передача данных между облачными сервисами могут оплачиваться отдельно от хранения. Рост трафика нередко скрывается за внешне стабильным объёмом бакета. Разложите передачу по направлениям: между регионами, в интернет, между сервисами. Проверьте, не читают ли один и тот же набор данных несколько приложений и не отправляются ли большие файлы туда, где достаточно метаданных.

4. Индексы и разрастание таблиц в PostgreSQL

В PostgreSQL 16 размер базы — это не только объём строк. Индексы занимают место отдельно, а после массовых обновлений и удалений файлы таблиц могут не уменьшиться автоматически. Обычный VACUUM помогает повторно использовать освободившееся место внутри таблицы, но обычно не возвращает его операционной системе. Поэтому число строк может почти не измениться, а выделенный дисковый объём — оставаться высоким.

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

5. WAL, резервные копии и снимки

WAL — журнал предварительной записи: PostgreSQL фиксирует в нём изменения, чтобы восстановить базу после сбоя и поддерживать репликацию. Если архивирование или репликация отстают, журналы могут задерживаться и занимать дисковое место. Резервные копии и снимки добавляют ещё один слой хранения; их стоимость зависит от частоты создания, срока удержания и способа учёта изменённых блоков.

Проверьте не только размер активной базы, но и объём резервных копий, снимков и архивных WAL, а также срок их хранения. Политика удаления должна учитывать требования к восстановлению и хранению данных: удалять копии без проверки процедуры восстановления опаснее, чем переплачивать за них.

Как измерить утечку, а не гадать по счёту

Для поиска причины нужны данные минимум за несколько расчётных периодов. Сравнивайте расходы с объёмом полезных данных и активностью системы. Универсальные цифры «нормальной доли индексов» или «правильного срока хранения» здесь бесполезны: они зависят от нагрузки, облака и требований к восстановлению.

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

Термин: WAL (Write-Ahead Log) — журнал, куда PostgreSQL записывает изменения до того, как они окончательно попадут в файлы таблиц. Архив WAL может занимать отдельное место и нужен, в частности, для восстановления и репликации.

Где оптимизация может навредить

Перевод данных в архивный класс не поможет, если к ним часто обращаются. Сокращение срока хранения резервных копий уменьшит объём, но может лишить вас нужной точки восстановления. Удаление старых версий объектов необратимо убирает возможность отката к ним. А попытка «сжать» PostgreSQL может потребовать временного дополнительного диска или привести к заметной нагрузке.

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

Что делать дальше

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

Начните с самой большой статьи расходов, а не с самой простой настройки. Если основную сумму создаёт передача данных, чистка старых версий почти не повлияет на счёт. Если растёт объём резервных копий, оптимизация запросов тоже не решит проблему.