Объяснение JSONB, представленное PostgreSQL

Во-первых, hstore является модулем Contrib, который позволяет хранить пары key = > value, где ключи и значения могут be text (однако значения могут быть также sql NULL).

Оба json и jsonb позволяют хранить допустимое значение JSON (определенное в , {"foo":"bar","baz":[null]} - hstore - это всего лишь небольшое подмножество по сравнению с тем, что JSON способно (но если вам нужно только это подмножество, это нормально).

Единственное различие между json и jsonb заключается в их хранении:

• json хранится в текстовом формате, а
• jsonb хранится в двоичном представлении

Есть 3 основных последствия этого:

• jsonb обычно занимает больше места на диске, чем json (иногда нет)
• jsonb требуется больше времени для создания из своего входного представления, чем json Операции
• json занимают значительно больше времени, чем jsonb (и синтаксический анализ также должен выполняться каждый раз, когда вы выполняете некоторую операцию при значении json)

Когда jsonb будет доступен со стабильной версией, будут два основных варианта использования, когда вы можете легко выбрать между ними:

• Если вы работаете только с представлением JSON в своем приложении, PostgreSQL используется только для хранения и получения этого представления, вы должны использовать json.
• Если вы выполняете много операций над значением JSON в PostgreSQL или используете индексирование в каком-то поле JSON, вы должны использовать jsonb.

Peeyush:

Короткий ответ:

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

Для более длительного ответа вам нужно дождаться, когда я сделаю полную запись "HowTo" ближе к выпуску 9.4.

Простое объяснение различия между json и jsonb (оригинальным изображением PostgresProfessional):

SELECT '{"c":0,   "a":2,"a":1}'::json, '{"c":0,   "a":2,"a":1}'::jsonb;

          json          |        jsonb 
------------------------+--------------------- 
 {"c":0,   "a":2,"a":1} | {"a": 1, "c": 0} 
(1 row)

• json: текстовое хранилище "как есть"
• jsonb: нет пробелов
• jsonb: нет дубликатов ключей, последний ключ
• jsonb: ключи сортируются

Подробнее в речь видео и презентация слайд-шоу от разработчиков jsonb. Также они ввели JsQuery, pg.extension обеспечивает мощный язык запросов jsonb

• hstore - это скорее тип хранения "широкий столбец", это плоский (не вложенный) словарь пар ключ-значение, всегда хранимый в разумно эффективном двоичном формате (хеш-таблица, отсюда и название).
• json хранит документы JSON в виде текста, выполняет проверку, когда хранятся документы, и анализирует их на выходе, если это необходимо (например, для доступа к отдельным полям); он должен поддерживать всю спецификацию JSON. Поскольку весь текст JSON сохраняется, его форматирование сохраняется.
• jsonb выполняет быстрые вызовы по соображениям производительности: данные JSON анализируются на входе и сохраняются в двоичном формате, порядок клавиш в словарях не поддерживается, а также не дублируются. Доступ к отдельным элементам в поле JSONB выполняется быстро, так как он не требует разбора текста JSON все время. На выходе данные JSON восстанавливаются и исходное форматирование теряется.

IMO, нет существенных причин не использовать jsonb после его доступности, если вы работаете с машиносчитываемыми данными.

Я был в pgopen, сегодня тесты быстрее, чем mongodb, я считаю, что это было примерно на 500% быстрее для выбора. Практически все было быстрее, по крайней мере, на 200%, если сравнивать с mongodb, чем одно исключение прямо сейчас - это обновление, которое требует полного переписывания всей колонки json, которую лучше обрабатывает mongodb.

Индексирование джина на jsonb звучит потрясающе.

Также postgres будут сохранять типы jsonb внутри и в основном соответствовать этим типам, таким как числовые, текстовые, логические и т.д.

Объединение также возможно с помощью jsonb

Добавьте PLv8 для хранимых процедур, и это будет в основном мечтой для разработчиков node.js.

Будучи сохраненным как двоичный jsonb, он также удаляет все пробелы, меняет порядок свойств и удаляет повторяющиеся свойства, используя последнее свойство свойства.

Помимо индекса, когда запрос на столбец jsonb, противоположный столбцу json postgres, не должен фактически запускать функциональные возможности для преобразования текста в json в каждую строку, которая, скорее всего, сэкономит огромное количество времени.

Насколько я могу судить,

• hstore, поскольку он в настоящее время существует (в Postgresql 9.3) не позволяет вложить другие объекты и массивы в качестве значений его пар ключ/значение. однако будущий патч hstore позволит вложенности. этот патч не будет в выпуске 9.4 и не может быть включен в ближайшее время.

• json, поскольку он в настоящее время существует, разрешает вложение, но основан на тексте и не позволяет индексировать, поэтому он "медленный"

• jsonb, который будет выпущен с 9.4, будет иметь текущие возможности вложения json, а также индексирование GIN/GIST hstore, поэтому оно будет быстрым

Люди, работающие над postgresql 9.4, похоже, говорят, что новый быстрый тип jsonb понравится людям, которые предпочли бы использовать хранилище данных noSQL, такое как MongoDB, но теперь могут комбинировать реляционную базу данных с неструктурированными данными, одна крыша

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

Тесты postgresql 9.4 jsonb кажутся на одном уровне с или в некоторых случаях быстрее, чем MongoDB

http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb

JSONB является "лучшей" версией JSON. Давайте проверим на примере.

1. JSON хранит пробелы, поэтому мы можем видеть пробелы, когда хранится ключ "a", а JSONB - нет.
2. JSON хранит все значения ключа. По этой причине вы можете видеть несколько значений (2 и 1) для клавиши "а", в то время как JSONB только "хранит" последнее значение.
3. JSON поддерживает порядок, в котором элементы вставляются, а JSONB поддерживает "отсортированный" порядок.
4. Объекты JSONB хранятся в виде распакованного двоичного файла, в отличие от "необработанных данных" в JSON, где повторный анализ данных не требуется во время поиска.
5. JSONB также поддерживает индексирование, что может быть существенным преимуществом.

В общем, следует отдавать предпочтение JSONB, если только нет особых потребностей, таких как устаревшие предположения о порядке расположения ключей объекта.

Другое важное отличие, которое не упоминалось ни в одном ответе выше, заключается в том, что для json типа нет оператора равенства, но есть для jsonb.

Это означает, что вы не можете использовать DISTINCT ключевое слово при выборе этого json -type и/или другие поля из таблицы (вы можете использовать DISTINCT ON вместо этого, но это не всегда возможно из - за случаев, как это).