Операторы JSONB
Тема дорожной карты · PostgreSQL
PostgreSQL предоставляет богатый набор операторов JSONB, обеспечивающих выразительные и типобезопасные запросы к полуструктурированным документальным данным, хранящимся в столбце реляционной базы данных. Оператор -> извлекает поле объекта JSON по ключу и возвращает значение как JSONB (например, payload -> 'user'), тогда как оператор ->> возвращает то же значение как TEXT — это необходимо, когда извлечённое значение нужно сравнить со строковым литералом или привести к другому типу. Операторы #> и #>> позволяют перемещаться по вложенным путям с помощью массива строк — например, payload #>> '{user, address, city}' — тогда как @> (содержит) и <@ (содержится в) поддерживают семантику проверки вхождения множеств, ускоряемую GIN-индексом для оптимизации запросов по большим наборам данных JSONB. Дополнительные операторы JSONB включают || для объединения двух объектов JSONB, - для удаления ключа или элемента по индексу и #- для удаления вложенного пути, что делает операторы JSONB в PostgreSQL полноценным набором инструментов для создания гибких приложений реляционных баз данных, работающих с развивающимися JSON-схемами.
Как это работает
Операторы JSONB делает Postgres конкурентным document-store. JSONB бинарный, быстрее JSON для запросов, поддерживает GIN-индексы. Операторы: -> (поле как JSON), ->> (как текст), @> (containment), ? (ключ существует), #>> (глубокий путь как текст). jsonb_set/jsonb_insert мутируют; jsonb_agg/jsonb_object_agg агрегируют. GIN-индекс на JSONB-колонке делает containment-запросы быстрыми — обязателен для JSONB-фильтров.
Когда применять
JSONB — для semi-structured данных, форма которых меняется per row (config-блобы, audit-payload, third-party event body). Реляционные колонки + плотная схема — для предсказуемых форм; реляционные запросы в 5-10× быстрее JSONB на тех же данных при известной схеме. Не используйте JSONB как "schema escape hatch" — теряете constraint, foreign key, type-check.
Типичные ошибки
Ловушки Операторы JSONB: структурированные поля как JSONB "для гибкости" с запросами по каждому пути (нет enforce схемы, планировщик не видит реальную статистику); огромные JSONB-блобы (per-row TOAST), дорогие row update; нет GIN-индекса и жалобы что @> медленно; -> где нужен ->> (получаете JSON-quoted строки, не текст).