forum.opennet.ru - "Автор LZ4 представил новый быстрый и эффективный алгоритм сж..." (56)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Автор LZ4 представил новый быстрый и эффективный алгоритм сж..."	+2 +/–
Сообщение от opennews (ok), 25-Янв-15, 10:31
Ян Колле (Yann Collet), автор эталонной реализации алгоритма LZ4 (https://en.wikipedia.org/wiki/LZ4_%28compression_algori...), представил (http://fastcompression.blogspot.ru/2015/01/zstd-stronger-com...) новый алгоритм сжатия Z-standard (https://github.com/Cyan4973/zstd) (ZSTD), сочетающий высокую скорость кодирования и декодирования с хорошей эффективностью сжатия. Алгоритм предназначен для использования в повседневном обиходе, но он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4. По сравнению с обеспечивающими рекордные показатели системами предложенный алгоритм не является однобоким (скорость за счёт степени сжатия или степень сжатия за счёт скорости) и обеспечивает отличное соотношение скорости и эффективности сжатия. Библиотека с эталонной реализацией алгоритма распространяется (https://github.com/Cyan4973/zstd) под лицензией BSD. <center> <table style="border: 1px solid rgb(176, 177, 144); border-collapse: collapse; background: none repeat scroll 0% 0% rgb(221, 225, 194);" width="50%" border="1" cellpadding="2" cellspacing="0"> <thead> <tr> <th>Название</th> <th>Степень сжатия</th> <th>Скорость кодирования</th> <th>Скорость декодирования</th> </tr> </thead> <tbody> <tr> <td></td> <td></td> <td>MB/s</td> <td>MB/s</td> </tr> <tr> <td>zlib 1.2.8 -6 (http://www.zlib.net/)</td> <td>3.099</td> <td>18</td> <td>275</td> </tr> <tr> <td><strong>ZSTD</strong></td> <td><strong>2.872</strong></td> <td><strong>201</strong></td> <td><strong>498</strong></td> </tr> <tr> <td>zlib 1.2.8 -1 (http://www.zlib.net/)</td> <td>2.730</td> <td>58</td> <td>250</td> </tr> <tr> <td>LZ4 HC r127 (https://github.com/Cyan4973/lz4)</td> <td>2.720</td> <td>26</td> <td>1720</td> </tr> <tr> <td>QuickLZ 1.5.1b6</td> <td>2.237</td> <td>323</td> <td>373</td> </tr> <tr> <td>LZO 2.06</td> <td>2.106</td> <td>351</td> <td>510</td> </tr> <tr> <td>Snappy 1.1.0</td> <td>2.091</td> <td>238</td> <td>964</td> </tr> <tr> <td>LZ4 r127 (https://github.com/Cyan4973/lz4)</td> <td>2.084</td> <td>370</td> <td>1590</td> </tr> <tr> <td>LZF 3.6</td> <td>2.077</td> <td>220</td> <td>502</td> </tr> </tbody> </table> </center> Скорость декодирования в ZSTD составляет примерно 500 Мб/сек на одном ядре процессора Intel Core i5-4300U (1.9 GHz) при скорости кодирования на уровне 200 Мб/сек, что позволяет использовать данный алгортим в сценариях по обработке данных в режиме реального времени. Кроме того, как и в LZ4, для ситуаций когда данные сжимаются один раз и многократно распаковываются в ZSTD предусмотрен режим форсированного сжатия, при котором достигается более высокий коэффициент сжатия за счёт увеличения времени упаковки. Примечательной особенностью ZSTD также является возможность настройки потребления памяти, что позволяет использовать ZSTD на встраиваемых системах с небольшим размером ОЗУ или на серверах, одновременно обрабатывающих большое число сжатых потоков. Для декодирования требуется заполнение таблиц трансформации, размер который может быть настроен 2.5 до 20 Кб, а также выделение памяти под буфер с окном сжатия, который по умолчанию составляет 512 Кб, но может быть по желанию уменьшен до нескольких килобайт или увеличен до гигабайт (чем больше размер окна - тем выше уровень сжатия). В процессе сжатия данных дополнительно требуется выделение памяти под буфер сортировки, который по умолчанию составляет 128 Кб, но может быть произвольно уменьшен или увеличен. На приведённом ниже графике отражены параметры эксперимента по сжатию файла, передаче потока по сети и его распаковке на другом конце соединения. Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X). Второй график отличается тем, что вместо времени используется относительное ранжирование алгоритмов, при котором за 1 принят лучший для данной скорости результат, а остальные показатели показаны в процентном соотношении к нему. <center><a href="http://2.bp.blogspot.com/-T_-mbRHqExM/VMKItdNShBI/AAAAAAAABH... src="http://www.opennet.me/opennews/pics_base/0_1422169920.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> <center><a href="http://2.bp.blogspot.com/-gE8B0wCfox4/VMKJFyaDO4I/AAAAAAAABH... src="http://www.opennet.me/opennews/pics_base/0_1422169956.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> URL: http://fastcompression.blogspot.ru/2015/01/zstd-stronger-com... Новость: http://www.opennet.me/opennews/art.shtml?num=41534
Ответить \| Правка \| Cообщить модератору

Оглавление

Наоборот же Респект и уважуха автору, ждём поддержки в ядре и Btrfs , Fracta1L (ok), 10:31 , 25-Янв-15, (1) +15

А что ждать svn co http lz4 googlecode com svn trunk make -j 3sudo make inst, Аноним (-), 12:32 , 25-Янв-15, (10) +9

А смысл этой возни Там уже есть вполне сравнимый LZO, вот никто и не рвется осо, Аноним (-), 03:52 , 26-Янв-15, (35) +4
Почитай про checkinstall хотя бы, болезный , Аноним (-), 11:49 , 26-Янв-15, (40) –1

То есть алгоритм не годится ни для одной конкретной задачи , Аноним (-), 10:37 , 25-Янв-15, (2) –5

Вполне себе годится на моих данных логи в JSON-формате жмёт по объёму так же , anon9 (?), 10:55 , 25-Янв-15, (3) +12

А lz4 как при этом жмёт Т е понятно, что размер сжатого файла будет несколько , funny_falcon (?), 13:56 , 25-Янв-15, (12) +1

Судя по таблице вверху, lz4 сожмет не быстрее, а в несколько раз медленнее И ху, Stax (ok), 16:00 , 25-Янв-15, (19)

Есть lz4 hc, и есть просто lz4 Вглядись , tyuiop (?), 16:18 , 25-Янв-15, (22) +3

алгоритм, который среднячек во всём , Baz (?), 11:35 , 25-Янв-15, (4)

Предпочтёшь свербыстрый алгоритм, который почти не жмёт Или отлично сжимающий, , Tyuiop (?), 11:43 , 25-Янв-15, (5) +5

Жмем 7z или gz, а если сжимать не нужно - просто tar им Но я слышал что есть люд, Аноним (-), 15:05 , 25-Янв-15, (16) +10

сарказм Все сжимаю в tar Почему в тесте его нет , Аноним (-), 12:01 , 25-Янв-15, (6) +1

Научите сарказм , Michael Shigorin (ok), 12:07 , 25-Янв-15, (7) +11

Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более, A.Stahl (ok), 12:13 , 25-Янв-15, (8) +3

а сэкономишь аж 0,1 , ALex_hha (ok), 12:20 , 25-Янв-15, (9) –2

А теперь представь, что файлы по десятку байт и не неси фигню , Crazy Alex (ok), 13:21 , 25-Янв-15, (11) +8

Если это не FAT какой-нибудь, то данные короткого файла лежат в метаданных, вмес, Аноним (-), 14:33 , 25-Янв-15, (13) +1

Минимум - inode directory record , Crazy Alex (ok), 16:01 , 25-Янв-15, (20) +1

Кстати, в ext4 inline data - это экспериментальная фича В продакшне её нет , Crazy Alex (ok), 16:06 , 25-Янв-15, (21) +1

А те, кто пользуются reiser3, используют notail Быстрее и стабильней , tyuiop (?), 16:20 , 25-Янв-15, (23) +1

Это для наоборот Опция даёт прирост в скорости в ущерб вместимости - 5 , Ne01eX (??), 19:39 , 25-Янв-15, (27) –1

Кстати, Reiser4 умеет танцевать деревья для экономии дискового пространства , Ne01eX (??), 19:42 , 25-Янв-15, (28)

Dancing Tree это как бы название структуры данных, а не танец каких-то други, Stax (ok), 15:20 , 26-Янв-15, (42)
спасибо, кэп , Ne01eX (ok), 19:28 , 27-Янв-15, (52)

А те, кто пользуются reiserfs - ищут грабли начиная с риска угробить ФС к черто, Crazy Alex (ok), 20:20 , 25-Янв-15, (30) –1

Атомарная структура Reiser4 позволяет избежать рисков что-то прое бать при опера, Ne01eX (??), 21:05 , 25-Янв-15, (32)

Для начала - речь шла о reiserfs Сейчас вы говорите о reiser4 Reiser4 нет в ядр, Crazy Alex (ok), 22:05 , 25-Янв-15, (33)
Хорошо, встанем тогда на том, что это хорошо когда у людей есть выбор, какой ФС , Ne01eX (??), 09:17 , 26-Янв-15, (39) +3
А тут и спорить не с чем Сейчас, насколько я понимаю, в моде экстенты, но, веро, Crazy Alex (ok), 15:20 , 26-Янв-15, (41) –1
Есть небольшая разница Btrfs-ники могут внятно показать что это дает Ну там на, Аноним (-), 02:48 , 27-Янв-15, (49)
Проснись, тормоз В РСУБД экстенты в моде уже больше 30 лет - ты столько на свет, Аноним (-), 21:18 , 27-Янв-15, (53) –1
Он так отлажен, что разгром тома fsck ом при налете на неправильное дерево - k, Аноним (-), 02:51 , 27-Янв-15, (50) –1

А в btrfs уже есть И сжатие , Аноним (-), 03:53 , 26-Янв-15, (36)

В ZFS это есть уже лет 8 , Аноним (-), 21:18 , 27-Янв-15, (54) –1

А системный кеш вместо собственного выноса там уже используется , AlexAT (ok), 21:45 , 27-Янв-15, (56) +1

Посчитай сам last pid 49014 load averages 0 30, 0 26, 0 25 up 0 06 04 , iZEN (ok), 01:12 , 29-Янв-15, (57)
Не используется В топку , AlexAT (ok), 08:28 , 29-Янв-15, (58)

Даже если результат меньше оригинала на два бита, то это уже сжатие , Ня (?), 14:37 , 25-Янв-15, (14) +1

потому что он архиватор, Аноним (-), 15:08 , 25-Янв-15, (17) +1

ждем в 7зип , Аноним (-), 14:49 , 25-Янв-15, (15) +1

А зачем он там, если lzma жмет эффективней при сравнимой скорости , Мандаринос (?), 19:55 , 25-Янв-15, (29)

А можно подробнее про большую скорость lzma , Vic (??), 10:54 , 09-Сен-15, (59) +1

https github com mcmilk 7-Zip-zstd, мяя (?), 11:53 , 27-Ноя-19, (60)

Или по оси Y не время, а скорость, или получается что чем выше пропускная способ, Etch (?), 15:43 , 25-Янв-15, (18) +3
Хотелось бы ZSTD в TokuDB увидеть Самое оно , AlexAT (ok), 23:19 , 25-Янв-15, (34) +1

Хотелось Возьми и запили Делов-то , Аноним (-), 21:19 , 27-Янв-15, (55)

А в MySQL до сих пор только zlib, только в innodb и, по сути, размер всё равно б, Анонимко (?), 08:28 , 26-Янв-15, (37)

zlib в innodb не нужен, в innodb структура организована таким образом, что сжати, AlexAT (ok), 08:46 , 26-Янв-15, (38) +3

Ага, и использовать двиг, который занимает в 7 раз больше места http www pe, Аноним (-), 18:32 , 26-Янв-15, (43)

Когда в первый раз попробуете починить а падают myisam ы при некорректной ост, AlexAT (ok), 20:36 , 26-Янв-15, (46)

Я рад за вас, у меня таблицы при переводе на innodb разрастаются в 5 раз Лично , Анонимко (?), 10:08 , 27-Янв-15, (51)

Порекомендуйте идеальную СУБД , Аноним (-), 18:40 , 26-Янв-15, (44) –1

Не успел я написать слово Oracle , как у моего комментария уже был минус , Мандаринос (?), 18:43 , 26-Янв-15, (45)
Порекомендуйте идеальный автомобиль , AlexAT (ok), 20:38 , 26-Янв-15, (47)

Летающий DeLorian , Аноним (-), 02:34 , 27-Янв-15, (48) +2

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Fracta1L (ok), 25-Янв-15, 10:31 +15 +/–

> он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4
Наоборот же.
Респект и уважуха автору, ждём поддержки в ядре и Btrfs.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

2. Сообщение от Аноним (-), 25-Янв-15, 10:37 –5 +/–

То есть алгоритм не годится ни для одной конкретной задачи)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от anon9 (?), 25-Янв-15, 10:55 +12 +/–

