Привет, Хабр!
Меня зовут Антон Виноградов, я Java developer в СберТехе, работаю в команде Platform V DataGrid — распределенной базы данных, основанной на Apache Ignite. Я реализовал альтернативный «ванильному» вариант сжатия данных в нашем продукте и хочу рассказать, какие особенности позволили превзойти оригинал.
В начале 2020 года мои коллеги уже рассказывали, как и зачем было организовано сжатие данных в Apache Ignite.
Сжатие данных в Apache Ignite
Кратко напомню, как мы сжимали данные раньше:
Cжатие данных производилось только на диске.
Специально увеличенные в размере страницы, занимающие несколько блоков файловой системы, например, размером в 16 Кб (4 x 4 Кб), при записи в хранилище сжимались до меньшего числа блоков файловой системы, например, до 12 Кб, 8 Кб или даже 4 Кб. Это происходило за счет использования файловых систем с разреженными файлами. При этом постраничная индексация прекрасно продолжала работать за счет того, что с точки зрения приложения страницы не изменяли свой размер.
Помимо этого, страницы сжимались и при записи в WAL, но уже без соблюдения кратности по отношению к блоку файловой системы, например, с 16 Кб до 5 Кб.
Однаĸо в WAL по-прежнему записывались:
несжатые дельты страниц (Δ), которые записываются вместо полной страницы при повторной записи в одну и ту же страницу в рамках одного чекпоинта;
несжатые логические записи (op), требующиеся для восстановления консистентности распределенной базы данных.
В итоге у нас появлялась возможность хранить больше данных на диске, но никаких других бонусов при этом мы не получали. И это подтолкнуло нас к реализации альтернативного подхода к сжатию данных, где решались бы и другие значимые для нас проблемы.
Альтернатива
В противоположность описанному варианту мы придумали сжимать отдельные записи в памяти:
В результате на страницах помещается больше данных:
Записываем на диск меньшее число страниц:
В итоге и в памяти, и на диске храним больше данных, а в WAL пишем заметно меньше:
Нажми, чтобы сравнить с тем как было раньше
Страницы в WAL продолжают сжиматься, как и в первом описанном варианте, но сжимаются не с 16 Кб до 5Кб, а с 4 Кб до 2 КБ; записать 2 Кб — значительно быстрее, чем 5 Кб.
Логические записи в WAL (op), как и дельты страниц (Δ), теперь меньше благодаря тому, что значения уже сжаты при первоначальной записи в память.
Как следствие, в WAL пишем меньше, чем в любом другом варианте со сжатием и без.
Данные на диске не так хорошо сжимаются, как в первом варианте, но зато сжимаются в памяти. А чем больше данных вмещается в память, тем позже наступает Page Replacement — механизм, который при переполнении памяти подгружает нужную страницу с диска, заменяя ею менее востребованную. Уже начавшийся Page Replacement приводит к значительной дергадации быстродействия, поэтому минимизация этого риска — очень важный бонус.
Чего мы добились в итоге
Мы сравнили оба варианта сжатия — «ванильный» сценарий сжатия страниц на дисĸе и наш новый сценарий сжатия значений в памяти.
Мы добавляли данные в пропорции 1:4 к их чтению.
Использовали алгогитм сжатия SNAPPY.
Комбинировали размер страницы (4 Кб, 8 Кб и 16 Кб) и различные подходы к сжатию (None — без сжатия, Value — сжатие значений, Page — страниц, WAL — журнала изменений).
Использовали данные в формате: Ключ — Integer, Значение — String (размером в 1 Кб, сжимаемая до ~380 байт).
И получили следующие результаты:
1) При использовании нового подхода к сжатию уменьшается потребление памяти, что и было первоначальной целью. Это увеличивает зазор до Page Replacement.
2) Неплохое сжатие данных на диске — очень приятный бонус к первоначальной цели.
3) Невероятное уменьшение размеров WAL — неожиданный бонус, проявившийся именно на бенчмарках и кратно повышающий итоговую ценность решения.
4) Ускорение операций — следствие третьего пункта. Меньше пишем — быстрее работаем.
Даже на крутых SSD есть выигрыш по latency по отношению к любым другим вариантам:
На дисках похуже отрыв будет больше:
На дисĸе со «шпинделем» отрыв, по нашим предположениям, должен быть просто колоссальным.
Выводы
1) Сжатие значений в памяти не так эффективно, как сжатие целых страниц на диске «на бумаге», но кратно превосходит его в эффективности на реальных замерах.
Происходит это благодаря дополнительному сжатию WAL и использованию страниц меньшего размера. Грубо говоря, WAL сжимается максимально эффективно, уменьшаются все виды записей, содержащие данные. Это перевешивает тот факт, что сжатие целых страниц эффективнее сжатия отдельных значений.
И самое главное, мы достигаем первоначальной цели — уменьшения рисков неожиданной деградации системы из-за переполнения памяти и начавшегося Page Replacement.
2) Сжимать данные полезно не только для экономии места, но и для ускорения быстродействия системы.
Чем меньше вы пишете на диск, тем быстрее будут выполняться ваши операции записи. Следовательно, тем быстрее будут происходить и чтения, которые ждут своей очереди в thread pools.
WAL мы вынуждены писать синхронно. Чем больше записываем в WAL, тем хуже latency. Меньше всего в WAL (за весь бенчмарк) мы пишем при использовании нового сценария — 1,3 Гб против 2,6 Гб в старом.
3) Если ваша основная цель — минимизация объема содержимого на диске при малом числе операций записи (при околонулевой генерации WAL) и время выполнения операций чтения для вас не критично, то вам следует рассмотреть вариант использования «сжатия страниц на диске». При использовании старого сценария хранилище занимает 0,3 Гб против 0,5 Гб в новом.
