Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе.
Рубрика «lz4»
Как не получилось сделать PostgreSQL лучше (и почему это нормально)
2025-11-10 в 11:01, admin, рубрики: b-tree индекс, lz4, pglz, postgresql, wal, синхронная репликацияСжатие графики при помощи алгоритма LZ4
2024-12-18 в 8:00, admin, рубрики: lz4, whoosh, анимации, графика, дисплей, изображения, микроконтроллер, микроконтроллеры, сжатие данных, сжатие изображенийСодержание
-
Введение
-
Постановка задачи
-
Дисплей
-
Процесс отрисовки изображений
-
Память
-
-
Выбор алгоритма сжатия
-
Как работает LZ4?
-
LZ4 Block format
-
LZ4 Frame format
-
-
Так сжимались данные
-
Какой формат выбрать?
-
Разработка протокола хранения данных
-
-
Результаты
Введение
Привет! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании Whoosh. Мы в embedded-команде не только переливаем биты из одного регистра в другой, но и решаем разные бизнес-задачи. Иногда попадаются головоломки.
Почему uBlock Origin лучше работает в Firefox
2021-04-22 в 6:30, admin, рубрики: chromium, DNS, Firefox, Google Chrome, HTML-фильтры, indexeddb, lz4, uBlock Origin, webassembly, WebRequest.filterResponseData, Блог компании VDSina.ru, блокировщик рекламы, браузеры, запись CNAME, клоакинг CNAME, Расширения для браузеров
Автор uBlock Origin и uMatrix Реймонд Хилл обновил памятку, почему расширение uBlock Origin наиболее эффективно работает в браузере Firefox. Некоторые технические детали относятся не только к uBO, но и к другим блокировщикам рекламы.
Реймонд Хилл называет несколько основных факторов: более эффективное вскрытие маскировки CNAME, HTML-фильтрация, поддержка WebAssembly, более корректная процедура запуска браузера, сжатие LZ4 и надёжно отключённый префетчинг ресурсов. Всё это есть в Firefox, но отсутствует или глючит в браузерах на основе Chromium.
Читать полностью »
How to speed up LZ4 decompression in ClickHouse?
2019-06-25 в 14:42, admin, рубрики: bayesian optimization, big data, c++, clickhouse, data compression, databases, highload, lz4, lz77, open source, performance, Блог компании Яндекс, высокая производительностьWhen you run queries in ClickHouse, you might notice that the profiler often shows the LZ_decompress_fast function near the top. What is going on? This question had us wondering how to choose the best compression algorithm.
ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.
So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.
Читать полностью »
Как ускорить разжатие LZ4 в ClickHouse
2019-05-21 в 11:14, admin, рубрики: bayesian optimization, big data, c++, clickhouse, highload, lz4, lz77, open source, performance, базы данных, Блог компании Яндекс, высокая производительность, сжатие данныхПри выполнении запросов в ClickHouse можно обратить внимание, что в профайлере на одном из первых мест часто видна функция LZ_decompress_fast. Почему так происходит? Этот вопрос стал поводом для целого исследования по выбору лучшего алгоритма разжатия. Здесь я публикую исследование целиком, а короткую версию можно узнать из моего доклада на HighLoad++ Siberia.
Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.
Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.
Как я писал LZ4 плагин компрессии для Reiser4
2013-06-13 в 16:12, admin, рубрики: linux, lz4, reiser4, метки: linux, lz4, reiser4 
Объяснять что такое Reiser4 и с чем его едят я не буду, т. к. на этот счет достаточно информации [1, 2] и повторять её я не вижу смысла. Поэтому начну пожалуй с того, что Reiser4 я решил опробовать в 2010 году, но из-за проблем с использования прозрачной компрессии совместно с упаковкой хвостов (как оказалось были проблемы в flush процедуре, которые на данный момент решены[3]) перешел обратно на ReiserFS. В 2013 году я узнал о том, что эта проблема решена [4] и я снова вернулся на Reiser4 (LZO1 на стационарной системе, на ноутбуке без сжатия). Через какое-то время я вспомнил про новости о «Чрезвычайно быстром алгоритме сжатия» LZ4, а так-же о том, что комьюнити Illumos добавило поддержку оного в ZFS. Тут меня посетила мысль: «А было-бы здорово будь в Reiser4 поддержка LZ4»! Вот я и начал «приделывать» его к Reiser4.
Читать полностью »