Вполне себе годится: на моих данных (логи в JSON-формате) жмёт по объёму так же как gzip -6, но при этом в 7.6 раза быстрее. По-моему очень достойный результат

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #12

4. Сообщение от Baz (?), 25-Янв-15, 11:35 +/–

алгоритм, который среднячек во всём.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

5. Сообщение от Tyuiop (?), 25-Янв-15, 11:43 +5 +/–

Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #16

6. Сообщение от Аноним (-), 25-Янв-15, 12:01 +1 +/–

<сарказм>Все сжимаю в tar. Почему в тесте его нет?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #17

7. Сообщение от Michael Shigorin (ok), 25-Янв-15, 12:07 +11 +/–

> <сарказм>Все сжимаю в tar.
Научите!</сарказм>

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от A.Stahl (ok), 25-Янв-15, 12:13 +3 +/–

Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от ALex_hha (ok), 25-Янв-15, 12:20 –2 +/–

> Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров.
а сэкономишь аж 0,1%?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #11, #14

10. Сообщение от Аноним (-), 25-Янв-15, 12:32 +9 +/–

А что ждать?
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...
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/maste...
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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #35, #40

11. Сообщение от Crazy Alex (ok), 25-Янв-15, 13:21 +8 +/–

А теперь представь, что файлы по десятку байт и не неси фигню.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

