Почему JSONB в PostgreSQL не всегда быстрее JSON!

В PostgreSQL тип JSONB часто выбирают вместо JSON из-за возможности индексации и работы с операторами поиска. Но отличие между ними не только в скорости чтения — оно связано с тем, как PostgreSQL хранит, обрабатывает и изменяет данные.

Рассмотрим таблицу с JSONB-структурой:

CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    payload JSONB
);

Добавим документ с вложенными данными:

INSERT INTO events (payload)
VALUES (
    '{
        "user": {
            "id": 100,
            "role": "admin"
        },
        "active": true
    }'
);

При хранении JSONB PostgreSQL разбирает документ и сохраняет его во внутреннем бинарном представлении. Благодаря этому можно выполнять поиск по содержимому документа:

SELECT *
FROM events
WHERE payload @> '{"active": true}';

Оператор @> проверяет наличие указанного фрагмента внутри JSONB-объекта.

Для ускорения подобных запросов используется GIN-индекс:

CREATE INDEX idx_events_payload
ON events
USING GIN (payload);

После создания индекса PostgreSQL может выполнять поиск внутри JSONB-структуры без полного последовательного просмотра всех строк. Но у JSONB есть особенности, которые важно учитывать.

При изменении одного поля PostgreSQL не изменяет отдельный элемент внутри JSONB-документа. Из-за механизма MVCC создаётся новая версия строки с новым значением JSONB:

UPDATE events
SET payload = jsonb_set(
    payload,
    '{user,role}',
    '"moderator"'
)
WHERE id = 1;

Для небольших объектов это обычно не оказывает заметного влияния. Но большие JSONB-документы с частыми обновлениями могут увеличивать нагрузку на операции записи из-за необходимости создавать новые версии данных.

Ещё одно отличие связано с сохранением структуры документа. В типе JSON PostgreSQL сохраняет текстовое представление документа:

SELECT '{"b":2,"a":1}'::json;

В этом случае исходный порядок ключей сохраняется. JSONB хранит уже разобранную структуру документа:

SELECT '{"b":2,"a":1}'::jsonb;

В JSONB порядок ключей не сохраняется, поскольку PostgreSQL работает с внутренним структурированным представлением данных. Поэтому он лучше подходит для случаев, когда требуется поиск, индексация и работа с содержимым документа, а JSON — когда важно сохранить исходное представление данных.

Отдельно стоит учитывать особенности работы индексов. Например, запрос с извлечением значения через оператор ->> выглядит следующим образом:

SELECT *
FROM events
WHERE payload->>'active' = 'true';

А запрос с проверкой содержимого JSONB-объекта использует другой механизм доступа:

SELECT *
FROM events
WHERE payload @> '{"active": true}';

GIN-индекс эффективно работает с операторами JSONB, такими как проверка вхождения @>, проверка существования ключей ?, а также операторы проверки нескольких ключей ?| и ?&.

Однако GIN-индекс не ускоряет автоматически любые выражения с извлечением значений через ->>. Для таких случаев могут использоваться отдельные функциональные индексы.

Например, индекс для конкретного поля JSONB можно создать следующим образом:

CREATE INDEX idx_events_active
ON events ((payload->>'active'));

Если поле активно используется в фильтрации, сортировке или связях между таблицами, отдельная колонка часто будет эффективнее и проще для поддержки.

🔥 JSONB отлично подходит для хранения динамических структур, когда требуется гибкость схемы и возможность выполнять поиск по содержимому. Главное правило: JSONB — это инструмент для работы с полуструктурированными данными, а не способ заменить полноценную структуру реляционной базы данных.

➡️ SQL Ready | #практика