В чем разница между JSON и JSONB в PostgreSQL и когда их стоит использовать?

Question

В чем разница между JSON и JSONB в PostgreSQL и когда их стоит использовать?

Тип вопроса: Базы данных Вероятность: 10% Категория: Golang Разработчик

Ответ

Основное различие между JSON и JSONB в PostgreSQL заключается в способе хранения данных, что напрямую влияет на производительность и возможности.

JSON

Хранение: Хранит точную текстовую копию входных данных.
Плюсы: Очень быстрая вставка, так как не требует парсинга. Сохраняет все пробелы, порядок ключей и дубликаты ключей.
Минусы: Медленная обработка и поиск. Каждая операция требует повторного парсинга текста. Не поддерживает расширенное индексирование.

JSONB (JSON Binary)

Хранение: Хранит данные в разобранном двоичном (бинарном) формате.
Плюсы: Значительно более эффективная обработка и поиск данных внутри JSON-документа. Поддерживает GIN-индексы, что кардинально ускоряет запросы.
Минусы: Немного более медленная вставка из-за необходимости преобразования текста в бинарный формат. Не сохраняет пробелы, порядок ключей и удаляет дубликаты (оставляя только последнее значение).

Когда что использовать?

Почти всегда следует предпочитать JSONB.

Используйте JSONB в следующих случаях:

Хранение полуструктурированных данных: Пользовательские настройки, метаданные, логи, атрибуты товаров, где схема может меняться.
Необходимость индексации и быстрого поиска: Если вам нужно эффективно запрашивать данные по ключам или значениям внутри JSON.
Частичные обновления: Когда нужно изменять отдельные поля в большом JSON-документе, не перезаписывая его целиком.

Когда можно использовать JSON? Крайне редко. Основной сценарий — когда вам нужно хранить JSON как есть, с сохранением исходного форматирования, пробелов и порядка ключей, и вы не планируете активно запрашивать данные внутри этих JSON-документов.

Пример с `JSONB` и индексацией

-- Создание таблицы с полем JSONB
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    data JSONB
);

-- Создание GIN-индекса для ускорения запросов
CREATE INDEX idx_products_data ON products USING GIN (data);

-- Вставка данных
INSERT INTO products (data) VALUES
('{"name": "Laptop", "tags": ["electronics", "sale"], "specs": {"ram": 16, "cpu": "i7"}}'),
('{"name": "Mouse", "tags": ["electronics", "accessories"], "specs": {"dpi": 1200}}');

-- Эффективный поиск по тегу 'sale'
SELECT id, data->>'name' AS product_name
FROM products
WHERE data @> '{"tags": ["sale"]}'; -- Оператор @> использует GIN-индекс

Вывод: Для большинства бэкенд-задач JSONB является правильным выбором из-за его производительности и возможностей индексации.

Ответ 18+ 🔞

А, ну вот, опять про эти ваши JSON и JSONB, блядь! Сидишь такой, думаешь — ну что за хуйня, в чём разница-то? А разница, сука, как между сырым мясом и котлетой, ёпта!

JSON — это как засушенный гербарий, блядь.

Хранится: Точь-в-точь как ты всунул — со всеми пробелами, порядком ключей и даже если ключи повторяются, как идиот, два раза написал. Текстовая копия, сука!
Плюсы: Засунуть в базу — раз плюнуть. Не парсится ни хуя, тупо пихается как есть. Быстро, блядь!
Минусы: А вот чтобы что-то найти внутри или обработать — это пиздец, товарищ. Каждый раз этот текст заново разбирать надо. И индексы на него нормальные не повесишь, нихуя.

JSONB (Binary) — это уже готовая котлета, которую можно жрать.

Хранится: Внутри уже разобранная, понятная для машины бинарная хуйня.
Плюсы: Искать, фильтровать, обновлять кусочки — овердохуища быстрее! Поддерживает эти ваши GIN-индексы, которые всё ускоряют до неприличия.
Минусы: Ну, вставить чутка медленнее, потому что надо из текста в бинарник перевести. И всё лишнее — пробелы, порядок, дубликаты ключей — нахуй выбрасывает. Хранит только суть, блядь.

Так когда что брать, а?

В 99.9% случаев бери JSONB и не еби мозг!

Тащи JSONB сюда, если:

Данные полуструктурированные, как бардак в твоей комнате: Настройки пользователей, метаданные, логи, какие-то дополнительные атрибуты товаров — там, где схема может плавать, как говно в проруби.
Нужно быстро искать внутри: Если тебе надо эффективно выцепить, скажем, все товары с тегом "распродажа" из этого JSON-месива.
Обновлять по кусочкам: Чтобы не перезаписывать весь здоровенный документ, а только одно поле поменять.

А JSON — это для редких извращенцев. Только если тебе реально, блядь, позарез нужно сохранить точный вид исходного JSON — со всеми отступами, порядком и прочей ерундой. И при этом ты вообще не собираешься внутри этого добра искать. Сценарий, конечно, пиздец какой-то узкий, но бывает и такое, ёпта.

Живой пример, чтобы понятно было

-- Создаём табличку для товаров
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    data JSONB -- Вот наш герой, JSONB!
);

-- Вешаем волшебный GIN-индекс, чтобы летало
CREATE INDEX idx_products_data ON products USING GIN (data);

-- Пихаем данные
INSERT INTO products (data) VALUES
('{"name": "Ноутбук", "tags": ["электроника", "распродажа"], "specs": {"ram": 16, "cpu": "i7"}}'),
('{"name": "Мышь", "tags": ["электроника", "аксессуары"], "specs": {"dpi": 1200}}');

-- Ищем всё, что на распродаже, БЫСТРО, благодаря индексу!
SELECT id, data->>'name' AS product_name
FROM products
WHERE data @> '{"tags": ["распродажа"]}';

Короче, вывод простой, как три копейки: Для нормальной работы в бэкенде — JSONB, и точка. А JSON оставь для музея или для каких-то совсем уж конченых архивных задач, где важна именно текстура, а не содержание.