12. Сообщение от funny_falcon (?), 25-Янв-15, 13:56 +1 +/–

А lz4 как при этом жмёт? Т.е. понятно, что размер сжатого файла будет несколько больше, но на сколько? и во сколько раз быстрее он сожмёт?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #19

13. Сообщение от Аноним (-), 25-Янв-15, 14:33 +1 +/–

Если это не FAT какой-нибудь, то данные короткого файла лежат в метаданных, вместе с прочими атрибутами. Не занимает он ни одного кластера.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20

14. Сообщение от Ня (?), 25-Янв-15, 14:37 +1 +/–

Даже если результат меньше оригинала на два бита, то это уже сжатие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

15. Сообщение от Аноним (-), 25-Янв-15, 14:49 +1 +/–

ждем в 7зип ?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #60

16. Сообщение от Аноним (-), 25-Янв-15, 15:05 +10 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

17. Сообщение от Аноним (-), 25-Янв-15, 15:08 +1 +/–

> <сарказм>Все сжимаю в tar. Почему в тесте его нет?
потому что он архиватор

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

18. Сообщение от Etch (?), 25-Янв-15, 15:43 +3 +/–

> Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X).
Или по оси Y не время, а скорость, или получается что чем выше пропускная способность канала, тем дольше длится операция...

Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Stax (ok), 25-Янв-15, 16:00 +/–

