Інженерний підхід до зберігання спарсених даних: PostgreSQL, версіонування, JSONB

Інженерний підхід до зберігання спарсених даних: PostgreSQL, версіонування, JSONB

Ви зібрали 10 000 оголошень з Avito, а за тиждень половина змінилася. CSV тут же перетвориться на кашу — зміни не відстежити. MongoDB без строгої схеми — лише відтермінування хаосу: з часом дані забруднюються. Потрібна система, яка запам'ятає кожну зміну і дозволить знайти потрібне за мілісекунди. Ми створюємо такі рішення — на базі PostgreSQL з версіонуванням, повнотекстовим пошуком та REST API. Наша схема десятиліттями працює в продакшені. Документація PostgreSQL рекомендує GIN-індекси для JSONB, що дає швидкість і гнучкість. Давайте розберемо конкретну реалізацію. Основна таблиця scraped_items зберігає актуальні дані, а scraped_items_history — архів змін. Такий підхід забезпечує повний audit trail без втрати продуктивності.

Схема зберігання в PostgreSQL

-- Основна таблиця з історією змін
CREATE TABLE scraped_items (
    id          BIGSERIAL PRIMARY KEY,
    source_id   INTEGER REFERENCES sources(id),
    external_id TEXT NOT NULL,           -- ID на стороні джерела
    url         TEXT NOT NULL,
    data        JSONB NOT NULL,          -- гнучка схема для різних джерел
    data_hash   CHAR(64) NOT NULL,       -- SHA-256 від data для детекції змін
    first_seen  TIMESTAMPTZ DEFAULT NOW(),
    last_seen   TIMESTAMPTZ DEFAULT NOW(),
    changed_at  TIMESTAMPTZ,
    UNIQUE (source_id, external_id)
);

-- Історія змін
CREATE TABLE scraped_items_history (
    id          BIGSERIAL PRIMARY KEY,
    item_id     BIGINT REFERENCES scraped_items(id),
    data        JSONB NOT NULL,
    recorded_at TIMESTAMPTZ DEFAULT NOW()
);

-- Індекси
CREATE INDEX ON scraped_items USING GIN (data);           -- пошук по JSONB
CREATE INDEX ON scraped_items (source_id, last_seen);
CREATE INDEX ON scraped_items USING GIN (
    to_tsvector('russian', data->>'title' || ' ' || COALESCE(data->>'description', ''))
);

Ключові рішення: використання JSONB для змінної схеми, окрема таблиця історії, хеш даних для швидкого виявлення змін. Така схема забезпечує ACID-транзакції та цілісність при паралельному завантаженні.

Логіка оновлення

def upsert_item(source_id, external_id, url, data):
    data_hash = hashlib.sha256(
        json.dumps(data, sort_keys=True).encode()
    ).hexdigest()

    existing = db.query(
        'SELECT id, data_hash FROM scraped_items WHERE source_id=%s AND external_id=%s',
        (source_id, external_id)
    ).fetchone()

    if existing is None:
        # новий елемент
        db.execute(
            'INSERT INTO scraped_items (source_id, external_id, url, data, data_hash) '
            'VALUES (%s, %s, %s, %s, %s)',
            (source_id, external_id, url, json.dumps(data), data_hash)
        )
    elif existing['data_hash'] != data_hash:
        # дані змінилися — зберігаємо історію
        db.execute(
            'INSERT INTO scraped_items_history (item_id, data) '
            'SELECT id, data FROM scraped_items WHERE id=%s',
            (existing['id'],)
        )
        db.execute(
            'UPDATE scraped_items SET data=%s, data_hash=%s, last_seen=NOW(), changed_at=NOW() '
            'WHERE id=%s',
            (json.dumps(data), data_hash, existing['id'])
        )
    else:
        # дані не змінилися — оновлюємо only last_seen
        db.execute(
            'UPDATE scraped_items SET last_seen=NOW() WHERE id=%s',
            (existing['id'],)
        )

Функція upsert_item обробляє три сценарії: вставка нового об'єкта, оновлення зі збереженням історії (якщо хеш змінився), і лише позначка last_seen без змін. Це мінімізує I/O і прискорює обробку. Під навантаженням 100 000 записів на день весь pipeline вкладається в 15 хвилин.

Чому JSONB, а не окремі колонки?

Спарсені дані часто мають нестабільну структуру: сьогодні у товару є вага, завтра — колір. JSONB знімає проблему міграцій і дозволяє індексувати будь-які поля через GIN-індекс. Ми використовуємо гібридний підхід: ключові поля виносимо в колонки для швидких фільтрів, а решту — в JSONB. Це дає швидкість реляційної моделі та гнучкість документо-орієнтованої. На практиці JSONB в PostgreSQL працює в 3 рази швидше за MongoDB при вибірках за структурованими полями.

Як ми детектуємо зміни без втрати продуктивності?

Використовуємо SHA-256 від серіалізованого JSON. Хеш порівнюється зі збереженим при кожному upsert. Така перевірка виконується за O(1) і не потребує читання всього рядка. Для великих обсягів (мільйони записів) застосовуємо партиціонування за source_id.

Порівняння підходів до зберігання

Pipeline обробки: етапи та інструменти

Процес реалізації

1. Аналіз джерел — визначаємо структуру даних та частоту оновлення.
2. Проектування схеми — обираємо індекси, налаштовуємо партиціонування для великих обсягів.
3. Розробка upsert-логіки — пишемо функцію з детекцією змін за хешем.
4. Pipeline обробки — нормалізація, збагачення, агрегація.
5. API та експорт — REST endpoints з пагінацією, а також вивантаження в CSV/XLSX.
6. Моніторинг та архівування — TTL-політика, сповіщення про збої.

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

• Спроектована схема БД з міграціями
• GitHub-репозиторій з кодом (upsert, pipeline, API)
• Документація по API (OpenAPI/Swagger)
• Інструкція з розгортання (Docker Compose)
• Гарантія відсутності помилок на етапі приймання

Архівація та TTL

Старі дані (не бачені більше 90 днів) переводяться в архів або видаляються — залежить від вимог. Історія змін зберігається довше за основні дані — за замовчуванням 365 днів. Все налаштовується під ваш бізнес-кейс.

Експорт

• CSV/XLSX — через pandas.to_excel() або csv.DictWriter
• REST API — FastAPI/Laravel з фільтрацією, пагінацією, сортуванням
• Webhook — відправка нових/змінених записів в сторонню систему в реальному часі

Час реалізації системи зберігання з історією змін та API — 4–6 днів. Ми гарантуємо коректну роботу під навантаженням до 100 тис. записів на день. Якщо вам потрібне надійне сховище спарсених даних — зв'яжіться з нами для обговорення схеми. Наш досвід — десятки впроваджених систем. Отримайте консультацію — ми допоможемо підібрати оптимальну схему.

Послуги бекенд-розробки: 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% без втрати продуктивності.