|
jsonb занимает намного больше места, чем json
|
|||
---|---|---|---|
#18+
На хабре пишут: авторТакже доступен тип JSONB — двоичная разновидность формата JSON, у которой пробелы удаляются, сортировка объектов не сохраняется, вместо этого они хранятся наиболее оптимальным образом , и сохраняется только последнее значение для ключей-дубликатов. JSONB обычно является предпочтительным форматом, поскольку требует меньше места для объектов , может быть проиндексирован и обрабатывается быстрее, так как не требует повторного синтаксического анализа. Берём пример из справки и проверям, кто занимает меньше места: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Да, jsonb незначащие пробелы игнорирует. Но места занимает намного больше, чем обычный json. Объяснить это можно метаданными, которые хранятся вместе с данными (длина строки, тип данных, формат чисел и т.д.). Плюс сами числа могут занимать больше байт, чем их строковое представление в json (например, само число 10 в json займёт 2 байта, в jsonb - 4 или 8). Получается, что экономнее хранить JSON-данные в формате json , а не jsonb : Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 02:36 |
|
jsonb занимает намного больше места, чем json
|
|||
---|---|---|---|
#18+
Cyrax_02, Это справедливо ровно до того момента когда вам надо какие то поля доставать из этого json(b) или какие то функции над ним из имеющихся только для jsonb вызывать (а там уже скорость работы сильно начинает отличатся). Ну и на 40 байтовых полях сравнивать странно, имеет смысл сравнивать на килобайтных и более json(b) где начинает сжатие включатся. ps: меньше читайте хабр и больше документацию официальную где про размер ничего не сказано. На практических json(b) какой то принципиальной разницы обычно нет. pps: а еще экономнее в bytea bzip2 с максимальным сжатием да ;). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 03:06 |
|
jsonb занимает намного больше места, чем json
|
|||
---|---|---|---|
#18+
авторЭто справедливо ровно до того момента когда вам надо какие то поля доставать из этого json(b) или какие то функции над ним из имеющихся только для jsonb вызывать (а там уже скорость работы сильно начинает отличатся).Обычно критическое значение играет скорость поиска (функциональный индекс по выражению json_field::jsonb ), а выборка, как правило, небольшая и более низкая скорость извлечения данных из формата json на общем времени выполнения запроса сколь-нибудь заметно не скажется. авторНу и на 40 байтовых полях сравнивать странно, имеет смысл сравнивать на килобайтных и более json(b) где начинает сжатие включатся... На практических json(b) какой то принципиальной разницы обычно нет.Но: 1 ) TOAST-сжатие будет применяться как к формату jsonb , так и к формату json . Т.е. TOAST-сжатие не даёт никаких преимуществ формату jsonb . 2 ) TOAST-сжатие бинарный формат jsonb будет сжимать слабее (т.к. там меньше повторяющихся байтов), а json - сильнее (больше повторяющихся символов) 3 ) На "килобайтных" json(b) с длинными строками преимущество формата json над jsonb уменьшится в относительных единицах, но сохранится в абсолютных единицах 4 ) Если JSON-данные состоят из большого количества полей без длинных строк, то преимущество формата json над jsonb останется таким же большим и в относительных, и в абсолютных единицах. Речь идёт о разнице в 45%, как показывает пример из 1-го топика. Т.е. формат json изначально занимет меньше места, чем jsonb . А со сжатием TOAST выигрыш ещё больше увеличится за счёт более сильного сжатия текстовой строки json , чем бинарной строки jsonb . авторpps: а еще экономнее в bytea bzip2 с максимальным сжатием да ;).Или deflate с общим словарём по всей БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 15:13 |
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1994410]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
316ms |
get topic data: |
9ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
others: | 335ms |
total: | 735ms |
0 / 0 |