Судя по таблице вверху, lz4 сожмет не быстрее, а в несколько раз медленнее. И хуже. Но - разжиматься потом будет быстрее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #22

20. Сообщение от Crazy Alex (ok), 25-Янв-15, 16:01 +1 +/–

Минимум - inode + directory record.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #21

21. Сообщение от Crazy Alex (ok), 25-Янв-15, 16:06 +1 +/–

Кстати, в ext4 inline data - это экспериментальная фича. В продакшне её нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #23, #36

22. Сообщение от tyuiop (?), 25-Янв-15, 16:18 +3 +/–

Есть lz4 hc, и есть просто lz4. Вглядись.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

23. Сообщение от tyuiop (?), 25-Янв-15, 16:20 +1 +/–

А те, кто пользуются reiser3, используют notail. Быстрее и стабильней.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27, #30

27. Сообщение от Ne01eX (??), 25-Янв-15, 19:39 –1 +/–

Это для наоборот. Опция даёт прирост в скорости в ущерб вместимости (- ~5%).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #28

28. Сообщение от Ne01eX (??), 25-Янв-15, 19:42 +/–

Кстати, Reiser4 умеет танцевать деревья для экономии дискового пространства.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #42

29. Сообщение от Мандаринос (?), 25-Янв-15, 19:55 +/–

А зачем он там, если lzma жмет эффективней при сравнимой скорости?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #59

30. Сообщение от Crazy Alex (ok), 25-Янв-15, 20:20 –1 +/–

А те, кто пользуются reiserfs - ищут грабли. начиная с риска угробить ФС к чертовой матери изаканчивая суровым падением скорости вследствеи фрагментации. Если, конечно, за последнюю пару лет что-то радикально не улучшилось, но не припомню такого.
Если уж на то пошло - паковать хвосты умеет XFS. И, так как, судя по любви к reiserfs, вы живете в криокамере - информирую, что тормоза с мелкифи файлами на XFS уже с год как пофиксили.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #32

