Комментарии 16
Мне, к сожалению, сейчас негде это всё собрать, если кто-нибудь соберёт и протестит, киньте сюда, пожалуйста, таблицу — что получилось. Скорость и коэффициент сжатия по сравнению с остальными решениями.
Вот таблица. pastebin.com/SFaNzRuf
Увы, она тоже не потоковая. Требует полного блока на сжатие и на расжатие. Соответственно в реальных приложениях где она требуется засчет своей скорости (сжимать сетевой поток на лету и разжимать его) — она бесполезна.
Нихто ж вам не мешает разбивать ваш трафик на сколь угодно малые части и их потом отдельно сжимать/расжимать, не так ли? Не понятно на сколько менее оно будет еффетивно — но прикрутить вроде можно.
Вот вот менее эффективно. Чтобы эмулировать поток блоки придется делать маленькими и все равно не будет полной эмуляции. Очень легко представить такую эмуляцию на отправку:
— У вас исходящий ПОТОК, нужно его поточно же отправлять, возникает вопрос: как копить блоки?
Накапливать блок определенной длинны?
Решение неправильное, так как поток может застрять на половине блоке.
Добавить таймеры на накопления блока? Получаем увеличеный лаг (а еще к этому таймеру добавится еще системный лаг на отправку) и оверхед на указание размера блока в потоке, так как при этом блоки станут переменной длинны. Кроме того таймер на накоплении блока заствляет иметь обратную связь с сетевой частью из паковщика, что отрицательно сказывается на гибкости кода.
— Итого эта библиотека хороша только для быстрого блочного обмена.
— А вот поточный бы пакер представлял бы из себя трубу без всякой завязки на сетевую часть (таймеры).
— У вас исходящий ПОТОК, нужно его поточно же отправлять, возникает вопрос: как копить блоки?
Накапливать блок определенной длинны?
Решение неправильное, так как поток может застрять на половине блоке.
Добавить таймеры на накопления блока? Получаем увеличеный лаг (а еще к этому таймеру добавится еще системный лаг на отправку) и оверхед на указание размера блока в потоке, так как при этом блоки станут переменной длинны. Кроме того таймер на накоплении блока заствляет иметь обратную связь с сетевой частью из паковщика, что отрицательно сказывается на гибкости кода.
— Итого эта библиотека хороша только для быстрого блочного обмена.
— А вот поточный бы пакер представлял бы из себя трубу без всякой завязки на сетевую часть (таймеры).
НЛО прилетело и опубликовало эту надпись здесь
Да уж.
> Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems.
Вполне вероятно оно уже там есть просто для нас прозрачно и не афишируется. Возможно с пользователя берётся и за время (CPU) комрессии-декомпрессии и за полный несжатый размер хранения данных.
Если же дать нам в руки то получится что за storage брать будут меньше.
> Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems.
Вполне вероятно оно уже там есть просто для нас прозрачно и не афишируется. Возможно с пользователя берётся и за время (CPU) комрессии-декомпрессии и за полный несжатый размер хранения данных.
Если же дать нам в руки то получится что за storage брать будут меньше.
НЛО прилетело и опубликовало эту надпись здесь
А смысл есть? Делали анализ не дешевле было бы хранить несжатым?
Насколько я понимаю выигрыш будет если данные хранятся долго и читаются редко. Было бы интересно увидеть анализ на эту тему. Что то вроде «при хранени 100KB обычного теста компрессия становится выгодной если вы храните дольше чем Х дней».
Насколько я понимаю выигрыш будет если данные хранятся долго и читаются редко. Было бы интересно увидеть анализ на эту тему. Что то вроде «при хранени 100KB обычного теста компрессия становится выгодной если вы храните дольше чем Х дней».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Snappy (zippy), библиотека для сжатия данных от Bigtable