Сжатие и предоставление доступа к 10 миллионам файлов одним файлом

347
Denis Kulagin

У меня ~ 10 миллионов небольших текстовых файлов, и я хотел бы решить следующие задачи:

  • сжать все данные;
  • положить все это в 1 файл для передачи через Интернет;
  • иметь возможность быстро получить доступ к каждому файлу по заданному пути;
  • (обновить) отдельные файлы, которые будут легко доступны из экосистемы Python.

Я придумал следующее решение:

  • gzip каждый файл (сжатие);

  • добавьте все сжатые файлы в один архив:

    single.tar -> /1/100/1001451.gz ... -> /9/956/9562548.gz

Решает ли это мои задачи?

0
Если ваш фактический вопрос «моя идея решает мою задачу», то кажется, что вы в лучшем положении, чтобы ответить на него. Просто попробуйте и посмотрите, а потом расскажите нам. Если ваш вопрос - что-то еще, пожалуйста, укажите это в вопросе. Просто бросить это там для комментариев - слишком открытый конец для сайта. fixer1234 5 лет назад 1

1 ответ на вопрос

4
Eugen Rieck

Я думаю, что может быть лучше, чтобы решить эту проблему: tar, zip, и rarт.д. все доли собственности (в некоторой степени Diferent), что доступ к одному файлу является

  • не очень быстро
  • непрозрачный: вы не можете просмотреть его напрямую, но нужно распаковать его в другом месте, а затем просмотреть его

Однако есть одна альтернатива: использовать сжатый файл изображения с файловой системой (например, cloopи ext4) или простой файл изображения со сжатой файловой системой (например squashfs) - я обычно использую последний.

Таким образом, вы можете переместить ваш файл через Интернет, а в целевой системе непосредственно смонтировать его и получить быстрый и прозрачный доступ к файлам в нем.

РЕДАКТИРОВАТЬ

Что касается необходимости обновления файлов: у меня возникла та же проблема, и я решил ее с помощью mksquashfsи overlayfs. Измененные файлы попадают в оверлей, оригиналы остаются в неизмененном транспортном файле (я считаю это важной функцией)

Я бы сказал, что файловые системы и форматы архивов работают здесь почти одинаково и имеют одни и те же общие свойства, различающиеся только эффективностью поиска пути. (Очень эффективно в таких форматах, как ext4, приемлемо в таких форматах, как Zip, у которых есть центральный линейный индекс, плохо в Tar, у которого вообще нет индекса.) Особенно когда дело доходит до форматов с однократной записью, таких как squashfs, кажется, что они различаются только случайным образом. получить доступ к файлу _win (Zip требует распаковки всего файла, squashfs позволяет распаковывать отдельные блоки), но они почти одинаковы при извлечении всего файла сразу. grawity 5 лет назад 0
squashfs всегда быстрее, потому что он находится в пространстве ядра, а zip - в пространстве пользователя; и вы должны вызывать сам бинарный файл распаковки при каждом доступе, что намного сложнее, чем простая функция open. Ipor Sircer 5 лет назад 0
@IporSircer: Kernelspace не делает вещи быстрее. Он работает на том же процессоре с той же скоростью. Что ускоряет работу, так это хорошо продуманный формат / структура (squashfs действительно гораздо более оптимизирован), кеширование метаданных и - как вы заметили - отсутствие необходимости запускать новый процесс и перечитывать архив каждый раз ... но это предполагает, что порождение `unzip` - единственный другой вариант. Это не так: многие языки программирования имеют встроенную поддержку формата Zip (реже Rar и 7z). grawity 5 лет назад 0
Хорошее решение, но не очень дружелюбное к нетехнической аудитории, знакомой только с Python. Обновил вопрос, хотя. Denis Kulagin 5 лет назад 1
@grawity: вы забыли много скомпилированных функций безопасности от gcc, например, стековая защита, пирог; плюс в настоящее время обходные пути призрака / расплавления, которые только замедляют программы пользовательского пространства. Таким образом, тот же алгоритм еще быстрее в пространстве ядра в реальности. Ipor Sircer 5 лет назад 0
@DenisKulagin: смонтировать squashfs в папку, и неопытный пользователь не заметит никакой разницы, кроме непосредственного открытия локального файла. Ipor Sircer 5 лет назад 2
@DenisKulagin Красота файловой системы в качестве уровня абстракции заключается в том, что когда вы монтируете один, ее файлы доступны для * любой * экосистемы / программы / независимо от того, что может иметь дело с файлами. Очень Unix-й подход. Kamil Maciorowski 5 лет назад 0
@IporSircer: ядро ​​моего дистрибутива, похоже, также скомпилировано с STACKPROTECTOR_STRONG. Временные решения для расплавления замедляют переключение контекста ядра и пользователя, и как полностью пространство ядра, так и полностью пространство пользователя остаются одинаково незатронутыми. Спекуляционные меры смягчения применяются главным образом к коду ядра. grawity 5 лет назад 0
Еще раз повторю: скорость доступа к одному файлу зависит от используемого формата - tar очень медленный, другие гораздо быстрее. Ни один не так быстр, как файловая система. Но это менее важный момент: то, что я считаю более важным, - это прозрачность: смонтируйте FS, и каждый инструмент, который вам нужен, может получить к нему прямой доступ, даже не заметив, что он взят из транспортного файла. Eugen Rieck 5 лет назад 3
Что касается дружественности к пользователю: `mksquashfs` не сложнее, чем` tar`, если ваши пользователи не могут с этим справиться, вы можете просто обернуть его в скрипт оболочки и полностью автоматизировать процесс. Eugen Rieck 5 лет назад 1
Относительно удобства для пользователя: это мало что говорит, учитывая, что tar часто является предметом многих шуток о «тайных инструментах Unix». Я согласен с общей идеей возможности смонтировать архив как файловую систему ([см. Также] (https://github.com/tmbdev/archivefs)), но не похоже, что OP фактически упомянул Linux как целевая ОС ... grawity 5 лет назад 0
@grawity Поскольку первая идея OP была «tar», казалось логичным думать в терминах Linux. И `unsquashfs` для Windows работает довольно хорошо. Eugen Rieck 5 лет назад 1

Похожие вопросы