PostgreSQL JSONB: когда не нужна отдельная NoSQL-база
Прежде чем добавлять MongoDB или другое документное хранилище в стек, стоит проверить, что уже умеет JSONB в PostgreSQL - и где он объективно заканчивается.
Спор SQL против NoSQL идёт уже почти десятилетие. На практике у большинства команд, с которыми я работаю, нет нагрузки, которая требует чистой NoSQL-системы. Есть реляционная база с несколькими таблицами, где схема часто меняется или отличается от строки к строке. И для этой конкретной задачи тип колонки JSONB в PostgreSQL даёт практичный ответ начиная с версии 9.4.
Я не выступаю против документных баз. Для них есть реальные сценарии. Но добавление второй технологии баз данных в стек несёт реальную стоимость, и прежде чем её платить, стоит понять, что у вас уже есть.
Что на самом деле делает JSONB
JSONB хранит JSON как разобранную бинарную структуру, а не как сырую строку. Это значит, что PostgreSQL индексирует её, строит запросы внутрь неё и применяет стандартные SQL-функции. Можно писать запросы вроде «верни все строки, где в JSON-поле config есть "notify": true» - без загрузки и парсинга всего в коде приложения.
Для JSONB-колонок доступны GIN-индексы, что делает поиск внутри JSON-документов достаточно быстрым для большинства операционных нагрузок. Структурированные колонки и JSON-колонки можно смешивать в одной таблице и одном запросе.
Где это работает хорошо
По моему опыту, JSONB хорошо подходит для:
- Таблиц настроек и конфигурации, где у каждой строки разная форма.
- Таблиц событий и аудита, где payload различается по типу события, но нужны транзакционные гарантии.
- Точек интеграции, где вы получаете внешний JSON и хотите сохранить его с минимальной трансформацией, при этом сохраняя возможность делать запросы.
- Стадий прототипирования, где схема ещё не устоялась.
В каждом из этих случаев выигрыш - хранить всё в одной базе с единой моделью транзакций, единым режимом резервирования, единой операционной командой и единым пулом соединений.
Где он заканчивается
JSONB не заменяет специализированное документное хранилище, когда:
- Документы весят мегабайты каждый и нужны частичные обновления на уровне байтов.
- Шаблоны доступа исключительно документно-ориентированы и реляционные объединения не нужны никогда.
- Вам нужен конкретный агрегационный конвейер MongoDB или его нативная шардинговая модель.
- Команда глубоко знает MongoDB и совсем не знает PostgreSQL.
Последний пункт важнее, чем принято признавать. Выбор технологии должен соответствовать людям, которые её эксплуатируют, а не только результатам бенчмарков.
Решение, которое я на самом деле рекомендую
Прежде чем предлагать новую технологию базы данных, я задаю один вопрос: справится ли существующий PostgreSQL с этим через JSONB, и останется ли это читаемым и сопровождаемым? Если да - остаёмся в одной системе. Если ответ честно «нет» - иногда так бывает - тогда приносим специализированный инструмент.
Стоимость обслуживания двух технологий баз данных реальна: две стратегии резервирования, два набора операционных инструкций, две точки отказа для мониторинга и две предметные области, которые команда должна покрывать. Эта стоимость должна быть оправдана реальным требованием, а не предпочтением к более новому инструменту.