Почему 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 | #практика 