32. Сообщение от Ne01eX (??), 25-Янв-15, 21:05 +/–

>>А те, кто пользуются reiserfs - ищут грабли. начиная с риска угробить ФС к чертовой матери изаканчивая суровым падением скорости вследствеи фрагментации. Если, конечно, за последнюю пару лет что-то радикально не улучшилось, но не припомню такого.
Атомарная структура Reiser4 позволяет избежать рисков что-то прое@бать при операциях с ФС. Ну а так, - в целом всё также стабильно как и в других ФС.
Фрагментация пока единственное неудобство, но думаю это решится в будущем.
>>Если уж на то пошло - паковать хвосты умеет XFS. И, так как, судя по любви к reiserfs, вы живете в криокамере - информирую, что тормоза с мелкифи файлами на XFS уже с год как пофиксили.
Ну и молодцы, что пофиксили. Я, живя в своей криокамере, этого не знал.:-\
P.S. Не фанат Reiser4, но уважаю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #33

33. Сообщение от Crazy Alex (ok), 25-Янв-15, 22:05 +/–

Для начала - речь шла о reiserfs. Сейчас вы говорите о reiser4.
Reiser4 нет в ядре (соответственно, она слабо протестирована) и, самое главное, её фактически некому поддерживать и развивать. Лично для меня на этом разговор закончен.
Что до reiserfs - опять-таки, ничего не решится, так как ей, собственно, никто не занимается.
Рейзера я и сам уважаю, но, с учетом развития с тех времён, когда он свои ФС создавал, я не вижу никакого смысла на них смотреть. Ну вот так не повезло им - были в своё время продвинутями и перспективными, да сплыли.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #39

34. Сообщение от AlexAT (ok), 25-Янв-15, 23:19 +1 +/–

Хотелось бы ZSTD в TokuDB увидеть... Самое оно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55

35. Сообщение от Аноним (-), 26-Янв-15, 03:52 +4 +/–

А смысл этой возни? Там уже есть вполне сравнимый LZO, вот никто и не рвется особо имплементить еще 1 почти такой же алгоритм.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

36. Сообщение от Аноним (-), 26-Янв-15, 03:53 +/–

> Кстати, в ext4 inline data - это экспериментальная фича. В продакшне её нет.
А в btrfs уже есть. И сжатие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #54

37. Сообщение от Анонимко (?), 26-Янв-15, 08:28 +/–

А в MySQL до сих пор только zlib, только в innodb и, по сути, размер всё равно больше, чем у несжатой myisam...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #44

38. Сообщение от AlexAT (ok), 26-Янв-15, 08:46 +3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #43, #51

39. Сообщение от Ne01eX (??), 26-Янв-15, 09:17 +3 +/–

Хорошо, встанем тогда на том, что это хорошо когда у людей есть выбор, какой ФС пользоваться в GNU/Linux. =)
Напоследок замечу, что VFS ядра запилена под ext*. К тому же, это один из самых динамичных кусков ядра Linux. И, наконец, третье - Linux перестал быть проектом энтузиастов. Теперь это проект корпораций с их легионами маркетологов и ручных кодеров.
С учётом этого, простым программистам, вроде Эдуарда Шишкина и небольшому сообществу энтузиастов, сформировавшемуся возле него, нелегко оставаться на гребне волны, программируя Just for fun. Но это не делает код и идеи Reiser4 устаревшими или неправильными.
В эпоху развития reiserfs v.3 Гансу Рейзеру удалось включить код в состав основной ветки ядра, тем самым обеспечив поддержку ФС Linux-сообществом. Но, во многом, благодаря наличию Namesys, маленькой, но компании. И уже как следствие включения в основную ветвь, со временем, код reiserfs v.3 стал отлаженным и полностью интегрированным.

Вот такие вот мои мысли на тему ReiserFS v.3/Reiser4. Спорить с ними совсем не обязательно, так как от этого они не перестанут быть моими. =)
---
Честь имею, Ne01eX.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #41, #50

40. Сообщение от Аноним (-), 26-Янв-15, 11:49 –1 +/–

Почитай про checkinstall хотя бы, болезный.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

41. Сообщение от Crazy Alex (ok), 26-Янв-15, 15:20 –1 +/–

