Зберігання парсингу: 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 днів. Зв'яжіться з нами, щоб оцінити ваш проєкт. Отримайте консультацію з проєктування схеми для вашого проєкту. Ми допоможемо уникнути типових помилок і прискорити розробку.