1.1, Fracta1L (ok), 10:31, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +15 +/– |
> он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4
Наоборот же.
Респект и уважуха автору, ждём поддержки в ядре и Btrfs.
| |
|
|
3.35, Аноним (-), 03:52, 26/01/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
А смысл этой возни? Там уже есть вполне сравнимый LZO, вот никто и не рвется особо имплементить еще 1 почти такой же алгоритм.
| |
|
|
|
2.3, anon9 (?), 10:55, 25/01/2015 [^] [^^] [^^^] [ответить]
| +12 +/– |
Вполне себе годится: на моих данных (логи в 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 сожмет не быстрее, а в несколько раз медленнее. И хуже. Но - разжиматься потом будет быстрее.
| |
|
|
|
|
2.5, Tyuiop (?), 11:43, 25/01/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?
| |
|
3.16, Аноним (-), 15:05, 25/01/2015 [^] [^^] [^^^] [ответить]
| +10 +/– |
>Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?
Жмем 7z или gz, а если сжимать не нужно - просто 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%?
| |
|
|
6.13, Аноним (-), 14:33, 25/01/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если это не FAT какой-нибудь, то данные короткого файла лежат в метаданных, вместе с прочими атрибутами. Не занимает он ни одного кластера.
| |
|
|
|
|
|
|
12.42, Stax (ok), 15:20, 26/01/2015 [^] [^^] [^^^] [ответить] | +/– | Dancing Tree это как бы название структуры данных, а не танец каких-то други... текст свёрнут, показать | |
|
|
|
|
|
13.39, Ne01eX (??), 09:17, 26/01/2015 [^] [^^] [^^^] [ответить] | +3 +/– | Хорошо, встанем тогда на том, что это хорошо когда у людей есть выбор, какой ФС ... текст свёрнут, показать | |
|
|
15.49, Аноним (-), 02:48, 27/01/2015 [^] [^^] [^^^] [ответить] | +/– | Есть небольшая разница Btrfs-ники могут внятно показать что это дает Ну там на... большой текст свёрнут, показать | |
15.53, Аноним (-), 21:18, 27/01/2015 [^] [^^] [^^^] [ответить] | –1 +/– | Проснись, тормоз В РСУБД экстенты в моде уже больше 30 лет - ты столько на свет... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
5.14, Ня (?), 14:37, 25/01/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Даже если результат меньше оригинала на два бита, то это уже сжатие.
| |
|
|
|
2.17, Аноним (-), 15:08, 25/01/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> <сарказм>Все сжимаю в tar. Почему в тесте его нет?
потому что он архиватор
| |
|
1.18, Etch (?), 15:43, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X).
Или по оси Y не время, а скорость, или получается что чем выше пропускная способность канала, тем дольше длится операция...
| |
|
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 вообще пора запретить, как зло.
| |
|
|
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 на порядки.
Транзакции, кстати, далеко не всем нужны.
| |
|
|
3.47, AlexAT (ok), 20:38, 26/01/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Порекомендуйте идеальную СУБД?
Порекомендуйте идеальный автомобиль.
| |
|
|
|