The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Автор LZ4 представил новый быстрый и эффективный алгоритм сжатия ZSTD

25.01.2015 09:47

Ян Колле (Yann Collet), автор эталонной реализации алгоритма LZ4, представил новый алгоритм сжатия Z-standard (ZSTD), сочетающий высокую скорость кодирования и декодирования с хорошей эффективностью сжатия. Алгоритм предназначен для использования в повседневном обиходе, но он не рассчитан на достижение рекордных скоростей, свойственных LZ4, или максимальных уровней сжатия, обеспечиваемых в LZMA и ZPAQ. По сравнению с обеспечивающими рекордные показатели системами, предложенный алгоритм не является однобоким (скорость за счёт степени сжатия или степень сжатия за счёт скорости) и обеспечивает отличное соотношение скорости и эффективности сжатия. Библиотека с эталонной реализацией алгоритма распространяется под лицензией BSD.

Название Степень сжатия Скорость кодирования Скорость декодирования
MB/s MB/s
zlib 1.2.8 -6 3.099 18 275
ZSTD 2.872 201 498
zlib 1.2.8 -1 2.730 58 250
LZ4 HC r127 2.720 26 1720
QuickLZ 1.5.1b6 2.237 323 373
LZO 2.06 2.106 351 510
Snappy 1.1.0 2.091 238 964
LZ4 r127 2.084 370 1590
LZF 3.6 2.077 220 502

Скорость декодирования в ZSTD составляет примерно 500 Мб/сек на одном ядре процессора Intel Core i5-4300U (1.9 GHz) при скорости кодирования на уровне 200 Мб/сек, что позволяет использовать данный алгоритм в сценариях по обработке данных в режиме реального времени. Кроме того, как и в LZ4, для ситуаций, когда данные сжимаются один раз и многократно распаковываются, в ZSTD предусмотрен режим форсированного сжатия, при котором достигается более высокий коэффициент сжатия за счёт увеличения времени упаковки.

Примечательной особенностью ZSTD также является возможность настройки потребления памяти, что позволяет использовать ZSTD на встраиваемых системах с небольшим размером ОЗУ или на серверах, одновременно обрабатывающих большое число сжатых потоков. Для декодирования необходимо заполнение таблиц трансформации, размер которых может быть настроен от 2.5 до 20 Кб, а также требуется выделение памяти под буфер с окном сжатия, который по умолчанию составляет 512 Кб, но может быть по желанию уменьшен до нескольких килобайт или увеличен до гигабайт (чем больше размер окна - тем выше уровень сжатия). В процессе сжатия данных дополнительно требуется выделение памяти под буфер сортировки, который по умолчанию составляет 128 Кб, но может быть произвольно уменьшен или увеличен.

На приведённом ниже графике отражены параметры эксперимента по сжатию файла, передаче потока по сети и его распаковке на другом конце соединения. Первый график показывает соотношение времени выполнения операции (ось Y) к пропускной способности канала связи в Мб/сек (ось X). Второй график отличается тем, что вместо времени используется относительное ранжирование алгоритмов, при котором за 1 принят лучший результат, а остальные показатели показаны в процентном соотношении к нему.

