JSON агрегаты
Тема дорожной карты · PostgreSQL
PostgreSQL предоставляет богатый набор агрегатных функций JSON, позволяющих SQL-запросам собирать несколько строк реляционных данных и объединять их в единое значение JSON. Функции json_agg и jsonb_agg агрегируют весь столбец значений в массив JSON, тогда как json_object_agg и jsonb_object_agg строят объект JSON, используя столбцы ключа и значения из результата запроса. Эти JSON-агрегаты особенно мощны в сочетании с GROUP BY, позволяя PostgreSQL формировать вложенные JSON-структуры непосредственно из реляционной базы данных без какой-либо постобработки в коде приложения. Варианты jsonb хранят результат в двоичном формате JSON PostgreSQL, что поддерживает индексирование и ускоряет вычисление операторов в последующих запросах. JSON-агрегаты широко используются в бэкендах API для сериализации реляционных данных в JSON-ответы, ожидаемые клиентами.
Как это работает
JSON агрегаты делает 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.
Типичные ошибки
Ловушки JSON агрегаты: структурированные поля как JSONB "для гибкости" с запросами по каждому пути (нет enforce схемы, планировщик не видит реальную статистику); огромные JSONB-блобы (per-row TOAST), дорогие row update; нет GIN-индекса и жалобы что @> медленно; -> где нужен ->> (получаете JSON-quoted строки, не текст).