Хранение данных под нагрузкой: где растёт счёт и что ломается

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

За что вы платите помимо размера таблиц

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

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

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

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

Что ломается первым под нагрузкой

Универсального порядка нет: он зависит от типа диска, настроек сервиса и профиля запросов. Но один сценарий встречается часто: при росте параллельных операций диск достигает лимита IOPS или пропускной способности. Запросы дольше ждут чтения и записи, растут задержки, очередь, а затем начинают срываться тайм-ауты приложения. При этом свободное место ещё может быть.

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

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

Наконец, рост базы может быть следствием накопления старых версий строк. Обычный VACUUM подготавливает место к повторному использованию, но не является командой «сжать файл». Попытка срочно вернуть место на диск без оценки блокировок, дополнительного пространства и нагрузки способна создать новый инцидент. Инвалидация кэша и настройка жизненного цикла резервных копий — отдельные темы; здесь важно включить их стоимость в картину целиком.

Как измерить расходы, а не гадать по графику

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

-- Крупнейшие таблицы вместе с индексами и TOAST-данными
SELECT
    schemaname,
    relname,
    pg_total_relation_size(relid) AS total_bytes,
    pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

-- Временные файлы по базам данных
SELECT
    datname,
    temp_files,
    temp_bytes
FROM pg_stat_database
ORDER BY temp_bytes DESC;

-- Счётчики операций ввода-вывода по типам процессов и контекстам
SELECT
    backend_type,
    object,
    context,
    reads,
    writes,
    extends,
    hits,
    evictions,
    op_bytes
FROM pg_stat_io
ORDER BY reads DESC;

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

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

Где диагностика даёт сбой

• Смотрят только на размер базы. Он не показывает, сколько места занимает WAL, временные файлы и внешние копии, и не раскрывает упор в производительность диска.
• Сравнивают абсолютные счётчики. Счётчик чтений без длительности наблюдения, сброса статистики и уровня параллельности мало что говорит. Сравнивайте прирост на одинаковых интервалах и при сопоставимой нагрузке.
• Списывают любую задержку на диск. Высокая задержка запросов может быть связана с планом выполнения, блокировками или нехваткой CPU. Проверьте совпадение по времени с метриками хранилища.
• Пытаются немедленно уменьшить файлы. В PostgreSQL освобождённое место часто остаётся доступным для повторного использования внутри таблицы. Операции физического сжатия требуют отдельной оценки блокировок и свободного пространства.
• Не считают копии. Реплика, архив WAL и резервная копия — разные механизмы с разными сроками хранения и правилами тарификации. Сверьте настройки каждого.

Что проверить после диагностики

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

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

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