Оптимізація PostgreSQL для Paperclip: конфігурація, індекси, реплікація

Налаштування PostgreSQL для Paperclip у продакшені — завдання, яке не можна відкладати. Коли 50 AI-агентів одночасно пишуть логи дій, викликають LLM та оновлюють статуси завдань, база починає деградувати вже через тиждень. Без правильної конфігурації latency SELECT зростає до 5 секунд, а падіння primary призводить до втрати даних за останні хвилини. Ми налаштовуємо PostgreSQL так, щоб він витримував таке навантаження без збоїв: latency < 100 мс при 95-му перцентилі, автоматичний failover за 30 секунд, точка відновлення до будь-якої секунди.

Які проблеми вирішує правильне налаштування?

Деградація запитів до логів агентів. Без складених індексів на agent_id та created_at фільтрація за датою перетворюється на full scan. Ми ставимо partial індекси для активних завдань — це прискорює вибірку в 10 разів порівняно з full scan.

Швидке зростання таблиць. Таблиця логів легко виростає на сотні гігабайт на місяць. Використовуємо партиціонування таблиць PostgreSQL за датою: старі партиції автоматично архівуються та видаляються, а запити до свіжих даних залишаються швидкими. Партиціонування знижує час бекапу в 2 рази. Це знижує footprint на 40% та прискорює бекапи.

Втрата даних при збої. Налаштовуємо streaming replication з Patroni для автоматичного failover. Якщо primary падає, replica бере на себе роль за 30 секунд. WAL-архівування в S3 через pgBackRest дає точку відновлення до будь-якої секунди — економія на простої до 50%.

Як ми це робимо: стек та кейс

Для типового проекту — Paperclip з 50 AI-агентами — використовуємо PostgreSQL 16 на Ubuntu 22.04. Конфігурація:

shared_buffers = 25% RAM work_mem = 64MB maintenance_work_mem = 1GB effective_cache_size = 75% RAM wal_buffers = 64MB random_page_cost = 1.1 

Індекси створюємо тільки після аналізу реального workload через pg_stat_statements. Партиції — по днях з retention 90 днів. Реплікація — синхронна на одну replica, Patroni контролює кластер.

Кейс: один із наших клієнтів мав latency SELECT до 5 секунд після місяця роботи. Після нашого налаштування p99 впав до 80 мс. Витрати на інфраструктуру знизилися на 30% за рахунок ефективного використання ресурсів. Економія на інфраструктурі склала $3500 на місяць.

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

1. Аналіз схеми та навантаження — збираємо метрики, вивчаємо запити Paperclip.
2. Проектування конфігурації — підбираємо shared_buffers, work_mem, плануємо партиції та індекси.
3. Реалізація — застосовуємо зміни, налаштовуємо Patroni та реплікацію.
4. Тестування — навантажувальне тестування з синтетичними агентами, перевірка failover.
5. Деплой у продакшен — поетапний rollout, моніторинг першу добу.

Що входить у роботу

• Конфігурація PostgreSQL (параметри, індекси, партиції).
• Налаштування реплікації (Streaming + Patroni) або відмовостійкого кластера.
• Резервне копіювання (pgBackRest + S3 з PITR).
• Моніторинг (Prometheus + Grafana + алерти).
• Документація та рекомендації з експлуатації.

Терміни та метрики

Робота займає від 3 до 7 днів залежно від складності схеми. Наша команда має багаторічний досвід у PostgreSQL (понад 30 проектів з AI-навантаженням). Гарантуємо, що latency не перевищить 100 мс при 95-му перцентилі. Отримайте консультацію по вашому проекту — оцінимо за один день.

Як правильно налаштувати PostgreSQL для Paperclip?

Головне правило — не копіювати дефолтні налаштування. Починаємо з shared_buffers = 25% RAM, а потім підлаштовуємося під real workload. Обов'язково вмикаємо pg_stat_statements для збору статистики — без неї ви сліпі. Ми використовуємо методи PostgreSQL production tuning для досягнення високої продуктивності. Використовуємо офіційну документацію Patroni як опору, але адаптуємо під Paperclip. Забезпечуємо високу доступність PostgreSQL.

Що робити при високому навантаженні?

Підключаємо PgBouncer для пулу з'єднань — Paperclip може відкривати сотні коннектів. Збільшуємо work_mem для складних запитів (RAG, пошук по ембедінгах). Якщо навантаження пікове, тимчасово піднімаємо додаткові репліки читання. Для порівняння: без PgBouncer max_connections впирається в ліміт уже при 50 агентах, а з ним ми легко тримаємо 200 агентів.

Моніторинг та алерти