PostgreSQL 9.2 вышел 10 сентября, и главная новость для архитекторов данных – встроенный тип json. Последние два года команды бросались к MongoDB и CouchDB ради гибкой схемы и хранения документов. Теперь реляционная СУБД предлагает то же самое, не теряя транзакций, внешних ключей и SQL. Для корпоративных и государственных систем это меняет расчёт «брать ли отдельную NoSQL-базу».

Что именно появилось в 9.2

Тип json валидирует структуру при вставке: кривой документ в таблицу не попадёт. Это уже отличает Postgres от схемы «храним строку и надеемся». Вытаскивать поля из документа можно функциями вроде json_each и row_to_json – последняя собирает результат запроса прямо в JSON, удобно отдавать веб-клиенту без промежуточного слоя.

Не менее важны вещи без слова JSON в названии. Index-only scans отдают данные прямо из индекса, не трогая таблицу, – типовые отчётные запросы ускоряются в разы. Каскадная репликация снимает нагрузку с мастера: реплика может кормить другие реплики. Для системы, где сотни тысяч граждан одновременно читают одни и те же данные, это прямой путь масштабировать чтение без шардинга.

Честно о границах. В 9.2 JSON хранится как текст, разбор идёт при каждом обращении, а индексировать отдельные поля документа штатно нельзя – только через функциональные индексы поверх выражений. Бинарного представления и операторов поиска по документу пока нет. Это первый шаг, а не паритет с документными базами.

Когда это снимает вопрос об отдельной NoSQL

Большинство проектов берут MongoDB не ради распределённости, а ради удобства: гибкая схема, документ как единица хранения, JSON по проводу. Если объёмы укладываются в один сервер с репликами – а это подавляющее число корпоративных и ведомственных задач, – Postgres 9.2 закрывает эти потребности и оставляет транзакции и целостность. Анкеты, заявления, журналы событий, настройки с переменным набором полей ложатся в json-колонку рядом со строго типизированными атрибутами в той же таблице.

Распределённость – отдельный разговор. Кто упёрся в горизонтальное масштабирование записи, смотрит в сторону систем вроде той, что недавно описала Google в статье про распределённую СУБД Spanner. Это другой класс задач и другой бюджет. Большинству он не нужен.

Что это значит для госсектора и enterprise

Меньше технологий в стеке – меньше точек отказа, проще аудит и аттестация. Одна СУБД вместо реляционной плюс документной упрощает резервное копирование, разграничение доступа и защиту персональных данных по 152-ФЗ. Для систем с высокими требованиями к доступу – порталов вроде описанного нами защищённого портала для выборов – единая транзакционная база предсказуемее связки разнородных движков.

JSON в Postgres хорошо стыкуется и с аналитикой: сырые полуструктурированные данные кладутся как есть, а разбираются в витрины запросами. Это разумная отправная точка перед тем, как строить тяжёлый контур обработки, о котором мы писали в материале про большие данные для бизнеса. Дальше всё упирается в проектирование схемы, нагрузочных сценариев и репликации под конкретную нагрузку.

Вывод

PostgreSQL 9.2 не отменяет NoSQL, но забирает у него самый частый сценарий – гибкое хранение документов на одном узле. Прежде чем заводить вторую СУБД, проверьте, не решает ли задачу json-колонка в той, что у вас уже есть. Чаще всего решает.