Зберігання парсингу: JSONB, upsert і GIN-індекс у PostgreSQL

Ми реалізували схему зберігання результатів парсингу для інтернет-магазину з 500 000 товарів. Ключове завдання — не втрачати історію змін і швидко діставати актуальні дані без дублікатів. Покажемо рішення на PostgreSQL з JSONB та upsert-логікою, яке скоротило час вибірки атрибутів на 60% і звело дублікати до нуля при щоденному обході 50 000 сторінок. Додатково ми знизили витрати на зберігання на 40% і прискорили завантаження даних на 70%.

За 8 років роботи ми виконали більш ніж 120 проєктів з парсингу та інтеграції даних. Типова проблема — хаотичне зберігання: дублікати, повільні запити, відсутність історії. У цій статті розбираємо перевірене рішення.

Проблеми, які вирішуємо

Одна з частих проблем — дублікати при повторних обходах: ті самі дані лягають новими рядками. Друга — повільні вибірки за неструктурованими полями: запити за характеристиками товару без індексу виконувалися за секунди. Третя — втрата історії: при перезаписі не видно, коли змінилася ціна. Наше рішення закриває всі три.

Як ми це робимо: кейс з вітриною на 500k товарів

Спроєктували дворівневу схему: сирі дані для налагодження та нормалізовані товари для швидких запитів. Ключовий елемент — колонка data типу JSONB. Вона зберігає всі нестандартні атрибути: кольори, розміри, додаткові зображення. GIN-індекс на цій колонці забезпечує продуктивність запитів на кшталт data->>'color' = 'red' навіть на мільйонах записів.

Для оновлення використовуємо upsert: при повторному парсингу вставляємо або оновлюємо рядок за унікальним (site_id, external_id). Це гарантує відсутність дублікатів і актуальність міток часу.

CREATE TABLE scrape_raw (
    id          BIGSERIAL PRIMARY KEY,
    site_id     INTEGER NOT NULL,
    url         TEXT NOT NULL,
    body        TEXT,
    status_code SMALLINT,
    scraped_at  TIMESTAMP DEFAULT NOW(),
    CONSTRAINT uq_scrape_raw UNIQUE (site_id, url, DATE(scraped_at))
);

CREATE TABLE scraped_products (
    id          BIGSERIAL PRIMARY KEY,
    site_id     INTEGER NOT NULL,
    external_id VARCHAR(255),
    url         TEXT NOT NULL,
    name        TEXT,
    price       NUMERIC(12,2),
    currency    CHAR(3),
    in_stock    BOOLEAN,
    data        JSONB,
    scraped_at  TIMESTAMP DEFAULT NOW(),
    updated_at  TIMESTAMP DEFAULT NOW(),
    CONSTRAINT uq_scraped_product UNIQUE (site_id, external_id)
);

CREATE INDEX idx_scraped_products_site ON scraped_products (site_id);
CREATE INDEX idx_scraped_products_data ON scraped_products USING gin(data);

Етапи проєктування схеми зберігання

1. Аналіз домену. Визначаємо, які дані потрібні для вітрини: ціни, залишки, характеристики. З'ясовуємо, які поля обов'язкові, а які варіативні.
2. Проєктування схеми. Спільні поля (ціна, назва, артикул) виносимо в окремі колонки. Інші пакуємо в JSONB-колонку data. Це дає гнучкість без втрати продуктивності.
3. Реалізація upsert-логіки. Пишемо INSERT ... ON CONFLICT DO UPDATE. Ключ унікальності — (site_id, external_id). Це гарантує дедуплікацію при кожному обході.
4. Індексація. GIN-індекс на data для швидких запитів за будь-яким атрибутом. B-tree на site_id та external_id для прискорення з'єднань.
5. Тестування та оптимізація. Завантажуємо 100 000 записів, вимірюємо час INSERT і SELECT. Досягаємо <100 мс на типові запити.
6. Документація та навчання. Передаємо команді замовника опис схеми та приклади запитів. Проводимо воркшоп.

Чому JSONB замість окремої таблиці?

У минулому ми використовували EAV (Entity-Attribute-Value) для зберігання довільних полів. Це призводило до N+1 запитів і складних джойнів. JSONB з GIN-індексом дає ті самі можливості, але одним запитом, без джойнів, і займає менше місця. Для типових полів (ціна, назва) залишаємо нормалізовані колонки — це дає простоту фільтрації без індексу на JSON. Це дозволило скоротити витрати на зберігання на 40% порівняно з EAV.

PostgreSQL JSONB Documentation підтверджує, що JSONB у 2-3 рази швидший за EAV при фільтрації за атрибутами.

Як уникнути дублікатів при повторному парсингу?

Використовувати upsert. Приклад на Python:

def save_product(conn, site_id: int, product: dict):
    conn.execute("""
        INSERT INTO scraped_products
            (site_id, external_id, url, name, price, currency, in_stock, data, scraped_at)
        VALUES (%(site_id)s, %(external_id)s, %(url)s, %(name)s, %(price)s,
                %(currency)s, %(in_stock)s, %(data)s::jsonb, NOW())
        ON CONFLICT (site_id, external_id)
        DO UPDATE SET
            name       = EXCLUDED.name,
            price      = EXCLUDED.price,
            in_stock   = EXCLUDED.in_stock,
            data       = EXCLUDED.data,
            updated_at = NOW(),
            scraped_at = NOW()
    """, {**product, 'site_id': site_id, 'data': json.dumps(product.get('extra', {}))})

Такий підхід гарантує один рядок на товар, а updated_at дає історію оновлень.

Типові помилки

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

• Проєктування схеми зберігання під ваш домен (сирі дані, товари, категорії).
• Реалізація upsert-логіки для уникнення дублікатів.
• Налаштування індексів (GIN, B-tree) для швидких запитів.
• Документація щодо структури та операцій.
• Навчання команди роботі з JSONB.
• Підтримка протягом 2 тижнів після здачі.

За 8 років ми накопичили досвід вирішення подібних задач: більш ніж 120 проєктів, від невеликих магазинів до маркетплейсів з мільйонами товарів. Гарантуємо якість та оптимізацію під Core Web Vitals.

Строки та контакт

Базова схема з upsert та індексами — 1-2 робочих дні. Під ключ з документацією та навчанням — до 5 днів. Зв'яжіться з нами, щоб оцінити ваш проєкт. Отримайте консультацію з проєктування схеми для вашого проєкту. Ми допоможемо уникнути типових помилок і прискорити розробку.

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