| 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 [^] [^^] [^^^] [ответить]
| +/– |
> Порекомендуйте идеальную СУБД?
Порекомендуйте идеальный автомобиль.
| | |
|
|
|