Калькулятор розміру бази даних та IOPS: дисковий простір, індекси, WAL та бекапи

Прогнозування місткості сховища для реляційних та нереляційних СУБД - це критичний елемент інфраструктурного планування. Неправильна оцінка дискового простору на етапі запуску проєкту неминуче призводить до аварійних зупинок production-систем, вичерпання лімітів хмарних блочних сховищ або непередбачуваних капітальних витрат на закупівлю заліза. Цей матеріал та вбудований безпосередньо на цій сторінці інтерактивний інструмент розрахунку створені для того, щоб усунути невизначеність у capacity planning для PostgreSQL, MySQL та MongoDB.

Важливо: На відміну від примітивних калькуляторів, які множать кількість рядків на їхню середню довжину, повноцінний розрахунок обов’язково враховує внутрішню архітектуру СУБД: механізми контролю паралельного доступу (MVCC), оверхед на вирівнювання пам’яті (alignment), розміри B-Tree та GIN індексів, інтенсивність генерації журналів транзакцій (WAL / Binlog) та політику зберігання бекапів відповідно до цільових показників RPO.

Навіщо потрібен розрахунок дискового простору та iops для сучасних бд

Архітектура сучасних enterprise-додатків вимагає чіткого розуміння того, як навантаження трансформується у фізичні гігабайти на накопичувачах і навантаження на підсистему введення-виведення. Зростання бази даних рідко буває лінійним. Додавання нових індексів, зміна бізнес-логіки та інтенсивні фонові процеси здатні заповнити вільне місце на дисках набагато швидше, ніж прогнозували розробники.

Типовий сценарій ризику виглядає так: база даних розгортається на диску обсягом 500 ГБ з розрахунком на 2 роки роботи. Проте вже через 8 місяців через активні операції оновлення (`UPDATE`) ініціюється роздування таблиць і журналів передзапису. Файлова система блокується, процеси запису аварійно зупиняються (out-of-disk error), що призводить до тривалого простою (downtime) сервісу та потенційної корупції даних при екстреному завершенні роботи СУБД.

Окрім чистого обсягу пам’яті, критично важливим є прогнозування продуктивності дискової підсистеми - IOPS (Input/Output Operations Per Second) та пропускної здатності (Throughput). Неправильно підібраний тип хмарного диска (наприклад, перехід на AWS EBS gp2/gp3 без урахування лімітів burst-балансу або IOPS на гігабайт) створює латентність на рівні додатку, навіть якщо фізичного місця на диску ще достатньо.

Аналіз цільової аудиторії: хто і чому використовує калькулятор сховища

Різні технічні ролі в компанії мають власні пріоритети, метрики та обмеження під час розрахунку ресурсів баз даних. Розуміння цих інтересів допомагає сформувати збалансовану конфігурацію інфраструктури.

Як працює калькулятор: математичні моделі та алгоритми розрахунку

В основі коректного розрахунку лежить глибоке розуміння того, як СУБД зберігають дані на диск. Розглянемо ключові математичні моделі, які використовує професійний калькулятор для трансформації бізнес-метрик у системні ресурси.

1. Розрахунок базового розміру таблиці: Загальний обсягу «сирих» даних визначається як добуток кількості рядків на середній реальний розмір одного рядка з урахуванням вирівнювання пам’яті (alignment) та бітів нулів (NULL bitmaps). Формула: Total Table Size = (Number of Rows * Average Row Size) / (1 - Fill Factor Overhead).
2. Облік оверхеду MVCC: У таких СУБД, як PostgreSQL, операції оновлення та видалення не видаляють фізичні дані одразу, а створюють нові версії рядків (tuple versions). Це створює внутрішнє роздування (Table & Page Bloat), яке компенсується процесами VACUUM, але вимагає додаткового запасу дискового простору (типово +20-30%).
3. Розрахунок індексів: Індекси типу B-Tree та GIN не є статичними. Середній оверхед PostgreSQL B-Tree індексів складає 20-40% від розміру табличних даних залежно від кількості індексованих колонок, кардинальності даних та частоти модифікацій.
4. Генерація журналів транзакцій (WAL / Binlog): Інтенсивне write-heavy навантаження генерує значний потік журналів передзапису. У PostgreSQL та MySQL журнали транзакцій можуть створювати від 30% до 200% обсягу щоденного приросту даних залежно від інтенсивності `UPDATE`/`DELETE` та налаштувань checkpoint.

Архітектура даних: облік оверхеду таблиць, індексів, wal та бекапів

Щоб спланувати надійну інфраструктуру, недостатньо порахувати самі таблиці. Повний обсяг дискового простору формується з чотирьох ключових шарів, кожен із яких має власний коефіцієнт розширення.

• Табличні дані (Heap / Data Files): Фундаментальний обсяг інформації, що залежить від кількості записів та схем таблиць. У MongoDB рушій WiredTiger використовує внутрішнє стиснення (зрідка дає економію до 50-70%), тоді як реляційні БД зберігають дані у сторінках по 8 КБ (PostgreSQL) або 16 КБ (MySQL InnoDB) із фіксованим заповненням залежно від параметра fillfactor.
• Індекси (B-Tree, GIN, Hash): Індекси прискорюють пошук, але споживають дисковий простір. У таблицях із великою кількістю невеликих текстових полів або JSONB-документів сумарний обсяг індексів може перевищувати розмір самих таблиць у 1.5-2 рази.
• Журнали транзакцій (WAL, Binlog, Oplog): Необхідні для забезпечення ACID-властивостей та реплікації. При інтенсивному потоці транзакцій старі файли WAL видаляються не відразу (особливо при наявності відстаючих реплік або тривалих транзакцій), що загрожує раптовим заповненням диска.
• Резервні копії (Backups & Retention): Політика RPO (Recovery Point Objective) визначає, скільки повних (Full) та інкрементальних/диференційних (Incremental) копій зберігається на локальному чи віддаленому сховищі. Сумарний обсяг бекапів часто дорівнює або перевищує робочий обсяг самої бази даних.

Порада експерта: Завжди закладайте у бюджет мінімум 30-40% вільного простору (Headroom) на дисковому масиві для production-середовищ. Це дозволить без авралів виконувати планові операції реіндексації (`REINDEX`), процедури `VACUUM FULL`, створювати локальні міграційні дампи та переживати пікові сплески навантаження без зупинки додатку.

Практичні приклади та сценарії розрахунку для різних субд

Розглянемо практичний кейс прогнозування для OLTP-системи електронної комерції з початковою базою в 10 мільйонів рядків та щоденним приростом у 50 000 нових записів протягом 3 років.

Сценарій для PostgreSQL 15:

• Початкова кількість рядків: 10 000 000.
• Середній розмір рядка: 450 байт.
• Кількість індексів: 3 (первинний ключ + 2 зовнішні ключі / пошукові поля). Оверхед індексів: ~35%.
• Щоденний приріст даних: 50 000 рядків * 450 байт = 22.5 МБ на день (до урахування оверхеду).
• З урахуванням MVCC оверхеду (фактор 1.3), індексів (+35%) та щоденного обсягу WAL (~40% від приросту даних), реальний приріст дискового простору за 3 роки складе приблизно 75-90 ГБ лише для робочих даних, без урахування політики зберігання бекапів.

Сценарій для MongoDB 6.0 (WiredTiger):

• Документна модель із вкладеними масивами. Середній розмір документа: 2 КБ.
• Кількість документів: 15 000 000.
• Завдяки вбудованому алгоритму стиснення Snappy або zlib у WiredTiger (коефіцієнт стиснення ~2.5x), «сирий» обсяг у 30 ГБ фізично займає на диску близько 12-14 ГБ. Проте слід пам’ятати про потребу в додатковому просторі для оперативної пам’яті (RAM) та файлів розмітки (indexes), які зберігаються нестисненими в пам’яті або вимагають пам’яті під кеш.

Покрокова інструкція використання калькулятора на сторінці

Для отримання точного прогнозу місткості дискового сховища та вимог до IOPS скористайтеся інтерактивним калькулятором, розташованим вище на цій сторінці. Дотримуйтеся такого порядку введення даних:

1. Виберіть СУБД: Вкажіть цільову систему керування базами даних (PostgreSQL, MySQL або MongoDB), оскільки алгоритми враховують специфіку рушіїв зберігання (InnoDB, WiredTiger, Heap).
2. Введіть базові метрики таблиць: Вкажіть поточну кількість рядків/документів та середній розмір одного запису в байтах. За потреби скористайтеся готовми пресетами для типових проєктів (CRM, E-commerce, IoT-телеметрія).
3. Задайте параметри інтенсивності: Введіть прогнозований щоденний приріст записів та співвідношення операцій читання й запису (Read/Write ratio) для розрахунку пікових IOPS.
4. Налаштуйте політику індексів і журналів: Укажіть кількість та тип індексів, а також період зберігання журналів транзакцій (WAL / Binlog retention) та резервних копій (RPO retention).
5. Проаналізуйте результат: Отримайте зведений графік та таблицю необхідного дискового простору на 1, 3 та 5 років із врахуванням рекомендованого аварійного запасу (Headroom).

Експертні поради: підводні камені capacity planning та вибору nvme / ebs

Під час закупівлі хмарного обладнання (наприклад, AWS EBS io2 / gp3) або фізичних серверів із NVMe-накопичувачами інженери часто припускаються типових помилок. Використання матриці усунення несправностей допоможе уникнути інфраструктурних проблем ще на етапі проєктування.

Поширені запитання (faq)

Як впливає fill factor на кінцевий розмір таблиці та частоту появи page bloat?

Параметр fillfactor визначає, на який відсоток заповнюються сторінки даних під час їх первинного створення чи перепакування. Якщо встановити fillfactor на рівні 70-80% замість 100% для таблиць із частими оновленнями (`UPDATE`), СУБД залишає вільний простір всередині сторінок для нових версій рядків (MVCC). Це суттєво зменшує міграцію рядків на інші сторінки та запобігає швидкому появі Page Bloat, хоча й дещо збільшує початковий розмір таблиці на дисковому сховищі.