А тут и спорить не с чем. Сейчас, насколько я понимаю, в моде экстенты, но, вероятно, Рейзер сумел бы их со своей архитектурой подружить.
Я на всё это смотрю с чисто практической точки зрения - использовать предпочтительно то, что, с одной стороны, показало свои возможности и ограничения, хорошо оттестировано и имеет приемлемые характеристики - а с другой имеет хорошую команду, которая бы правила ошибки и занималась развитием. На данный момент это Ext4 и XFS. Может, через годик btrfs подоспеет, хотя как по мне - это на порядок большее надругательство над линуксовой идеологией блочных устройств и ФС, чем то, что предлагал Рейзер. Но если покажет хороший практический результат - то и ладно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #49, #53

42. Сообщение от Stax (ok), 26-Янв-15, 15:20 +/–

"Dancing Tree" это как бы название структуры данных, а не "танец" каких-то других типов деревьев.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #52

43. Сообщение от Аноним (-), 26-Янв-15, 18:32 +/–

Ага, и использовать двиг, который занимает в 7 раз больше места? ( http://www.percona.com/forums/questions-discussions/mysql-an... ). Боже упаси. Я не проверял, но что-то верится с трудом что innodb при таком оверхеде может быть быстрее myisam.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #46

44. Сообщение от Аноним (-), 26-Янв-15, 18:40 –1 +/–

Порекомендуйте идеальную СУБД?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #45, #47

45. Сообщение от Мандаринос (?), 26-Янв-15, 18:43 +/–

Не успел я написать слово "Oracle", как у моего комментария уже был минус :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

46. Сообщение от AlexAT (ok), 26-Янв-15, 20:36 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от AlexAT (ok), 26-Янв-15, 20:38 +/–

> Порекомендуйте идеальную СУБД?
Порекомендуйте идеальный автомобиль.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #48

48. Сообщение от Аноним (-), 27-Янв-15, 02:34 +2 +/–

> Порекомендуйте идеальный автомобиль.
Летающий DeLorian :).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

49. Сообщение от Аноним (-), 27-Янв-15, 02:48 +/–

> как по мне - это на порядок большее надругательство над линуксовой
> идеологией блочных устройств и ФС, чем то, что предлагал Рейзер.
Есть небольшая разница. Btrfs-ники могут внятно показать что это дает. Ну там например возможность смешивать уровни райдов и переконфигурировать все это на лету. Без остановки системы и с плавной миграцией. А у рейзера только чисто теоретические возможности. Ну там чисто теоретически - можно например плагин для CoW сделать. Чисто практически - ну как бы пусть покажут это работающее со скоростью хоть того же бтрфс, тогда поверим. Ибо если плагином привинчивать CoW к обычной файлухе - это совсем не то же самое что проектировать файлуху сразу как CoW. Сложно самосвал в самолет перестраивать - конструкционные особенности разные. И тезис что а вот мы плагином все-таки так можем - ок, давайте готовый прототип и мы посмотрим на его летные качества.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

50. Сообщение от Аноним (-), 27-Янв-15, 02:51 –1 +/–

> включения в основную ветвь, со временем, код reiserfs v.3 стал отлаженным
> и полностью интегрированным.
Он так отлажен, что разгром тома fsck'ом при налете на "неправильное" дерево - known issue. С советом от разработчиков не хранить образа рейзеров на рейзере (ну то-есть, гудбай, виртуалки!). Ну его нафиг такую стабильность с такими known issues, Мэйсон и его шака как-то поадекватнее к эксплуатационщикам.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

51. Сообщение от Анонимко (?), 27-Янв-15, 10:08 +/–

Я рад за вас, у меня таблицы при переводе на innodb разрастаются в 5 раз. Лично я по этому параметру вижу регресс, myisam по тестам оказывается гораздо быстрее. Еслиб еще к этому двигу прикрутили сжатие и построчную блокировку, - myisam бы обходил innodb на порядки.
Транзакции, кстати, далеко не всем нужны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

52. Сообщение от Ne01eX (ok), 27-Янв-15, 19:28 +/–

> "Dancing Tree" это как бы название структуры данных, а не "танец" каких-то
> других типов деревьев.
спасибо, кэп. =)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

53. Сообщение от Аноним (-), 27-Янв-15, 21:18 –1 +/–

Проснись, тормоз. В РСУБД экстенты в моде уже больше 30 лет - ты столько на свете не прожил.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

54. Сообщение от Аноним (-), 27-Янв-15, 21:18 –1 +/–

>> Кстати, в ext4 inline data - это экспериментальная фича. В продакшне её нет.
> А в btrfs уже есть. И сжатие.
В ZFS это есть уже лет 8.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #56

