Чем JSON отличается от JSONB? Когда что использовать? Какие операторы для JSONB (->, ->>, @>)?

Операторы jsonb

-- Создание таблицы с jsonb
CREATE TABLE events (
    event_id  bigserial PRIMARY KEY,
    payload   jsonb NOT NULL,
    created_at timestamptz DEFAULT now()
);

-- -> : получить значение как jsonb (объект/массив остаётся jsonb)
SELECT payload -> 'user' FROM events;
-- Вернёт: {"id": 42, "email": "test@example.com"}

-- ->> : получить значение как text
SELECT payload ->> 'type' FROM events;
-- Вернёт: signup  (строка без кавычек)

-- Вложенный доступ:
SELECT payload -> 'user' ->> 'email' FROM events;

-- @> : containment — левый jsonb содержит правый фрагмент
SELECT * FROM events
WHERE payload @> '{"type": "signup"}'::jsonb;

-- <@ : обратный containment
SELECT * FROM events
WHERE '{"type": "signup"}'::jsonb <@ payload;

-- ? : проверка наличия ключа
SELECT * FROM events WHERE payload ? 'error_code';

-- #> : вложенный путь как jsonb, #>> : как text
SELECT payload #>> '{user,email}' FROM events;

json vs jsonb: внутреннее представление

json хранит данные как текст — точная копия входной строки, включая пробелы, порядок ключей и дубликаты. При каждом обращении к полю текст парсится заново. Используется только если нужно сохранить исходный формат документа (например, для аудита или когда порядок ключей семантически важен).

jsonb парсит документ при записи и хранит бинарное представление. Ключи сортируются, дубликаты удаляются (берётся последнее значение), пробелы не сохраняются. Поддерживает GIN-индексы и операторы containment. Почти всегда лучший выбор.

GIN-индексы для jsonb

-- Общий GIN индекс — поддерживает @>, ?, ?|, ?&
CREATE INDEX idx_events_payload_gin
    ON events USING GIN (payload);

-- jsonb_path_ops — только @>, но меньше размер индекса (быстрее поиск)
CREATE INDEX idx_events_payload_path
    ON events USING GIN (payload jsonb_path_ops);

-- Expression index для конкретного поля (поддерживает =, >, <)
CREATE INDEX idx_events_type
    ON events ((payload ->> 'type'));

-- Использование expression index:
SELECT * FROM events WHERE payload ->> 'type' = 'signup';
-- GIN через ->> НЕ работает, нужен именно expression index

Обновление jsonb

-- jsonb_set: обновить конкретное поле (create_missing = true добавит ключ)
UPDATE events
SET payload = jsonb_set(payload, '{status}', '"processed"', true)
WHERE event_id = 42;

-- || : merge двух jsonb (правый перезаписывает ключи левого)
UPDATE events
SET payload = payload || '{"processed_at": "2024-01-15"}'::jsonb
WHERE event_id = 42;

-- - : удалить ключ
UPDATE events
SET payload = payload - 'temp_field'
WHERE event_id = 42;

Подводные камни

• GIN-индекс не ускоряет ->> фильтры вида WHERE payload ->> 'status' = 'active' — для этого нужен отдельный expression index по (payload ->> 'status').
• Обновление любого поля jsonb документа перезаписывает всю строку — частые точечные UPDATE создают много dead tuples и увеличивают нагрузку на VACUUM.
• json с дублирующимися ключами не вызывает ошибку, но при конвертации в jsonb дубликаты молча удаляются — это может привести к потере данных при миграции.
• Отсутствие ключа и null — разные вещи в jsonb: оператор ? проверяет наличие ключа, а не его значение.
• jsonb не сохраняет порядок ключей — если приложение зависит от порядка (например, сериализует обратно и сравнивает строки), нужен json.
• Большие jsonb документы (>8kB) могут храниться через TOAST — это добавляет косвенный I/O при доступе к ним.
• jsonb не следует использовать вместо нормальных столбцов для данных, по которым нужны JOIN, foreign key constraints или агрегации — RDBMS не умеет строить статистику по внутренним ключам jsonb так же, как по обычным столбцам.
• Оператор @> с GIN индексом не работает через json_path_ops для массивов с вложенными объектами — нужно тестировать на реальных данных через EXPLAIN ANALYZE.

• Хранить всю предметную модель в jsonb.
• Ожидать индекс по любому JSON-выражению автоматически.
• Путать -> и ->>.

• Просит объяснить @>.
• Уточняет индекс для payload ->> 'email'.
• Проверяет trade-off между гибкостью и constraints.