Партиціонування таблиць БД: впровадження під ключ

Партиціонування таблиць БД: прискорення запитів та керування даними

Ми реалізуємо партиціонування таблиць баз даних. Проблема зростання даних — одна з найчастіших причин падіння швидкості. На минулому проекті у клієнта таблиця 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 дорогий, а зберігати всю історію на швидкому диску нераціонально.

Як ми впроваджуємо партиціонування таблиць

Стек та інструменти

Типи партиціонування: порівняння

Конкретний кейс

Замовник — маркетингове агентство. Таблиця подій — 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'. Ми перевіряємо це при тестуванні.

Як виконати міграцію без простою?

1. Створюємо нову партиціоновану таблицю з тим самим набором полів.
2. Копіюємо дані батчами по місяцях (окремі INSERT).
3. Перемикаємо через транзакцію: ALTER TABLE events RENAME TO events_old; ALTER TABLE events_partitioned RENAME TO events; — секунди.
4. Видаляємо стару таблицю після тижня моніторингу.
5. Налаштовуємо pg_partman для автоматичного керування.

Процес роботи

1. Аналітика — профілюємо запити, виявляємо найповільніші, оцінюємо обсяг даних і швидкість зростання.
2. Проектування — обираємо ключ і тип партиціонування (range, hash, list), кількість розділів.
3. Реалізація — пишемо скрипти, налаштовуємо pg_partman, створюємо історичні партиції.
4. Тестування — перевіряємо partition pruning, заміряємо продуктивність до/після.
5. Деплой — міграція за описаною схемою, в робочий час або з мінімальним вікном.
6. Моніторинг — налаштовуємо алерти на пропущені партиції та перевищення порогів.

Терміни та що входить

Орієнтовні терміни: від 3 до 10 робочих днів. Вартість розраховується індивідуально.

Входить у роботу:

• Документація схеми партиціонування
• Скрипти створення та керування партиціями
• Налаштування автоматичного обслуговування (pg_partman або аналог)
• Інструкція з моніторингу та алертів
• Гарантія 3 місяці на коректну роботу

Замовте консультацію по вашому проекту — ми проаналізуємо навантаження та запропонуємо оптимальне рішення.

Типові помилки при партиціонуванні таблиць

• Неправильний ключ — pruning не працює, продуктивність падає
• Індекси створені на батьку, але не на всіх партиціях (PG<11)
• Відсутній премейк — нові партиції не створюються вчасно
• У MySQL унікальні ключі мусять включати ключ партиціонування

Коли партиціонування не потрібне

• Таблиця менше 10–20 млн рядків — достатньо індексів
• Немає чіткого ключа (дані без часової або категоріальної мітки)
• Запити не фільтрують за ключем — вигоди не буде

Докладніше про партиціонування PostgreSQL — офіційна документація

Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Ми проаналізуємо навантаження та запропонуємо оптимальне рішення.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.