55. Сообщение от Аноним (-), 27-Янв-15, 21:19 +/–

> Хотелось бы ZSTD в TokuDB увидеть... Самое оно.
Хотелось? Возьми и запили. Делов-то.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

56. Сообщение от AlexAT (ok), 27-Янв-15, 21:45 +1 +/–

> В ZFS это есть уже лет 8.
А системный кеш вместо собственного выноса там уже используется?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #57

57. Сообщение от iZEN (ok), 29-Янв-15, 01:12 +/–

>> В ZFS это есть уже лет 8.
> А системный кеш вместо собственного выноса там уже используется?
Посчитай сам:
last pid: 49014;  load averages:  0.30,  0.26,  0.25    up 0+06:04:38  01:12:48
63 processes:  1 running, 62 sleeping
CPU:  1.4% user,  0.0% nice,  0.6% system,  0.0% interrupt, 98.1% idle
Mem: 381M Active, 1414M Inact, 3275M Wired, 120K Cache, 6839M Free
ARC: 2241M Total, 681M MFU, 1215M MRU, 1216K Anon, 25M Header, 320M Other
Swap:
Всё ОЗУ 12ГБ.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #58

58. Сообщение от AlexAT (ok), 29-Янв-15, 08:28 +/–

Не используется. В топку.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

59. Сообщение от Vic (??), 09-Сен-15, 10:54 +1 +/–

А можно подробнее про большую скорость lzma?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

60. Сообщение от мяя (?), 27-Ноя-19, 11:53 +/–

https://github.com/mcmilk/7-Zip-zstd

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Fracta1L (ok), 25-Янв-15, 10:31	+15 +/–
> он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4 Наоборот же. Респект и уважуха автору, ждём поддержки в ядре и Btrfs.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10

2. Сообщение от Аноним (-), 25-Янв-15, 10:37	–5 +/–
То есть алгоритм не годится ни для одной конкретной задачи)
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #3

3. Сообщение от anon9 (?), 25-Янв-15, 10:55	+12 +/–
Вполне себе годится: на моих данных (логи в JSON-формате) жмёт по объёму так же как gzip -6, но при этом в 7.6 раза быстрее. По-моему очень достойный результат
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #12

4. Сообщение от Baz (?), 25-Янв-15, 11:35	+/–
алгоритм, который среднячек во всём.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5

5. Сообщение от Tyuiop (?), 25-Янв-15, 11:43	+5 +/–
Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #16

6. Сообщение от Аноним (-), 25-Янв-15, 12:01	+1 +/–
<сарказм>Все сжимаю в tar. Почему в тесте его нет?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7, #17

7. Сообщение от Michael Shigorin (ok), 25-Янв-15, 12:07	+11 +/–
> <сарказм>Все сжимаю в tar. Научите!</сарказм>
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от A.Stahl (ok), 25-Янв-15, 12:13	+3 +/–
Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от ALex_hha (ok), 25-Янв-15, 12:20	–2 +/–
> Ну если упаковывается множество мелких файлов, то можно сэкономить за счёт более рационального использования кластеров. а сэкономишь аж 0,1%?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #11, #14

10. Сообщение от Аноним (-), 25-Янв-15, 12:32	+9 +/–
А что ждать? 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... 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/maste... 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
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #35, #40

11. Сообщение от Crazy Alex (ok), 25-Янв-15, 13:21	+8 +/–
А теперь представь, что файлы по десятку байт и не неси фигню.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #13

12. Сообщение от funny_falcon (?), 25-Янв-15, 13:56	+1 +/–
А lz4 как при этом жмёт? Т.е. понятно, что размер сжатого файла будет несколько больше, но на сколько? и во сколько раз быстрее он сожмёт?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #19

13. Сообщение от Аноним (-), 25-Янв-15, 14:33	+1 +/–
Если это не FAT какой-нибудь, то данные короткого файла лежат в метаданных, вместе с прочими атрибутами. Не занимает он ни одного кластера.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #20

14. Сообщение от Ня (?), 25-Янв-15, 14:37	+1 +/–
Даже если результат меньше оригинала на два бита, то это уже сжатие.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

15. Сообщение от Аноним (-), 25-Янв-15, 14:49	+1 +/–
ждем в 7зип ?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #29, #60

16. Сообщение от Аноним (-), 25-Янв-15, 15:05	+10 +/–
>Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе? Жмем 7z или gz, а если сжимать не нужно - просто tar'им. Но я слышал что есть люди которые верят в бога и пользуются винраром.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