По графику видно, что LZ4 остаётся лидером на скоростях выше 50 Мб/сек, а ZSTD демонстрирует лучшие результаты на скоростях от 0.5 Мб/сек до 50 Мб/сек.

  1. Главная ссылка к новости (http://fastcompression.blogspo...)
Лицензия: CC-BY
Тип: Интересно / Программы
Ключевые слова: compress, lz4, zstd
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Fracta1L (ok), 10:31, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    > он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4

    Наоборот же.

    Респект и уважуха автору, ждём поддержки в ядре и Btrfs.

     
     
  • 2.10, Аноним (-), 12:32, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А что ждать?
    svn co http://lz4.googlecode.com/svn/trunk/ .
    make -j 3
    sudo make install
    sudo modprobe lz4
    sudo modprobe lz4hc
    sudo update-initramfs -c -k 'uname -r' -u
    дописать в /etc/initramfs-tools lz4 и lz4hc

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
    patch -p1 < btrfs3.18.1-lz4.patch
    патч взять отсюда https://github.com/xbianonpi/xbian-patches/tree/master/btrfs-progs
    make -j 3
    sudo make install

    git clone https://github.com/pfactum/pf-kernel.git
    patch -p1 < lz4.patch
    патч взять отсюда https://github.com/xbianonpi/xbian-package-kernel/tree/master/patches/rpi-3.17
    make menuconfig  паковать ядро lz4
    make-kpkg clean
    sudo make-kpkg -j 3 --initrd --append-to-version=+ kernel_image kernel_headers
    sudo dpkg -i linux-header*.deb linux-kernel*.deb

     
     
  • 3.35, Аноним (-), 03:52, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А смысл этой возни? Там уже есть вполне сравнимый LZO, вот никто и не рвется особо имплементить еще 1 почти такой же алгоритм.
     
  • 3.40, Аноним (-), 11:49, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Почитай про checkinstall хотя бы, болезный.
     

  • 1.2, Аноним (-), 10:37, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    То есть алгоритм не годится ни для одной конкретной задачи)
     
     
  • 2.3, anon9 (?), 10:55, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Вполне себе годится: на моих данных (логи в JSON-формате) жмёт по объёму так же как gzip -6, но при этом в 7.6 раза быстрее. По-моему очень достойный результат
     
     
  • 3.12, funny_falcon (?), 13:56, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А lz4 как при этом жмёт? Т.е. понятно, что размер сжатого файла будет несколько больше, но на сколько? и во сколько раз быстрее он сожмёт?
     
     
  • 4.19, Stax (ok), 16:00, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по таблице вверху, lz4 сожмет не быстрее, а в несколько раз медленнее. И хуже. Но - разжиматься потом будет быстрее.
     
     
  • 5.22, tyuiop (?), 16:18, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Есть lz4 hc, и есть просто lz4. Вглядись.
     

  • 1.4, Baz (?), 11:35, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    алгоритм, который среднячек во всём.
     
     
  • 2.5, Tyuiop (?), 11:43, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?
     
     
  • 3.16, Аноним (-), 15:05, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?

    Жмем 7z или gz, а если сжимать не нужно - просто tar'им.
    Но я слышал что есть люди которые верят в бога и пользуются винраром.

     

  • 1.6, Аноним (-), 12:01, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    <сарказм>Все сжимаю в tar. Почему в тесте его нет?
     
     
  • 2.7, Michael Shigorin (ok), 12:07, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > <сарказм>Все сжимаю в tar.

    Научите!</сарказм>

     
     
  • 3.8, A.Stahl (ok), 12:13, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров.
     
     
  • 4.9, ALex_hha (ok), 12:20, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров.

    а сэкономишь аж 0,1%?

     
     
  • 5.11, Crazy Alex (ok), 13:21, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А теперь представь, что файлы по десятку байт и не неси фигню.
     
     
  • 6.13, Аноним (-), 14:33, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если это не FAT какой-нибудь, то данные короткого файла лежат в метаданных, вместе с прочими атрибутами. Не занимает он ни одного кластера.
     
     
  • 7.20, Crazy Alex (ok), 16:01, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Минимум - inode + directory record.
     
     
  • 8.21, Crazy Alex (ok), 16:06, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, в ext4 inline data - это экспериментальная фича В продакшне её нет ... текст свёрнут, показать
     
     
  • 9.23, tyuiop (?), 16:20, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А те, кто пользуются reiser3, используют notail Быстрее и стабильней ... текст свёрнут, показать
     
     
  • 10.27, Ne01eX (??), 19:39, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это для наоборот Опция даёт прирост в скорости в ущерб вместимости - 5 ... текст свёрнут, показать
     
     
  • 11.28, Ne01eX (??), 19:42, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, Reiser4 умеет танцевать деревья для экономии дискового пространства ... текст свёрнут, показать
     
     
  • 12.42, Stax (ok), 15:20, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Dancing Tree это как бы название структуры данных, а не танец каких-то други... текст свёрнут, показать
     
     
  • 13.52, Ne01eX (ok), 19:28, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо, кэп ... текст свёрнут, показать
     
  • 10.30, Crazy Alex (ok), 20:20, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А те, кто пользуются reiserfs - ищут грабли начиная с риска угробить ФС к черто... текст свёрнут, показать
     
     
  • 11.32, Ne01eX (??), 21:05, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Атомарная структура Reiser4 позволяет избежать рисков что-то прое бать при опера... текст свёрнут, показать
     
     
  • 12.33, Crazy Alex (ok), 22:05, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала - речь шла о reiserfs Сейчас вы говорите о reiser4 Reiser4 нет в яд... текст свёрнут, показать
     
     
  • 13.39, Ne01eX (??), 09:17, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хорошо, встанем тогда на том, что это хорошо когда у людей есть выбор, какой ФС ... текст свёрнут, показать
     
     
  • 14.41, Crazy Alex (ok), 15:20, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А тут и спорить не с чем Сейчас, насколько я понимаю, в моде экстенты, но, веро... текст свёрнут, показать
     
     
  • 15.49, Аноним (-), 02:48, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Есть небольшая разница Btrfs-ники могут внятно показать что это дает Ну там на... текст свёрнут, показать
     
  • 15.53, Аноним (-), 21:18, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проснись, тормоз В РСУБД экстенты в моде уже больше 30 лет - ты столько на свет... текст свёрнут, показать
     
  • 14.50, Аноним (-), 02:51, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он так отлажен, что разгром тома fsck ом при налете на неправильное дерево - k... текст свёрнут, показать
     
  • 9.36, Аноним (-), 03:53, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А в btrfs уже есть И сжатие ... текст свёрнут, показать
     
     
  • 10.54, Аноним (-), 21:18, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В ZFS это есть уже лет 8 ... текст свёрнут, показать
     
     
  • 11.56, AlexAT (ok), 21:45, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А системный кеш вместо собственного выноса там уже используется ... текст свёрнут, показать
     
     
  • 12.57, iZEN (ok), 01:12, 29/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Посчитай сам last pid 49014 load averages 0 30, 0 26, 0 25 up 0 06 04... текст свёрнут, показать
     
     
  • 13.58, AlexAT (ok), 08:28, 29/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не используется В топку ... текст свёрнут, показать
     
  • 5.14, Ня (?), 14:37, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже если результат меньше оригинала на два бита, то это уже сжатие.
     
  • 2.17, Аноним (-), 15:08, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > <сарказм>Все сжимаю в tar. Почему в тесте его нет?

    потому что он архиватор

     

  • 1.15, Аноним (-), 14:49, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ждем в 7зип ?
     
     
  • 2.29, Мандаринос (?), 19:55, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем он там, если lzma жмет эффективней при сравнимой скорости?
     
     
  • 3.59, Vic (??), 10:54, 09/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А можно подробнее про большую скорость lzma?
     

  • 1.18, Etch (?), 15:43, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X).

    Или по оси Y не время, а скорость, или получается что чем выше пропускная способность канала, тем дольше длится операция...

     
  • 1.34, AlexAT (ok), 23:19, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хотелось бы ZSTD в TokuDB увидеть... Самое оно.
     
     
  • 2.55, Аноним (-), 21:19, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотелось бы ZSTD в TokuDB увидеть... Самое оно.

    Хотелось? Возьми и запили. Делов-то.

     

  • 1.37, Анонимко (?), 08:28, 26/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в MySQL до сих пор только zlib, только в innodb и, по сути, размер всё равно больше, чем у несжатой myisam...
     
     
  • 2.38, AlexAT (ok), 08:46, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А в MySQL до сих пор только zlib, только в innodb и,
    > по сути, размер всё равно больше, чем у несжатой myisam...

    zlib в innodb не нужен, в innodb структура организована таким образом, что сжатие делает её совершенно неповоротливой при записи - она вся расчитана на страницы фиксированной и неизменной длины. Ну а myisam вообще пора запретить, как зло.

     
     
  • 3.43, Аноним (-), 18:32, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, и использовать двиг, который занимает в 7 раз больше места? ( http://www.percona.com/forums/questions-discussions/mysql-and-percona-server/ ). Боже упаси. Я не проверял, но что-то верится с трудом что innodb при таком оверхеде может быть быстрее myisam.
     
     
  • 4.46, AlexAT (ok), 20:36, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага, и использовать двиг, который занимает в 7 раз больше места? (

    Когда в первый раз попробуете "починить" (а падают myisam'ы при некорректной остановке mysqld влёт) таблицу размером хотя бы гиг в 20 - перескочите на innodb/tokudb быстро, и без шелеста :) Плюс нет поддержки транзакций совершенно, плюс полная блокировка при записи...

    Вообще таблица myisam в 50 Gb + 40 Gb индекса, доставшаяся от предшественника, в несжатом innodb заняла 75 - т.е. никаких "в 7 раз" не наблюдается. TokuDB+lzma уфигачил вместе с индексом в 25 гиг, при этом производительность как чтения, так и записи только выросли (да и нагрузка на CPU сильно не подскочила) :)

     
  • 3.51, Анонимко (?), 10:08, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я рад за вас, у меня таблицы при переводе на innodb разрастаются в 5 раз. Лично я по этому параметру вижу регресс, myisam по тестам оказывается гораздо быстрее. Еслиб еще к этому двигу прикрутили сжатие и построчную блокировку, - myisam бы обходил innodb на порядки.
    Транзакции, кстати, далеко не всем нужны.
     
  • 2.44, Аноним (-), 18:40, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Порекомендуйте идеальную СУБД?
     
     
  • 3.45, Мандаринос (?), 18:43, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не успел я написать слово "Oracle", как у моего комментария уже был минус :)
     
  • 3.47, AlexAT (ok), 20:38, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Порекомендуйте идеальную СУБД?

    Порекомендуйте идеальный автомобиль.

     
     
  • 4.48, Аноним (-), 02:34, 27/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Порекомендуйте идеальный автомобиль.

    Летающий DeLorian :).

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру