Партиціонування таблиць БД: прискорення запитів та керування даними
Ми реалізуємо партиціонування таблиць баз даних. Проблема зростання даних — одна з найчастіших причин падіння швидкості. На минулому проекті у клієнта таблиця events виросла до 500 млн рядків, запити висіли по 30 секунд. Ми впровадили партиціонування за місяцями — час відгуку впав до 50 мс, а вартість зберігання знизилася на 40% за рахунок архівації старих розділів.
На іншому проекті таблиця логів займала 1.5 ТБ, після розділення по днях активний набір скоротився до 50 ГБ, а TTFB впав з 3 секунд до 200 мс. Без партиціонування кожен SELECT сканує всю таблицю, зростають LCP та INP. Partition pruning відсікає непотрібні розділи, прискорюючи запити в 5–20 разів залежно від селективності. Типова вибірка за останній місяць при range-розбитті за датою виконується в 10 разів швидше повного сканування.
Наші інженери мають 10+ років досвіду в оптимізації баз даних та успішно реалізували понад 50 проектів з партиціонуванням. Ми гарантуємо коректну роботу рішення.
Які проблеми вирішує партиціонування таблиць?
- Падіння швидкості: великі таблиці без партиціонування сканують усе, зростають LCP та TTFB. Запити з фільтром за датою або категорією — найчастіші жертви.
- Труднощі з обслуговуванням: очищення або архівація старих даних перетворюється на болісний DELETE з блокуваннями.
- Високі витрати на зберігання: SSD дорогий, а зберігати всю історію на швидкому диску нераціонально.
Як ми впроваджуємо партиціонування таблиць
Стек та інструменти
| Компонент | Інструменти |
|---|---|
| СУБД | PostgreSQL (10+), MySQL (8.0+) |
| Автоматизація | pg_partman, cron |
| Міграція | логічна реплікація, батчі |
Типи партиціонування: порівняння
| Тип | Опис | Коли використовувати |
|---|---|---|
| Range | За діапазонами значень (дати, числа) | Часові дані, логи, події |
| Hash | За хешем ключа | Рівномірний розподіл навантаження, немає природного ділення |
| List | За списком значень (країни, статуси) | Фіксовані категорії |
Конкретний кейс
Замовник — маркетингове агентство. Таблиця подій — 500 млн рядків, зростання 10 млн на місяць. Запити до статистики за останній рік гальмували, бекапи важили 200 ГБ.
Ми спроектували range-партиціонування за created_at з місячними розділами. Підключили pg_partman: премейк 3 партиції вперед, retention 12 місяців (автовидалення).
CREATE TABLE events ( id BIGSERIAL, user_id INTEGER NOT NULL, event_type VARCHAR(64) NOT NULL, payload JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ) PARTITION BY RANGE (created_at); CREATE TABLE events_2023_01 PARTITION OF events FOR VALUES FROM ('2023-01-01') TO ('2023-02-01'); -- pg_partman: створення розкладу SELECT partman.create_parent( p_parent_table => 'public.events', p_control => 'created_at', p_type => 'native', p_interval => 'monthly', p_premake => 3 ); Результат: запити прискорилися в 10 разів, розмір продакшену — лише актуальні 6 місяців, старі дані в об'єктному сховищі.
Чому важливий правильний вибір ключа партиціонування?
Partition pruning спрацьовує лише коли WHERE явно використовує ключ. Типова помилка — обгортати ключ у функцію: DATE(created_at) = '2023-01-15' — pruning вимикається. Правильно: created_at >= '2023-01-15' AND created_at < '2023-01-16'. Ми перевіряємо це при тестуванні.
Як виконати міграцію без простою?
- Створюємо нову партиціоновану таблицю з тим самим набором полів.
- Копіюємо дані батчами по місяцях (окремі INSERT).
- Перемикаємо через транзакцію: ALTER TABLE events RENAME TO events_old; ALTER TABLE events_partitioned RENAME TO events; — секунди.
- Видаляємо стару таблицю після тижня моніторингу.
- Налаштовуємо pg_partman для автоматичного керування.
Детальний план міграції
Копіювання великих обсягів без блокувань — використовуємо логічну реплікацію або pglogical. Процес займає від кількох годин до доби залежно від розміру даних. Ми проводимо міграцію в робочий час або в мінімальне вікно.
Процес роботи
- Аналітика — профілюємо запити, виявляємо найповільніші, оцінюємо обсяг даних і швидкість зростання.
- Проектування — обираємо ключ і тип партиціонування (range, hash, list), кількість розділів.
- Реалізація — пишемо скрипти, налаштовуємо pg_partman, створюємо історичні партиції.
- Тестування — перевіряємо partition pruning, заміряємо продуктивність до/після.
- Деплой — міграція за описаною схемою, в робочий час або з мінімальним вікном.
- Моніторинг — налаштовуємо алерти на пропущені партиції та перевищення порогів.
Терміни та що входить
Орієнтовні терміни: від 3 до 10 робочих днів. Вартість розраховується індивідуально. Входить у роботу:
- Документація схеми партиціонування
- Скрипти створення та керування партиціями
- Налаштування автоматичного обслуговування (pg_partman або аналог)
- Інструкція з моніторингу та алертів
- Гарантія 3 місяці на коректну роботу
Замовте консультацію по вашому проекту — ми проаналізуємо навантаження та запропонуємо оптимальне рішення.
Типові помилки при партиціонуванні таблиць
- Неправильний ключ — pruning не працює, продуктивність падає
- Індекси створені на батьку, але не на всіх партиціях (PG<11)
- Відсутній премейк — нові партиції не створюються вчасно
- У MySQL унікальні ключі мусять включати ключ партиціонування
Коли партиціонування не потрібне
- Таблиця менше 10–20 млн рядків — достатньо індексів
- Немає чіткого ключа (дані без часової або категоріальної мітки)
- Запити не фільтрують за ключем — вигоди не буде
Докладніше про партиціонування PostgreSQL — офіційна документація
Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Ми проаналізуємо навантаження та запропонуємо оптимальне рішення.