Выбираем конфигурацию для нового кластера PostgreSQL

Кажется, выбрать конфигурацию (или, по-другому, флейвор) для нового кластера PostgreSQL — простая задача, пока не столкнёшься с десятками вариантов виртуальных машин и типов дисков. Неподходящее решение может стоить проекту нескольких дней простоя или месяцев борьбы с базой данных, которая тормозит под нагрузкой.

Этот гайд поможет осознанно подойти к выбору флейвора для PostgreSQL начального уровня. Мы разберём, как каждый компонент — тип диска, объём оперативной памяти и количество ядер — влияет на реальную производительность СУБД. А ещё дадим рекомендации для разных сценариев нагрузки.

Зачем вообще нужен флейвор для кластера PostgreSQL

Флейвор для кластера PostgreSQL — это комбинация вычислительных ресурсов (CPU, RAM) и дисковой подсистемы. Правильный выбор флейвора напрямую влияет на работу базы данных.

Например, если объёма RAM будет недостаточно, PostgreSQL будет чаще читать с диска — и запросы станут медленными. А если не будет хватать ресурса vCPU, то при всплеске нагрузки запросы начнут копиться в очереди.

Важный показатель флейвора PostgreSQL — TPS, Transactions Per Second, количество транзакций в секунду. Это критерий производительности базы данных на конкретном типе нагрузки. Такие метрики обычно измеряют с помощью нагрузочных тестов, например pgbench. По величине TPS можно судить, справится ли база данных с реальной нагрузкой от приложения.

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

Мы провели исследование по перфомансу на дефолтных настройках pgbench и на стандартном профиле. Измеряли величину TPS для разных флейворов и дисков — всего получилось 28 конфигураций. Мы хотели измерить производительность набора флейворов и дисков относительно друг друга, поэтому все измерения выполняли на одинаковом объёме данных и с одинаковой нагрузкой.

Вот как это выглядело пошагово.

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

2. Для каждой конфигурации создали новый чистый кластер.

3. Для всех конфигураций кластеров устанавливали одинаковые параметры (кроме флейвора и диска), в том числе версию PostgreSQL 18, а также зоны доступности хостов (в случае с тремя хостами — a, b и d; с двумя — b и d).

4. Для тестирования конфигураций с local-SSD-дисками кластеры создавали с тремя хостами, чтобы они считались высокодоступными и на них распространялся SLA сервиса. Для конфигураций со всеми остальными дисками — с двумя хостами.

5. Для тестовых данных взяли 70 млн строк как универсальное значение, которое поместится на диски размером 20 ГБ.

6. Для всех кластеров применяли одинаковый алгоритм нагрузки:

   • После загрузки тестовых данных выполнялся ANALYZE (обновление внутренней статистики по таблицам).
   • Использовали стандартный профиль pgbench со смешанной нагрузкой (чтение и запись) с 32 одновременными клиентскими соединениями.
   • Применяли режим prepared (prepared statements) для уменьшения накладных расходов (разбор структуры SQL-запроса, подготовка к выполнению) на стороне клиентов и сервера. Это позволяет точнее измерять производительность базы в полезной нагрузке.
   • Перед измерением проводили пятиминутный прогрев с той же нагрузкой.
   • После прогрева делали три отдельных прогона по десять минут.
   • Итоговым показателем производительности каждой конфигурации выбрали медианный TPS по трём прогонам (отбрасываем самый высокий и самый низкий из трёх).

Результаты исследования

Результаты по каждому из трёх прогонов для каждого из 28 вариантов кластера отражены в этой диаграмме:

Значения TPS сильно варьируются в зависимости от:

• производительности дисковой подсистемы (локальный или сетевой диск);
• количества и качества ядер (standard-v3 vs standard-v4a);
• размера памяти.

Главные выводы

Мы совместили полученные результаты с актуальной стоимостью конфигураций и выделили решения с оптимальным соотношением цены и качества:

Лидером по производительности оказалась конфигурация local-SSD на 368 ГБ в конфигурации standard-v4a s4a-c4-m16. При этом эта сборка — одна из двух самых дорогих, наряду с standard-v3 s3-c4-m16 на 368 ГБ — 49 503 рубля.

Отдельно мы посчитали эффективность в рублях за TPS — цена за единицу производительности. В трёх ценовых категориях самыми эффективными с точки зрения стоимости TPS оказались такие сборки:

Чем ниже соотношение цены и производительности, тем выгоднее конфигурация. Лучшее значение у standard-v3 c3-c4-m8 (19,9 рубля за TPS). Это оптимальный вариант с высокой скоростью при низкой удельной стоимости.

Наши рекомендации

• Использовать local-ssd. Это даёт двукратный буст производительности, в то время как весь кластер на них стоит всего на 10–15% дороже по сравнению с кластером на сетевых дисках.
• Разворачивать кластер на HDD нет смысла. Производительность на них сильно падает. При практически такой же цене за кластер на сетевых SSD производительность последних выше в два раза.
• В битве платформ standard-v3 и standard-v4a — паритет. Но на сетевых дисках standard-v4a чаще показывает лучшую эффективность при прочих равных.
• Выбор флейворов с меньшим объёмом памяти позволяет сэкономить до 20% в цене кластера, потеряв в производительности единицы процентов. Здесь следует сделать оговорку, что оптимизация памяти — это не всегда хорошее решение. Если у вас высокая доля аналитических запросов, то экономия на памяти может привести к событиям OOM (out of memory), что в свою очередь скажется уже не только на производительности, но и на доступности вашего кластера.