Да. Есть доля шутки. Но просто имейте в виду, что сейчас много пользователей пользуются интернетом именно с телефона, и для них не проблема держать телефон вертикально, чтобы смотреть видео (а вот если ютуб не позволяет подобное — это ему минус).
Сам не люблю вертикальное видео, но иногда без него не обойтись, потому что человек существо вертикальное (обычно) и не любит сливаться с ландшафтом. А угол камеры телефона не позволяет снимать человека в полный рост в горизонтальном режиме.
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
Да с этим вроде нет проблем, это просто 7z такой медленный.
проводили ли тесты на промышленных масштабах 200-300-500Гб? но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?
Смотрите, тут дело в том, что вы можете получить 7z быстрее и проще чем стандартными средствами (и не тратить место на диске). А потом этот 7z восстановить не распаковывая. А т.к. 7z жмёт гораздо лучше чем zip и стандартные средства, для долговременного хранения лучше использовать его (если есть время). Ну или для быстрых бекапов уменьшить качество сжатия.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
Положить в папку sxs содержимое из установочного диска (microsoft-windows-netfx3-ondemand-package.cab). При этом сам скачивать по сети, или же использовать распакованный образ из шары — отказывался.
Хибернейт, но несколько месяцев хибернейт. Сделал проверку на виндовые апдейты, и оно вылезло, т.е. если и кешировал где, то очень тайно, потому что скачивал всё целиком.
Вчера включил ноутбук и он упорно мне предлагал обновиться на Win10, стало интересно, сроки ведь прошли — обновился, активировался. Так что, судя по всему, даже инвалидом не надо быть, до сих пор всё само происходит.
Ну, это не ко мне вопрос :) А к разработчикам Microsoft. А если серьёзно, то встроенная индексация ещё смотрит содержимое файлов и метатеги. Т.е. этим поиском может найти письма по содержимому, музыку по тегам и прочее. И вообще там есть целый язык запросов для всего этого барахла.
Другое дело, что многим этого не надо, и большинство этим не пользуется.
И? Чем это противоречит тому, что я сказал? Файл будет обработан точно также. Как поток. Хотя в реальности, данный поток или файл приведут тупо к заполнению внутреннего буфера определённой длины (32-64Кб), который будет пожат и выплюнут наружу.
Вообще, давайте прекращать эту дискуссию (или уходить в ЛС), а то совсем от темы статьи уехали. Вот я напишу статью про устройство архиваторов с примером реализации (я джва года уже хочу это сделать, но лень), и там уже знатно посрёмся и помакаем друг друга в нечистоты ;)
Сравните «ацки быстрый lzo» с rar на реальных файлах и вы прозреете. Понятно, что lzo быстрее, но в большинстве случаев место важнее. Не, ну кого интересует файл из одних нулей. Не прикалывайтесь.
Сравнивал, знаю. Двукратное улучшение сжатия и десятикратное падение скорости.
Один словарь хорошо, когда файлы одного типа(например текст на одном языке). Если тип данных меняется(а это почти всегда), множественные словари выигрывают.
Да какие там словари… нет в LZ77 словарей, там плавающее окно. И это гораздо проще, понятнее и быстрее чем словари. А это плавающее окно само подстроится под данные.
У винрара множество алгоритмов с эврестическим выбором по типу файла и/или характеристикам данных.
Кроме PPMd, там, насколько я помню, трансформирующие алгоритмы. А это всего-лишь пред.обработка перед тем же самым сжатием.
У винрара множество алгоритмов с эврестическим выбором по типу файла и/или характеристикам данных.
Ну, я вроде это и написал, LZ77 + энтропия. Но они не двухпроходные, а один поверх другого. Или вы считали подготовительные алгоритмы за проход?
Все архиваторы в конце концов работают с потоком (ну или с массивом байт). В данном случае, AdventureWorks (100 или 200 мегабайт) в потоке с флушами (могу сделать и независимыми блоками). Вообще, этот график был в своё время сделан не для демонстрации не размеров блоков, а полезности при «запоминании» предыдущего блока. Ну и для размера блока он подошёл.
Но в целом, при размерах блоков больше 64Кб — разница уже небольшая. Связано с тем, что размер «словаря» (не люблю это слово для LZ77), как раз 32-64Кб у данных архиваторов. Больший размер словаря даёт мало эффекта.
Хм, я всегда считал, что чем более крупный блок анализируется, тем лучше сжатие, ведь на бОльшем блоке можно найти бОльше совпадений и создать лучший словарь?
Да, но при размере в 1Mb, уже копеечная разница получается.
Картинка по размеру блоков
Тут как раз видно, насколько влияют граничные байты (Blazer и GZip) и независимые блоки (LZ4, Snappy)
Есть где-то ссылка, где бы детальнее показывалось как работает winrar, имеется ввиду именно работа с блоками? В стандартном faq и быстрым гуглением не вижу…
Да вроде бы он достаточно простой — LZ77 + энтропийное сжатие (тут не помню какое). Блоки, думаю как и в 7zip — при 1-2 тредах — потоковый, при большем количестве — независимые.
Делают. Ибо это аццки быстрее. Смотрите на LZ4, Snappy, LZO, QuickLZ и прочие. Это получается практически бесплатное архивирование при хорошем результате.
Есть граничные байты.
На них, как раз и проблема. Представьте для простоты файл в миллиард нулей. Сжимается в условные 5 байт (повторить миллиард раз ноль). С блоками у вас будет — повторить размер блока ноль. В реальности, это копейки, правда.
Потому необходим этап проверки «а не получится ли лучше если вот эти 10 кусков подряд сделать одним словарем»
Или вы фигню говорите, или в вашем понимании куски являются последовательностью, а не блоками. И классического Хаффмана (Дефри-Халман — это что-то среднее из Хаффмана и Диффи-Хеллмана, т.е. вообще не по делу), никто не использует. Обычный однопроходной энтропийный алгоритм.
Сам не люблю вертикальное видео, но иногда без него не обойтись, потому что человек существо вертикальное (обычно) и не любит сливаться с ландшафтом. А угол камеры телефона не позволяет снимать человека в полный рост в горизонтальном режиме.
normal
Да с этим вроде нет проблем, это просто 7z такой медленный.
Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?
Пожелания записали, будут ресурсы — сделаем.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
Положить в папку sxs содержимое из установочного диска (microsoft-windows-netfx3-ondemand-package.cab). При этом сам скачивать по сети, или же использовать распакованный образ из шары — отказывался.
Другое дело, что многим этого не надо, и большинство этим не пользуется.
Вообще, давайте прекращать эту дискуссию (или уходить в ЛС), а то совсем от темы статьи уехали. Вот я напишу статью про устройство архиваторов с примером реализации (я джва года уже хочу это сделать, но лень), и там уже знатно посрёмся и помакаем друг друга в нечистоты ;)
Сравнивал, знаю. Двукратное улучшение сжатия и десятикратное падение скорости.
Да какие там словари… нет в LZ77 словарей, там плавающее окно. И это гораздо проще, понятнее и быстрее чем словари. А это плавающее окно само подстроится под данные.
Кроме PPMd, там, насколько я помню, трансформирующие алгоритмы. А это всего-лишь пред.обработка перед тем же самым сжатием.
Ну, я вроде это и написал, LZ77 + энтропия. Но они не двухпроходные, а один поверх другого. Или вы считали подготовительные алгоритмы за проход?
Но в целом, при размерах блоков больше 64Кб — разница уже небольшая. Связано с тем, что размер «словаря» (не люблю это слово для LZ77), как раз 32-64Кб у данных архиваторов. Больший размер словаря даёт мало эффекта.
Да, но при размере в 1Mb, уже копеечная разница получается.
Тут как раз видно, насколько влияют граничные байты (Blazer и GZip) и независимые блоки (LZ4, Snappy)
Да вроде бы он достаточно простой — LZ77 + энтропийное сжатие (тут не помню какое). Блоки, думаю как и в 7zip — при 1-2 тредах — потоковый, при большем количестве — независимые.
Делают. Ибо это аццки быстрее. Смотрите на LZ4, Snappy, LZO, QuickLZ и прочие. Это получается практически бесплатное архивирование при хорошем результате.
На них, как раз и проблема. Представьте для простоты файл в миллиард нулей. Сжимается в условные 5 байт (повторить миллиард раз ноль). С блоками у вас будет — повторить размер блока ноль. В реальности, это копейки, правда.
Или вы фигню говорите, или в вашем понимании куски являются последовательностью, а не блоками. И классического Хаффмана (Дефри-Халман — это что-то среднее из Хаффмана и Диффи-Хеллмана, т.е. вообще не по делу), никто не использует. Обычный однопроходной энтропийный алгоритм.