| 1.1, Fracta1L (ok), 10:31, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +15 +/– |
 > он не рассчитан на достижение рекордных скоростей, свойственных LZMA и ZPAQ, или максимальных уровней сжатия, обеспечиваемых в LZ4
Наоборот же.
Респект и уважуха автору, ждём поддержки в ядре и Btrfs.
| | |
| |
| 2.3, anon9 (?), 10:55, 25/01/2015 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +12 +/– |
Вполне себе годится: на моих данных (логи в JSON-формате) жмёт по объёму так же как gzip -6, но при этом в 7.6 раза быстрее. По-моему очень достойный результат
| | |
|
| |
| |
| 3.16, Аноним (-), 15:05, 25/01/2015 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +10 +/– | |
>Предпочтёшь свербыстрый алгоритм, который почти не жмёт? Или отлично сжимающий, но результата ждать неделю на современном железе?
Жмем 7z или gz, а если сжимать не нужно - просто tar'им.
Но я слышал что есть люди которые верят в бога и пользуются винраром.
| | |
|
|
| 1.18, Etch (?), 15:43, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +3 +/– | |
> Первый рафик показывает соотношение времени выполнения операции (ось Y) к пропускной способность канала связи в Мб/сек (ось X).
Или по оси Y не время, а скорость, или получается что чем выше пропускная способность канала, тем дольше длится операция...
| | |
| |
| 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 на порядки.
Транзакции, кстати, далеко не всем нужны.
| | |
|
|
|
