Сайзинг Postgres Pro для аналитических проектов (DWH)
Сайзинг — это процесс определения необходимых ресурсов для развёртывания базы данных: объём хранилища, ОЗУ, количество процессоров, конфигурация сети, резервное копирование. В случае аналитических проектов (DWH) под Postgres Pro необходимо учитывать:
- большие объёмы исторических данных;
- тяжелые запросы с агрегациями;
- требования к SLA по построению отчётов;
- параллельную загрузку (ETL) и аналитику (BI);
- возможную нагрузку на репликации, бэкапы, индексирование.
1. Подход к оценке ресурсов
Сайзинг базируется на:
-
Оценке объема хранимых данных:
- размер таблиц, индексов, TOAST-объектов;
- планируемый прирост.
- Характере нагрузки:
- количество одновременно работающих BI-пользователей;
- тип запросов (сканирование, join, group);
- частота загрузки/обновления данных (ETL).
- SLAs на построение отчётов;
- ожидания от “интерактивности” витрин.
- Необходимом времени отклика:
2. Определение объема хранения
2.1 Формула расчета объема таблицы
Размер таблицы = (Размер строки + служебные поля + TOAST) × количество строк
- Для numeric, timestamp, uuid — 16 байт
- Для text, json, xml — хранится в TOAST, требует учета фрагментации
- Дополнительно: ~20% на индекс + ~30% на TOAST
2.2 Пример
|
Поле |
Тип |
Оценка (байт) |
|---|---|---|
|
customer_id |
UUID |
16 |
|
name |
TEXT |
50 |
|
|
TEXT |
70 |
|
created_at |
TIMESTAMP |
16 |
|
is_active |
BOOLEAN |
1 |
|
Индексы |
— |
~20% |
|
TOAST |
— |
~30% |
Итого: ~200 байт/строка.
При 50 млн строк:
~10 ГБ данных + 2 ГБ индексы + 3 ГБ TOAST = ~15 ГБ
Рекомендуется закладывать минимум 2× запас под рост.
3. RAM и CPU: как оценивать
3.1 Объем ОЗУ (RAM)
Рекомендации:
|
Компонент |
Рекомендация |
|---|---|
|
shared_buffers |
30–40% от RAM |
|
effective_cache_size |
60–70% от RAM |
|
work_mem |
64–512 MB |
|
maintenance_work_mem |
512MB–2GB (для VACUUM, CREATE INDEX) |
Расчет:
RAM ≈ 0.5 × активный объем «горячих» данных + work_mem × параллельных запросов
Пример:
- Хранилище на 2 ТБ, горячие данные ≈ 200 ГБ
- Ожидается 20 одновременных BI-запросов (work_mem = 128MB)
-
Рекомендуемая RAM:
100–150 ГБ shared_buffers + 2.5 ГБ на work_mem + запас = 128 ГБ ОЗУ
3.2 Процессоры (CPU)
Оценка по параллелизму:
- BI-запросы используют max_parallel_workers_per_gather = 2–4
- ETL → может использовать COPY и параллельные insert'ы
- Оптимум: 8–16 ядер (или больше, если частая агрегация + нагрузка от репликации)
Для OLAP-задач критичны большие кэши и частота на ядро, а не только количество ядер.
4. Конфигурация дисков (I/O)
4.1 Дисковая архитектура
|
Раздел |
Тип данных |
Рекомендации |
|---|---|---|
|
/var/lib/pgpro/data |
Основные таблицы и индексы |
SSD/NVMe RAID10 |
|
/pg_wal |
Журнал транзакций (WAL) |
SSD, отдельный volume |
|
/backup |
Архив WAL, бэкапы |
HDD/облако |
|
/tmp |
Временные таблицы, сортировки |
SSD |
4.2 Оценка скорости
- Sequential read: ≥ 300 МБ/сек
- Random read: ≥ 50k IOPS
- WAL: ≥ 50–100 МБ/сек (особенно важно при ETL)
5. Пример типового DWH-проекта
|
Параметр |
Значение |
|---|---|
|
Объем сырых данных в год |
500 ГБ |
|
Срок хранения |
3 года |
|
Количество строк в DWH |
3 млрд |
|
BI-пользователей |
20–30 |
|
Частота ETL |
Каждые 15 минут |
Рекомендуемые ресурсы:
- CPU: 16 ядер
- RAM: 128–192 ГБ
-
Диски:
- 2 ТБ SSD под данные
- 512 ГБ SSD под WAL
- 3 ТБ HDD под backup
6. Резерв + рост
Закладывайте:
- +30% объема под рост структуры и метаданных
- +30% на дубль данных (например, копии витрин, временные таблицы)
- +100% объема под резервные копии
7. Советы и best practices
Что обязательно учитывать
- Размер TOAST (особенно с JSON/текстами)
- Использование materialized views
- Количество индексов
- Размер JOIN-таблиц
- Работа с партициями (если используются)
Полезные SQL для анализа
-- Размер таблиц SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC; -- Кол-во строк SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC; -- Индексы SELECT * FROM pg_stat_user_indexes WHERE idx_scan = 0; -- неиспользуемые
Заключение
Сайзинг для Postgres Pro в DWH-проектах — это баланс между:
- объёмом исторических и активных данных,
- профилем нагрузки BI/ETL,
- SLA на скорость и отказоустойчивость,
- бюджетом на инфраструктуру.
С грамотным планированием можно создать производительное, масштабируемое и надежное аналитическое хранилище даже без вертикального масштабирования.
Postgres Professional — это российская промышленная СУБД, созданная на базе открытого PostgreSQL, но значительно расширенная для корпоративного применения. В отличие от классического PostgreSQL, решения от Postgres Professional включают в себя поддержку российских ГОСТов и сертификацию ФСТЭК, повышенную надёжность, оптимизации под высоконагруженные системы (в том числе 1С и DWH), инструменты резервного копирования, мониторинга и отказоустойчивости. За платформой стоит команда ядра PostgreSQL в России, что гарантирует актуальность, стабильность и экспертную техническую поддержку 24/7.
Для компаний, которым важно не просто использовать PostgreSQL, а внедрить его на уровне корпоративных стандартов — с гарантией, сопровождением, документированными улучшениями и адаптацией под российское законодательство — Postgres Pro Enterprise становится логичным выбором. Это не просто бесплатная база данных, а полноценный продуктовый стек, совместимый с BI, аналитикой, ERP, 1С и другими системами, в том числе импортозамещёнными.