Чому розмір індексів у postgresql іноді перевищує розмір самих таблиць?

Це типова ситуація для таблиць із великою кількістю текстових колонок, унікальних ідентифікаторів (`UUID`) або при активному використанні складених B-Tree та GIN індексів. Оскільки кожен індекс зберігає не лише посилання на рядок (TID), а й ключові значення з урахуванням вирівнювання та структури збалансованого дерева, наявність 3-4 індексів на таблицю легко призводить до того, що сумарний обсяг індексів перевершує розмір самих даних у табличному каталозі.

Як розрахувати необхідний обсяг диска з урахуванням політики retention для wal та інкрементальних бекапів?

Необхідно підсумувати робочий обсяг даних і всіх індексів, додати обсяг журналів транзакцій за максимальний період їх утримання (залежно від частоти повних та інкрементальних бекапів), а також зарезервувати місце під зберігання самих резервних копій згідно з правилом RPO. Наприклад, якщо щоденний інкрементальний бекап складає 10 ГБ, а повний тижневий - 150 ГБ при глибині зберігання 30 днів, під самі бекапи слід виділити окремий простір, що в 1.5-2 рази перевищує розмір активної бази даних.

Скільки iops потрібно виділити на ssd/nvme для high-load oltp бази даних на 1 млн щоденних транзакцій?

Розрахунок IOPS базується на піковому навантаженні (Peak TPS), а не на середньодобовому. Якщо 1 млн транзакцій припадає рівномірно, це близько 12 транзакцій на секунду. Проте в годинні піки навантаження може зростати у 4-5 разів (до 50-60 TPS). З урахуванням того, що кожна транзакція в OLTP може генерувати від 5 до 20 дискових операцій (читання індексів, запис даних, оновлення WAL), мінімальний розрахунковий показник для комфортної роботи такої системи становить від 300 до 1000 пікових IOPS із низькою латентністю (< 2 мс).

Чому моніторинг вільного місця на файловій системі відрізняється від розміру даних усередині postgresql (vacuum ефект)?

Операційна система бачить розмір файлів таблиць на рівні файлової системи. Коли рядки видаляються або оновлюються, PostgreSQL позначає старі версії рядків як вільні (dead tuples), але не повертає цей простір операційній системі одразу - простір залишається всередині файлу таблиці для майбутніх вставок. Процеси фонового `VACUUM` роблять ці ділянки доступними для повторного використання всередині СУБД, але не зменшують фізичний розмір файлу на диску. Для повернення місця ОС потрібен дорогий запуск команди `VACUUM FULL` або `pg_repack`.

Як калькулятор враховує специфіку стиснення у двигуні wiredtiger для mongodb?

Двигун WiredTiger використовує алгоритми стиснення блоків (за замовчуванням Snappy або опціонально zlib) на рівні пам’яті та диска. Калькулятор застосовує емпіричний коефіцієнт редукції розміру (typically 2.0x - 3.0x залежно від типу даних і наявності великих вкладених структур), що дозволяє відобразити реальний обсяг, який займуть документи у файловій системі після роботи вбудованого компресора.

Що робити, якщо журнали транзакцій (wal/binlog) повністю забили дисковий розділ?

Якщо диск заповнено на 100%, СУБД зазвичай аварійно зупиняється через неможливість запису нових логів. Необхідно терміново звільнити мінімальний простір (наприклад, перенести старі архівні копії або лог-файли на інший розділ, або безпечно видалити найстаріші файли WAL, якщо ви впевнені, що вони вже заархівовані чи передані на репліку). Після запуску бази обов’язково перевірте стан реплікації та налаштування `wal_keep_size` / `expire_logs_days`.

Як правильно порахувати вимоги до сховища для багатосерверної реплікації (master-slave)?

У класичній архітектурі Master-Slave самі сервери реплік потребують аналогічного обсягу дискового простору, оскільки вони зберігають повну копію даних та індексів. Крім того, на серверах-джерелах (Master) необхідно закладати додатковий простір на випадок тимчасового відключення або значного відставання репліки (Replication Lag), оскільки на Мастері накопичуватимуться журнали транзакцій, які очікують на підтвердження доставки до Slave.

Чи потрібно додавати коефіцієнт фрагментації диска при розрахунку обладнання в aws ebs?

Для хмарних блочних сховищ (AWS EBS, GCP Persistent Disk) традиційна фрагментація файлової системи ext4/XFS має мінімальний вплив на продуктивність через віртуалізовану природу NVMe-масивів провайдера. Проте варто закладати коефіцієнт накладних витрат метаданих файлової системи (близько 3-5% від загального обсягу тому) та забезпечувати необхідний запас IOPS для покриття пікових операцій запису.

Як часто потрібно переглядати прогноз місткості бази даних у міру зростання бізнесу?

Прогноз місткості (Capacity Planning) не є разовою процедурою. Рекомендується переглядати та коригувати модель у калькуляторі щонайменше раз на квартал або перед запуском великих маркетингових кампаній чи релізів нових функціональних модулів, які можуть різко змінити профіль навантаження та швидкість генерації даних у базі.