17. Сообщение от Аноним (-), 25-Янв-15, 15:08	+1 +/–
> <сарказм>Все сжимаю в tar. Почему в тесте его нет? потому что он архиватор
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

18. Сообщение от Etch (?), 25-Янв-15, 15:43	+3 +/–
> Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X). Или по оси Y не время, а скорость, или получается что чем выше пропускная способность канала, тем дольше длится операция...
Ответить \| Правка \| Наверх \| Cообщить модератору

19. Сообщение от Stax (ok), 25-Янв-15, 16:00	+/–
Судя по таблице вверху, lz4 сожмет не быстрее, а в несколько раз медленнее. И хуже. Но - разжиматься потом будет быстрее.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #22

20. Сообщение от Crazy Alex (ok), 25-Янв-15, 16:01	+1 +/–
Минимум - inode + directory record.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #21

21. Сообщение от Crazy Alex (ok), 25-Янв-15, 16:06	+1 +/–
Кстати, в ext4 inline data - это экспериментальная фича. В продакшне её нет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #20 Ответы: #23, #36

22. Сообщение от tyuiop (?), 25-Янв-15, 16:18	+3 +/–
Есть lz4 hc, и есть просто lz4. Вглядись.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

23. Сообщение от tyuiop (?), 25-Янв-15, 16:20	+1 +/–
А те, кто пользуются reiser3, используют notail. Быстрее и стабильней.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #27, #30

27. Сообщение от Ne01eX (??), 25-Янв-15, 19:39	–1 +/–
Это для наоборот. Опция даёт прирост в скорости в ущерб вместимости (- ~5%).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23 Ответы: #28

28. Сообщение от Ne01eX (??), 25-Янв-15, 19:42	+/–
Кстати, Reiser4 умеет танцевать деревья для экономии дискового пространства.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #42

29. Сообщение от Мандаринос (?), 25-Янв-15, 19:55	+/–
А зачем он там, если lzma жмет эффективней при сравнимой скорости?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #59

30. Сообщение от Crazy Alex (ok), 25-Янв-15, 20:20	–1 +/–
А те, кто пользуются reiserfs - ищут грабли. начиная с риска угробить ФС к чертовой матери изаканчивая суровым падением скорости вследствеи фрагментации. Если, конечно, за последнюю пару лет что-то радикально не улучшилось, но не припомню такого. Если уж на то пошло - паковать хвосты умеет XFS. И, так как, судя по любви к reiserfs, вы живете в криокамере - информирую, что тормоза с мелкифи файлами на XFS уже с год как пофиксили.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23 Ответы: #32

32. Сообщение от Ne01eX (??), 25-Янв-15, 21:05	+/–
>>А те, кто пользуются reiserfs - ищут грабли. начиная с риска угробить ФС к чертовой матери изаканчивая суровым падением скорости вследствеи фрагментации. Если, конечно, за последнюю пару лет что-то радикально не улучшилось, но не припомню такого. Атомарная структура Reiser4 позволяет избежать рисков что-то прое@бать при операциях с ФС. Ну а так, - в целом всё также стабильно как и в других ФС. Фрагментация пока единственное неудобство, но думаю это решится в будущем. >>Если уж на то пошло - паковать хвосты умеет XFS. И, так как, судя по любви к reiserfs, вы живете в криокамере - информирую, что тормоза с мелкифи файлами на XFS уже с год как пофиксили. Ну и молодцы, что пофиксили. Я, живя в своей криокамере, этого не знал.:-\ P.S. Не фанат Reiser4, но уважаю.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #30 Ответы: #33

33. Сообщение от Crazy Alex (ok), 25-Янв-15, 22:05	+/–
Для начала - речь шла о reiserfs. Сейчас вы говорите о reiser4. Reiser4 нет в ядре (соответственно, она слабо протестирована) и, самое главное, её фактически некому поддерживать и развивать. Лично для меня на этом разговор закончен. Что до reiserfs - опять-таки, ничего не решится, так как ей, собственно, никто не занимается. Рейзера я и сам уважаю, но, с учетом развития с тех времён, когда он свои ФС создавал, я не вижу никакого смысла на них смотреть. Ну вот так не повезло им - были в своё время продвинутями и перспективными, да сплыли.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #32 Ответы: #39

34. Сообщение от AlexAT (ok), 25-Янв-15, 23:19	+1 +/–
Хотелось бы ZSTD в TokuDB увидеть... Самое оно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #55