The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Эксперимент с использованием SQLite в качестве контейнера для архивирования файлов

25.03.2024 12:39

Проект Pack предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLite и алгоритма сжатия ZSTD (Zstandard). Подготовленный прототип, написанный на языке Pascal и распространяемый под лицензией Apache 2.0, обогнал по скорости создания архивов наиболее распространённые архиваторы, при том, что его работа сводилась к чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLite.

При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ, pack оказался быстрее утилиты ZIP в 112 раз, выполнив операцию за 1.3 секунды против 146 секунд у ZIP. Размер архива при этом у pack получился на 23% меньше (194 MB у Pack и 253 MB у ZIP). Для сравнения утилита tar выполнила упаковку за 4.7 секунды без сжатия и за 28.5 секунд со сжатием методом gzip, архиватор RAR справился с тестом за 27.5 секунд, а 7z за 54.2 секунды. Размер архивов составил: tar.gz - 214 MB, RAR - 235 MB, 7z - 135 MB. Отмечается, что по скорости распаковки и случайного доступа к файлам Pack также опережает другие архиваторы, потребляя при этом меньше оперативной памяти.


   ZIP:     253 MB,  146 s      
   7z:      135 MB,  54.2 s     быстрее ZIP в 2.7 раза
   tar.gz:  214 MB,  28.5 s     x 5.1
   RAR:     235 MB,  27.5 s     x 5.3
   tar:    1345 MB,  4.7 s      x 31
   Pack:    194 MB,  1.3 s      x 112

Про влияние файлового кэша на результаты проведения теста не упоминается. Вероятно, низкая скорость ZIP обусловлена порядком запуска тестов без оглядки на кэширование данных в памяти - тест с zip был запущен при холодном кэше, а остальные тесты при прогретом. В обычных условиях Zstandard демонстрирует в 3-5 раз более высокую скорость сжатия по сравнению с zlib и в два раза более быструю распаковку, при уровне сжатия выше на 10-15%.

Дополнение: Похожая идея хранения сжатых файлов в виде блобов в БД SQLite реализована в 2014 году в архиваторе sqlar, созданном разработчиками SQLite в качестве эксперимента для оценки эффективности хранения блобов в SQLite. В sqlar для сжатия применяется zlib и размер файлов примерно на 2% больше, чем у утилиты ZIP.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Автор LZ4 представил новый быстрый и эффективный алгоритм сжатия ZSTD
  3. OpenNews: Представлен формат сжатия изображений QOI
  4. OpenNews: Redbean 2.0 - платформа для web-приложений, упакованных в универсальный исполняемый ZIP-архив
  5. OpenNews: Выпуск архиватора RAR 7.0
  6. OpenNews: Facebook опубликовал реализацию алгоритма сжатия Zstandard 1.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60842-pack
Ключевые слова: pack, sqlite, zstd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (109) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Guest (??), 12:51, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А почему бы не исолпльзовать tar с zstd? Ну и для 7z где-то были эксперименты с zstd.
     
     
  • 2.56, Lui Kang (?), 19:07, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Степени сжатия 7z можно достичь, используя xz, который по-умолчанию обычно уже есть в системе и tar умеет создавать tar.xz, а 7z потребует отдельной установки. xz и 7z оба используют алгоритм LZMA2 по умолчанию. Но если сравнивать что круче в одних и тех же условиях, zstd или LZMA2, то всегда зависит от самих файлов.
     
     
  • 3.95, _oleg_ (ok), 13:46, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    tar умеет создавать всё и всегда: tar -c .... | xz > file.txz


    ;-)

     
     
  • 4.105, гыгы (?), 14:00, 28/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    тем временем:
         -J, --xz
                 (c mode only) Compress the resulting archive with xz(1).  In
                 extract or list modes, this option is ignored.  Note that this
                 tar implementation recognizes XZ compression automatically when
                 reading archives.
    tar(1)
    P.S. ;-)
     
     
  • 5.106, _oleg_ (ok), 15:16, 28/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > тем временем:
    >      -J, --xz

    Что ты этим хотел сказать?


     
     
  • 6.109, гыгы (?), 13:34, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> тем временем:
    >>      -J, --xz
    > Что ты этим хотел сказать?

    а ты догадайся.
    подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar

     
     
  • 7.110, _oleg_ (ok), 13:40, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>> тем временем:
    >>>      -J, --xz
    >> Что ты этим хотел сказать?
    > а ты догадайся.
    > подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar

    :FACEPALM: Возьми с полки пирожок. Дальше-то что? Раскрой свою мысль. Или тебя похвалить, что ты способен скопировать часть текста из man-страницы?

     
     
  • 8.111, Аноним (111), 15:26, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Похвали, конечно Трудно что ли ... текст свёрнут, показать
     
     
  • 9.112, _oleg_ (ok), 15:39, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да что это я, действительно Молодец ... текст свёрнут, показать
     
  • 8.113, гыгы (?), 11:19, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    мысль проста вые ся нужно уметь ты - не умеешь хотя, если ты из банды cat som... текст свёрнут, показать
     
     
  • 9.114, _oleg_ (ok), 12:59, 16/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Аха - Мда Скопировал кусок man а, выдал какую-то невероятную мысль Что хоте... текст свёрнут, показать
     
  • 5.108, anonymous (??), 21:01, 31/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это тоже самое.
     

  • 1.2, Аноним (2), 12:55, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Победил 7z. Пофиг, что затратил 54.2 с, зато сильнее всех пожмакал.
     
     
  • 2.28, Аноним (28), 14:07, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    В современных реалиях быстрее будет чуть больше скачать, но быстрее распаковать
     
     
  • 3.53, Аноним (53), 18:21, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Да не факт! Вы что, из америки где "везде есть интернет, электричество и паркинг"?? Люди могут и на 8Мбит сидеть - им не нужны ГИГАБАЙТЫ инфы, которую кто-то никак не может сжать.
     
     
  • 4.75, tty0 (?), 23:23, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мы из России. Тут интернет плохой в небольших удаленных поселках. Но 1МБ/с -- это вообще вполне сносно и не напряжно в рамках дачного поселка в 30км от города.
     
  • 2.42, Аноним (42), 17:11, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сомнительное соотношение скорости сжатия к размеру файла и скорости скачивания. У меня 100 мегабит етхернета быстрее работает чем большинство флешек лет 10 назад.
     
  • 2.60, Аноним (60), 20:06, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда уж xz. Только там еще дольше)
     
     
  • 3.62, Аноним (62), 20:11, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там тот же lzma только в формате потока, поточные компрессоры всегда будут давать результат хуже архиватора и иметь меньшую гибкость, но например они позволяют сжать тарбол со всеми атрибутами в него сохранёнными. Конечно, 7z/rar тоже позволяют запаковать тарбол, но они являются архиваторами со своей по-файловой логикой и тут стоит проверить здоровье.
     
  • 2.61, Аноним (62), 20:08, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    7z не дедуплицирует данные, поэтому годится только для маленьких и скучных наборов (без расширенных атрибутов, тегов, времени изменения/доступа и прочего подобного). А результат на пару килобайт лучше достигается совершенно дефективным форматом файла.
     
     
  • 3.72, fuggy (ok), 22:46, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ему это не надо, он это умеет на уровне алгоритма словаря с параметром qs. Если словарь достаточного размера. Умеет атрибуты NTFS потоки. С атрибутами файла есть недостатки, потому что 7z не совсем из мира unix way.
     
     
  • 4.73, Аноним (62), 22:50, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если словарь достаточного размера. Типичный архив в него не влезает, кроме того, ресурсов намного больше необходимо (и для упаковки и для распаковки) и в многопотоке прогрессия там не очень приятная.
     

  • 1.3, Аноним (3), 12:58, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Джипеги же жали, да?))
     
  • 1.4, GhostX (?), 13:00, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    rar одного размера с zip?
    Подозрительно. rar обычно лучше сжимает.
     
     
  • 2.10, ануснимус (?), 13:14, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Разный же! 253 и 235 Мб
     

  • 1.5, Аноним (3), 13:04, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В отрыве от возможностей в мейнстриме это всё весело, но довольно бессмысленно.
    Отдельно интересно посмотреть бенчмарк всех этих весёлых алгоритмов на разных типах данных и на разных выборках (например, что если нужно извлечь только один файл из сета, либо обновить один файл)
     
     
  • 2.14, человек (??), 13:19, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С одной стороны соглашусь, с другой нет. SQLite поставляется во всех массовых дистрибутивах систем и языков программирования, и сделать возможность создания такого арзива достаточно легко и не требует наличия специфических зависимостей, так что жизнь у проекто точно возможна, но как мы знаем, это далеко даже не 25%.

    Сколько проектов всяких интересных по сжатию умирало из-за отсутствия поддержки в меинстриме

     
     
  • 3.18, Аноним (18), 13:35, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скулайт он как питон, второй лучший вариант в любой сфере. Только тут задачи применимые к базе данных. Но всегда есть первый вариант.
     
  • 3.84, Аноним (84), 02:38, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >pickle поставляется во всех массовых дистрибутивах Python, и сделать возможность создания такого файла с сериализацией достаточно легко и не требует наличия специфических зависимостей

    Отлично, давайте использовать везде pickle, зачем нам какие-то JSON, CBOR, npy, safetensors, ведь это надо код писать, а тут всё в стандартной библиотеке! Давайте выпилим из либ код ненужных сериализаций и десериализаций, и будем просто использовать pickle!

     
  • 2.54, Аноним (53), 18:27, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тут нечего смотреть! Бенчи Сыкулита будут ±1% от того архиватора, который под капотом (на ЕДИНИЧНЫХ файлах). Главное - такой формат позволяет БЫСТРЫЙ доступ к любому файлу, что может быть полезно для каких-нть утилит синхронизации или просто "обновление бэкапа".
     

  • 1.6, Аноним (3), 13:06, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вообще они немножко опоздали, таких штук было уже навалом
    https://github.com/phiresky/sqlite-zstd
     
     
  • 2.9, YetAnotherOnanym (ok), 13:10, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Душнила. Весь кайф поломал :D
     
  • 2.13, Аноним (13), 13:17, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В новости речь про воссоздание архиватора на базе SQLite, а sqlite-zstd - дополнение для прозрачного сжатия записей в SQLite.
     
  • 2.27, Аноним (27), 13:47, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну раз пошла такая пьянка ...  https://codeberg.org/KOLANICH-libs/Cache.py
     

  • 1.7, Аноним (7), 13:09, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жду реализации для http-статики =) в духе времени будет
     
     
  • 2.37, Алкоголизм (?), 15:02, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для веб-архивирования. Как раз есть аддон SingleFile, который выгружает все ресурсы страницы (стили/графику), и инлайнит её в html, кодируя в base64. И есть на его базе отдельный SingleFileZ, который формирует zip-архив, и аналогичным образом вкладывает в html-страницу вместе со скриптом на js для распаковки и рендера.
    Тут можно сделать что-то подобное, но вложив в html-страницу БД SQLite, и скрипт для доступа к ней. С поддержкой сжатия БД.
    Хотя бы в рамках эксперимента и веществ.
     
  • 2.97, fuggy (ok), 15:41, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://wiki.openzim.org/wiki/ZIM_file_format со сжатием, есть просмотрщики. При этом всё умно по категориям ресурсов распихивает, а не тупо в Base64 кодирует.
     
     
  • 3.102, merv (?), 21:59, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Только нет вменяемых средств создания.
     

  • 1.8, YetAnotherOnanym (ok), 13:09, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ, pack оказался быстрее утилиты ZIP в 112 раз, выполнив операцию за 1.3 секунды против 146 секунд у ZIP

    Подозреваю, первым замерили скорость zip, и файлы он читал с диска, а после него запустили pack и файлы он брал из кэша. Ничем другим такую разницу объяснить невозможно.

     
     
  • 2.86, Аноним (86), 09:06, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То, что Pack оказался настолько быстрее Zip-а, конечно, подозрительно, но пусть (разные алгоритмы сжатия с многопоточность ю в Zstd и т.п.). Но то, что tar.gz с Deflate оказался в несколько раз быстрее, чем Zip с таким же Deflate (размер тарболла оказался даже несколько меньше, т.е. дело явно не в разных степенях сжатия), лично для меня является более серьёзным аргументом в пользу неправильно проведённого теста.
     

  • 1.11, Аноним (11), 13:15, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    "тест с zip был запущен при холодном кэше, а остальные тесты при прогретом"
    Серьёзно? Это ведь эпичнейшая фейспальма!
     
     
  • 2.16, Аноним (62), 13:27, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы дропнуть кэши надо записать 1 байт в специальный файл, очень сложно. Да и в чёрной-чёрной консоли, очень страшно! У нас тут дружелюбный паскаль. Но вообще, без указания версий и параметров это ни о чём. Поразительно низкое качество подачи материала, тот случай, когда со дна постучали.
     
  • 2.25, тоже Аноним (ok), 13:44, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это очень важный пункт эксперимента.
    Он наглядно демонстрирует, насколько стоит доверять всем остальным намерянным циферкам.
     
     
  • 3.30, Аноним (-), 14:15, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не на то смотришь. Если в намеренных данных не указаны ни доверительные интервалы, ни дисперсия, то не данные и были, кто-то просто нарисовал цифры от балды. Если есть, то следующий этап -- это исходные данные, на которых считались статистики или скрипт, который эти данные получает. Либо это есть, и вот тогда можно подумать над результатами статистики и как-то интерпретировать их, либо этого нет, тогда думать не о чем.
     
  • 3.44, Аноним (44), 17:22, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо хоть что сами дали себе явную оценку в тестах. Хотя по результата и так ясно что авторы в полном неадеквате
     

  • 1.12, Аноним (12), 13:16, 25/03/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     
  • 1.15, Аноним (15), 13:24, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Разве это не просто альтернативная реализация идеи https://www.sqlite.org/sqlar/doc/trunk/README.md ?
    > This repository contains sources for the "SQLite Archiver" program. This program (named "sqlar") operates much like "zip", except that the compressed archive it builds is stored in an SQLite database instead of a ZIP archive.

    Причём sqlar аж 2014 года.

     
  • 1.17, Аноним (18), 13:32, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Скулайт итак мало для чего пригоден, так он теперь ещё и плохой архиватор.
     
     
  • 2.19, Аноним (12), 13:35, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в докер надо засунуть, тогда будет норм
     
     
  • 3.31, Алексей (??), 14:32, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    libsql
     
     
  • 4.32, НяшМяш (ok), 14:44, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    systemd-sqlited
     

  • 1.20, Аноним (20), 13:37, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLite

    SQLite by design умеет исполнять произвольный код, поэтому даже просто открывать недоверенные SQLite-базы небезопасно.

     
     
  • 2.52, Аноним (53), 18:19, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Извините, но что это за uдuотская фича - исполнять код?? Это в смысле "брешь" в обработке файлов или это прямо специально реализованная фича?
     
     
  • 3.64, Прадед (?), 21:29, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Споткнулся и выполнил
     
  • 3.71, Аноним (84), 22:32, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Штатная фича - https://www.sqlite.org/lang_createview.html . VIEW - эта такая типа таблица, но когда из неё SELECT делаешь, то выполняется код, который при создании VIEW указали. Что-то вроде хранимой процедуры. Через них некоторый софт, который использует базы, можно эксплуатировать.

    Ещё в SQLite можно умышленно подредактировать контролируемым образом базу через редактирование служебных таблиц https://www.sqlite.org/schematab.html . Это можно прикрыть на уровне либы путём флагов ... но ведь скачанный с инета файл может быть сделан не твоей обмазанной флагами либой, а вообще форком.

    В общем ещё свежа память о том, как веб-страничкой с SQL-кодом, заточенным под эксплуатацию SQLite, Хром ломали (у него был API WebSQL на основе движка SQLite с навесными защитами).

     
     
  • 4.77, tty0 (?), 23:27, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы меня пугаете. Программные хуки в SQLite выполняются софтом.
     
     
  • 5.79, Аноним (84), 23:52, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Хромому они не помогли.
     

  • 1.21, Аноним (27), 13:40, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >сжатию библиотекой libzstd

    Напоминаю - zip -это контейнер, и туда могут быть добавлены произвольные компрессоры. Просто большинство реализаций не смогут распаковать архивы с компрессией, отличными от zlib, lzma и lzma2.

     
     
  • 2.24, Аноним (27), 13:44, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    даже PPMD очень не везде поддерживается. В качестве реализации рекомендую https://github.com/mcmilk/7-Zip-zstd
     
     
  • 3.29, fuggy (ok), 14:10, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ppmd уже давно поддерживается в 7z. Или ты смешивает ppmd и zstd.
     
     
  • 4.33, Аноним (33), 14:45, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    в 7z - да, а вот во многих других реализациях помимо store и zlib в лучшем случае lzma2 поддерживается, а не полный комплект компрессоров. В питонью реализацию с помощью monkey-patchingа можно любой компрессор впрячь, и пакеты есть, но это всё же не приложение для конечного пользователя.
     
     
  • 5.59, Аноним (62), 19:59, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    По скорее бы завезли zstd в info-zip, уже много лет как zip поддерживает zstd  в стандарте. И zstd определённо предпочтительнее lzma по всем параметрам (а по многим и предпочтительнее deflate). А вот 7z что-то сдулся, теперь везде RAR и он не такой томозной и дефективный (даже больше линуксовых данных о файле поддерживает).
     
     
  • 6.68, Аноним (84), 21:53, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мне плевать на "тормозной" до тех пор, пока замедление адекватно сжатию. У lzma2 оно адекватно, самое лучшее сжатие, что получал (на нужном наборе данных) - у brotli, просто бротли надо с песней компилировать и устанавливать на некоторых системах, а lzma из коробки идёт. zstd - это просто модно, юзаю его исключительно из-за наличия API для кастомного словаря в питоновском пакете (у lzma нет в пакете этого API). Но, как я уже сказал, хотя у brotli убрали вообще возможность юзать кастомный словарь в питоновском пакете, он жмёт лучше, чем zstd с шарингом словаря между записями. Поэтому, если есть возможность юзать бротли - то юзайте его.
     
     
  • 7.74, fuggy (ok), 22:55, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Чего не хватает в 7z так это больше фильтров для разных типов файла как в winrar. Сейчас он имеет фильтры только для исполняемых файлов и wav.
    Ещё фичей являются произвольные настраиваемые sfx модули. Куда можно встроить полноценный гуи или консольный установщик.
     
     
  • 8.76, Аноним (62), 23:24, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так у 7z тот же brunsli для картинок есть уже много лет Как по мне, главная фич... текст свёрнут, показать
     
     
  • 9.78, fuggy (ok), 23:34, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я хочу это чтобы было в стандартной поставке Стратегии это по сути и есть препр... текст свёрнут, показать
     

  • 1.22, Аноним (22), 13:41, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где сравнение с утилитой zstd?
     
  • 1.23, Аноним (23), 13:42, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть такой проект, Pigz называется, тотже gzip, но распаралленый. Быстро работает.
     
     
  • 2.34, НяшМяш (ok), 14:49, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Плохо, что всё время забываешь -I pigz к tar подкидывать. Его уже надо бы по-умолчанию подхватывать, если установлен.
     
     
  • 3.36, Аноним (36), 15:01, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сделай его системным.
     
  • 2.40, Аноним (40), 16:44, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    pbzip2 тоже, но чуть лучше жмёт и при распаковке контрольную сумму проверяет.  
    mksqushfs тоже неплох с дефолтным lz4 сжатием.
     

  • 1.35, topin89 (ok), 14:56, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ

    Лучше пользоваться https://github.com/mhx/dwarfs. И сжимает мощно, и вместо распаковки можно просто смонтировать.
    Можно и lrzip или lrzip-next.

    Если бы в Pack был бы precomp или аналоги -- это уже было бы круто, и позволило бы сжать джипеги процентов на 20. Очень не хватает подобной штуки в потребительских архиваторах.

    А так вообще непонятно, чем именно оно лучше tar+zstd.

     
     
  • 2.38, Аноним (38), 15:21, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >read-only
     
  • 2.47, Аноним (47), 17:54, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А так вообще непонятно, чем именно оно лучше tar+zstd.

    Прежде всего тем, что может вытащить ЛЮБОЙ файл за минимальное время.

     
     
  • 3.51, Аноним (44), 18:11, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не, нужно так писать

    > Прежде всего тем, что МОЖЕТ вытащить ЛЮБОЙ файл за МИНИМАЛЬНОЕ время.

     
  • 2.104, непонятка (?), 06:26, 27/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А этот dwarfs в качестве хранилки библиотеки сойдет?
     
     
  • 3.115, topin89 (ok), 13:04, 17/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А этот dwarfs в качестве хранилки библиотеки сойдет?

    В целом да. Но если данные сами по себе плохо сжимаются, то проще как есть в папках хранить. Всё-таки это read-only fs, докидывать новые файлики будет трудно

     

  • 1.39, Аноним (-), 16:44, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Давно ищу архиватор/способ чтоб в архиве сохранялась дата создания(через stat это Birth) и изменения файлов(через stat это Modify), дописывать в имена файлов не вариант. В "окошках" все популярные форматы это умеют, а в более продвинутой ОС это не работает. Да ну не может быть подумал я .. какая же это была ошибка, ну вот нет такого.

    Долгие поиски и.. последняя надежда на 7z после выкатывания исходников для сборки от автора, но он продолжил стандартную "подлянку" с "Change" вместо "Birth", автору писал "не баг, а фича". Я пытался разобраться в исходниках и сделать нормальное поведение, как заявлено в документации, нуу и не смог.. Если кто-то знает где это правится, поделитесь пожалуйста, можно патчем. Или может другой способ какой рабочий.

     
     
  • 2.46, Аноним (47), 17:53, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если сам формат файла хранит только ОДНУ дату, вряд ли ты сможешь туда засунуть вторую! (это так, мысли вслух) Спроси автора, может он идею какую подкинет (писать дату в комменты или что-то подобное).
     
  • 2.48, Аноним (48), 18:00, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > а в более продвинутой ОС это не работает. Да ну не может быть подумал
    > я .. какая же это была ошибка, ну вот нет такого.

    Это в какой именно "более продвинутой"?
    А то у лапчатых например Birth был долго "нинужна!" (ext2/3/4) - оттуда и отсутствие у многих утилит вменяемой поддержки.

     
     
  • 3.50, Аноним (48), 18:06, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> а в более продвинутой ОС это не работает. Да ну не может быть подумал
    >> я .. какая же это была ошибка, ну вот нет такого.
    > (ext2/3/4)

    Тьфу, 4 там лишняя. Но пингвинячий stat() таки традиционно не поддерживает b_time.

     
  • 2.57, Аноним (62), 19:54, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не так и давно, поддержку birth иноды не столь и полезная для архивации информа... большой текст свёрнут, показать
     
     
  • 3.66, Аноним (66), 21:49, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>7z
    >Oн вообще не сохраняет никакие линуксовые параметры файла, возлагать какие-либо надежды

    Неужели вы до сих пор путаете архиватор с компрессором?
    Использую для архивации *.tar.7z - что я делаю не так?

     
     
  • 4.70, Аноним (70), 22:09, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> и в частности индексированный tar позволяет получить быстрый произвольный доступ к сжатым данным,
    > Использую для архивации *.tar.7z - что я делаю не так?

    Обрати внимание на "быстрый произвольный доступ к сжатым данным".

     

  • 1.41, Аноним (42), 17:09, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Я тут уже лет 10 пишу, что с появлением твердотельников будущее за файловыми системами на основе хешей и БД.
     
  • 1.45, Аноним (47), 17:51, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLite

    Это имеет смысл только на конкретных юзкейсах "имеем один большой архив и периодически обновляем там некоторые файлы".
    Для простых бэкапов (где критична степень сжатия) нужен сжимальщик, который учитывает ВЕСЬ контент - типа 7z (solid архивы).

     
  • 1.49, Аноним (49), 18:02, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оверинженеринг
     
     
  • 2.58, Аноним (58), 19:57, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прелестный эксперимент. Чтоб подумать над результатом. :)
     

  • 1.55, O (?), 18:56, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Здравствуйте,

    I am the author of Pack, and I am happy to see you all interested in Pack. I am sorry for writing in English; my understanding of Russian is limited to that Здравствуйте.
    I try to answer most of the comments here, but if you have any further questions or comments, let me know or email me (you can find it in the linked post).

    Warm or Cold:
    On the linked post (https://pack.ac/note/pack), there is a line noting the test condition: "All corresponding official programs were used in an out-of-the-box configuration at the time of writing in a warm state."
    Please note that for ZIP, the official tool is WinZip and I tried the test many times to find the best warm time and remove any file system and disk interference.
    As noted in the post, you should test it for yourself. The numbers were not as "Look, others are bad". They are great; my point was, "Look what we can do if we update our design and code"

    Random access (extracting one):
    You can do that with Pack:
    'pack -i ./test.pack --include=/a/file.txt'

    or a couple files and folders at once:
    'pack -i ./test.pack --include=/a/file.txt --include=/a/folder/'

    Use '--list' to get a list of all files:
    'pack -i ./test.pack --list'

    Such random access using '--include' is very fast. As an example, if I want to extract just a .c file from the whole codebase of Linux, it can be done (on my machine) in 30 ms, compared to near 500 ms for WinRAR or 2500 ms for tar.gz. And it will just worsen when you count encryption. For now, Pack encryption is not public, but when it is, you can access a file in a locked Pack file in a matter of milliseconds rather than seconds.


    Is it a compressed database?:
    No. It is a container for files and raw data. Projects like sqlite-zstd are for any database for your projects. They are not made for files.

    sqlar:
    Pack is a new format. sqlar inspired me to create Pack as a new improved solution.
    Here is the latest sqlar result on Linux source code on the same test machine in warm state:
    sqlar: 268 MB, 30.5 s
    Pack: 194 MB, 1.3 s

    SQLite security:
    It is one, if not the most secure, library out there. It is very hard to crack it, and it will not allow running any harmful code on a machine. It is used in almost anything with a computer, partially because of its security and reliability.


    File system:
    Noted projects like dwarfs are file systems.
    It is read-only; Pack is not. Update and delete are not just public yet, as I wanted people to get the taste first.
    It is clearly focused on archiving, rather than Pack wanting to be a container option for people who want to pack some files/data and store or send them with no privacy dangers.

    Big files instead of many small files:
    Reading many files (81K in this test) is way slower than reading just one big file. For bigger files, Pack is much faster. Here is a link to some results from a kind contributor: https://forum.lazarus.freepascal.org/index.php/topic,66281.msg507177.html#msg507177
    (Too long to post here)

    tar.zst:
    As requested, here are some numbers on tar.zst of Linux source code (the test subject in the note):
    tar.zst: 196 MB, 5420 ms (using out-of-the-box config and -T0 to let it use all the cores. Without it, it would be, 7570 ms. And it is done in two steps: first creating tar and then compression.)
    Pack: 194 MB, 1300 ms Slightly smaller size, and more than 4X faster. (Again, it is on my machine; you need to try it for yourself.)
    Honestly, ZSTD is great. Tar is slowing it down (because of its old design and being one thread).
    Pack does all the steps (read, check, compress, and write) together, and this weaving helped achieve this speed and random access.

    Rate of compression:
    7-Zip and other similar tools are focused on compression rate. Pack is on another chart, which is why I proposed CompressedSpeed [2]. The speed of getting to compression needs to be accounted for. You can store anything on an atom if you try hard enough, but hard work takes time. Deduplication step may get added, but in Hard Press [3].

    RAR compression speed is great too. Many times, it can do better than Pack. My argument is that does it worth the wait? After all, if you can use Pack for those cases too,. Hard Press [3] creates a more compressed pack for cases of pack once, unpack many.

    [1] CompressedSpeed = (InputSize / OutputSize) * (InputSize / Speed). Materialized compression speed.
    [2] You can choose --press=hard to ask for better compression. Even with Hard Press, Pack does not try to eat your hardware just to get a little more; it goes the optimized way I described.

    User experience:
    Pack value comes from user experience, and speed is being one. I was not following the best speed or compression; I wanted an instantaneous feeling for most files. I wanted a better API, an easier CLI, improved OS integration (soon), and more safety and reliability.


    On a final note, I suggest trying Pack for yourself and on your machine. I will be glad to hear more about your experience.
    Thank you

     
     
  • 2.63, Аноним (84), 21:23, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https www blackhat com docs us-17 wednesday us-17-Feng-Many-Birds-One-Stone-Ex... большой текст свёрнут, показать
     
     
  • 3.65, Аноним (84), 21:32, 25/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    And forgot to add:
    * For the purpose of this paragraph let's assumme that SQLite when built with maximum hardening is secure ... Even if you use maximum source-level hardening options of SQLite, it would limit your software to 2 options: statically linking the SQLite lib with thisenoptions, or dynamically linking an additional variant of SQLite lib living in a separate package. Some distro maintainers can forget about this security measure and just link the usual distrowise SQLite lib optimized for performance and special tasks like schema manipulation ... creating this way a vulnerability. So mere using SQLite for the task it is unsuitable for introduces a weak point.
     
     
  • 4.80, O (?), 00:55, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    All are an will be statically linked. They are not considered a shared library to the program, but part of the source.
     
     
  • 5.82, Аноним (84), 02:21, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Noone sane uses statically-linked libs and sane distros would never accept anyth... большой текст свёрнут, показать
     
     
  • 6.87, Аноним (62), 10:43, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты просто не пользовался скулайтом, он примерно всегда бандлится. Или не заметил. Ну и все мейнтейнеры жрут, что им навалят разрабы, странный аргумент. Потому что шляпа вроде ffmpeg или libvpx регулярно ломает совместимость, но узнаешь ты об этом только когда пользователи начнут ныть (подход компилируется значит работает очень популярный у мейнтенеров). Или другой пример именно статически линкуемого компонента неизвестной версии это zlib.
     
     
  • 7.89, Аноним (89), 13:07, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У неадекватов всё подряд бандлится, причём с обоснованием уровня а вот я тут гл... большой текст свёрнут, показать
     
     
  • 8.93, Аноним (62), 13:24, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не в этом Лучше смотри на это с позиции когда мейнтенеры не будут возиться... большой текст свёрнут, показать
     
     
  • 9.96, Аноним (96), 14:40, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, есть такая проблема И это проблема в том числе самого SQLite Слишком много... большой текст свёрнут, показать
     
  • 6.90, O (?), 13:12, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Hey

    I am sorry that you think like that. Not much tracking, rather shared with me on the Lazarus forum (IDE I sued for developing Pack), and I thought clearing some points may help some others.

    I can explain more and correct your mistaken statements, but because of your way of talking, I think it won't help.

     
     
  • 7.94, Аноним (89), 13:30, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    I can give you a simple advice that will fix all issues in your format: just admit that it was an extremily bad idea to promote it as an archive format and put noticable warnings about that everywhere: on official webpages, in git repo, etc. For the uses that don't promote it as an archive format, but as a key-value store for a local use only in a pretty trusted setup ... there are plenty of solutions, and no hype around them.
     
  • 3.83, Аноним (84), 02:33, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Some moar things I forgot to add If this format gets adoption, insecure imple... большой текст свёрнут, показать
     
     
  • 4.92, O (?), 13:24, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Thank you for the interest.

    - As long as they use the official work, it will be securely checked and verified.
    - If anyone attempts to rewrite, they need to take security seriously too. Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official.
    - One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable.


    - SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_delete

    - Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it.

     
     
  • 5.98, Аноним (98), 15:58, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    The fast variant doesn t guarantee cleanup The slow one results in additional I... большой текст свёрнут, показать
     

  • 1.67, BrainFucker (ok), 21:52, 25/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Предпочитаю squashfs для архивирования. У него встроенное сжатие, но главное можно примонтировать и читать файлы с произвольным доступом без необходимости распаковывать весь архив.
     
     
  • 2.100, Аноним (100), 18:13, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Рекомендую dwarfs, он лучше
     
     
  • 3.101, BrainFucker (ok), 20:33, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Рекомендую dwarfs, он лучше

    Ок, подождём лет десять, как появится в репах дистрибутивов и если проект не будет заброшен, можно будет попробовать.

     

  • 1.88, DZgas (?), 11:39, 26/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
      👍 прект наебалго, разница скорости между Ним и 7zip zstd примрено 15% по скорости, то есть, проект pack не создаёт ни хэша файла, ни фаловой иерархии внутри. И поэтому на примерно 15% быстрее
     
     
  • 2.91, O (?), 13:17, 26/03/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    File hierarchy is implemented using recursive ID. In Item table, every Item gets linked to its parent by Parent field. On unpacking, they will be queried and verified.

    The hash of any compressed data is already stored and verified at the unpack step. It does not have an extra field, as it is stored together with the content.

    Each file or piece of data gets separated and/or joined with others as content, then compressed if seen as beneficial. Zstandard (the internal compression algorithm) uses xxHash together with a header to verify decompression.

    On unpacking, all needed Items (files or folders) get queried and checked, followed by all the ItemContents and related Contents. Each gets verified to be the correct size to prevent invalid memory access, and if decompression is needed, they will be double verified with their corresponding hash.

     

  • 1.103, Аноним (103), 06:15, 27/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В 7z мне не хватает CRC.
     
  • 1.107, mumu (ok), 16:01, 28/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    некорректный дизайн теста. паскаль. no comments
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру