Недавно мы выложили на GitHub ZSON. ZSON — это расширение к PostgreSQL для прозрачного сжатия JSONB-документов. Сжатие осуществляется путем выделения строк, наиболее часто встречающихся в ваших документах, и построения словаря с этими строками. Притом строки могут быть не только ключами документа, но и значениями или, например, строками из вложенных массивов. В некоторых случаях ZSON позволяет уменьшить размер базы до двух раз и увеличить количество транзакций в секунду на 10%. В shared buffers документы хранятся в сжатом виде, за счет чего память тоже экономится.
Интересно? Читайте дальше, и вы узнаете, как пользоваться всем этим хозяйством на практике.
Замечания
Прежде, чем перейти к основному содержимому статьи, хочется отметить несколько моментов:
- Бенчмарк ZSON'а в данной статье не приводится. Заинтересованные читатели могут ознакомиться с ним здесь. Примите во внимание, что на практике все очень сильно зависит от ваших данных, конфигурации, железа, версии СУБД и других факторов. Не верьте синтетическим бенчмаркам, проверяйте все самостоятельно!
- Вопрос написания расширений для PostgreSQL выходит за рамки этой статьи. Заинтересованные читатели могут ознакомиться с отдельной статьей по данной теме, и далее по ссылкам. Тому, как ZSON работает внутри, если это кому-то интересно, я могу посвятить отдельную статью.
- PostgreSQL имеет встроенный алгоритм сжатия — PGLZ. ZSON не заменяет, а дополняет его. PGLZ сжимает каждый документ в отдельности. Он не может обнаружить, что в разных документах встречаются одни и те же строки. ZSON находит эти строки и заменяет их на 16-и битовые коды. Затем документы сжимаются PGLZ, как обычно (или не сжимаются, если итоговый документ маленький и/или не жмется).
Установка
Сборка ZSON из исходников и его установка осуществляются так:
git clone https://github.com/afiskon/zson.git
cd zson
sudo make install
После установки прогоните тесты:
make installcheck
Включите ZSON для вашей базы данных:
create extension zson;
Поздравляю, ZSON установлен!
Удаление
Когда и если вы захотите удалить ZSON, просто выключите его:
drop extension zson;
А затем совсем выпилите из PostgreSQL:
sudo make uninstall
Все созданные ZSON'ом типы, таблицы и так далее, будут вычищены автоматически.
Использование
Первым делом вы должны обучить ZSON на ваших типичных документах. В результате обучения строится словарь с наиболее часто встречающимися в ваших документах строками, который потом используется для сжатия. Обучение происходит с помощью следующей процедуры:
zson_learn(
tables_and_columns text[][],
max_examples int default 10000,
min_length int default 2,
max_length int default 128,
min_count int default 2
)
Например:
select zson_learn('{{"table1", "col1"}, {"table2", "col2"}}');
Посмотреть получившийся в итоге словарь можно так:
select * from zson_dict;
Теперь вы можете использовать ZSON, как прозрачную замену типа JSONB:
zson_test=# create table zson_example(x zson);
CREATE TABLE
zson_test=# insert into zson_example values ('{"aaa": 123}');
INSERT 0 1
zson_test=# select x -> 'aaa' from zson_example;
-[ RECORD 1 ]-
?column? | 123
Все операторы и процедуры будут работать с ZSON точно так же, как и с JSONB.
Миграция на новый словарь
По мере изменения схемы ваших документов сжатие может стать неэффективным из-за исчезновения одних строк и появления других. В этом случае вы можете переобучить ZSON на новых данных:
select zson_learn('{{"table1", "col1"}, {"table2", "col2"}}');
При этом создается новая версия словаря. При обновлении и создании новых документов они будут сжиматься с его помощью. Старые документы будут разжиматься с помощью той версии словаря, с которой они были сжаты. Обратите внимание, что словари кэшируются в памяти. Поэтому ZSON узнает о новом словаре не сразу, а спустя примерно минуту после его создания.
Определить, с помощью какой версии словаря был сжат конкретный документ, можно при помощи процедуры zson_info:
zson_test=# select zson_info(x) from test_compress where id = 1;
-[ RECORD 1 ]---------------------------------------------------
zson_info | zson version = 0, dict version = 1, ...
zson_test=# select zson_info(x) from test_compress where id = 2;
-[ RECORD 1 ]---------------------------------------------------
zson_info | zson version = 0, dict version = 0, ...
Если вы абсолютно уверены, что все документы в вашей базе сжаты с помощью новой версии словаря, вы можете безопасно удалить старый словарь:
delete from zson_dict where dict_id = 0;
На практике, впрочем, в этом мало смысла. Вы сэкономите лишь пару килобайт места на диске. Параноик внутри меня считает, что риск потерять данные из-за маааленькой невнимательности того не стоит.
Как понять, что нужно обновить словарь?
К сожалению, трудно рекомендовать универсальный подход. Например, вы можете время от времени проверять средний размер документа в вашей базе:
select pg_table_size('tt') / (select count(*) from tt)
Если он стал увеличиваться, значит пришло время обновиться словарь. Еще можно переучивать ZSON просто время от времени, например, раз в год.
Наконец, разработчики приложения сами знают, когда они сильно меняют схему документов. Можно включить переобучение ZSON в миграционные скрипты или инструкцию по обновлению приложения.
При сильном желании можно придумать и другие подходы. В общем, все сильно зависит от ситуации.
Заключение
Как видите, благодаря ZSON вы получаете лучшее из двух миров — гибкость schemaless данных, совмещенную с компактностью реляционной модели. При этом на стороне приложения вообще ничего не нужно делать, все происходит прозрачно, на стороне самой СУБД.
Если у вас есть вопросы, я буду рад ответить на них в комментариях. Любой фидбек, а также pull requests горячо приветствуются.
Комментарии (30)
tsabir
07.10.2016 22:10+1Не могу понять, что нужно передавать в
tables_and_columns
? Если это названия таблиц и колонок в них, то пример{{'table1', 'row1'}, ...}
не совсем удачный. Может лучше{{'table1', 'col1'}, ..}
? Поясните пожалуйста.
Ranckont
10.10.2016 14:08А как лучше содержимое zson_learn перенести с тестовой на продуктивную БД?
afiskon
10.10.2016 14:08Да как вам удобнее так и переносите. Через COPY например.
Ranckont
10.10.2016 14:16А проблем с какими-нибудь zson version/dict version или id, не будет?
afiskon
10.10.2016 14:32Если вы не обучаете zson и на тестовом окружении и на проде одновременно, то проблем быть не должно. Иначе перед обучением на тестовом окружении сначала перенесите полностью словарь с прода.
И конечно же, на все всегда делайте бэкапы!Ranckont
10.10.2016 15:16Я так понял, что «My_schema».«Table» — работать не будет?
afiskon
10.10.2016 15:22Не уверен, что понял ваш вопрос. Если вы хотите включить расширение для схемы, то насколько я знаю, это работать не будет.
Ranckont
10.10.2016 15:26Ну да, не у всех в public данные.
А как прикрутить?afiskon
11.10.2016 10:58Вижу вы послали патч в ЛС. Я его замержил, спасибо!
Ranckont
11.10.2016 11:42Там надо ещё подумать над тем, что таблица public.zson_dict, становится частью данных другой схемы, что становится как-то неправильно.
Или принудительно её создавать в используемых схемах или как-то в документации отобразить.
Ranckont
10.10.2016 16:45Я думаю, можно вставить какой-нибудь шаблон, для исключения из словаря данных величин, которые будут заведомо единственные, скажем результат какой-либо последовательности.
Или потом удалить их словаря.
pasha_golub
В ваших тестах выключен автовакуум. Это умышленно? Есть проблемы с вакуумом у типа?
afiskon
Это умышленно, но не из-за проблем типа. Автовакуум на всех бенчмарках приводит к тому, что бенчмарк показывает не то, что вы думаете (работу автовакуума, а не тестируемого функционала). В теории автовакуум должен работать даже быстрее, так как размер туплов уменьшается и производится меньше дискового IO, но конкретных замеров я лично не делал.