python: Запихнуть тысячи файлов в один?!

Question

[kAIST]

Приветствую!
Появилась задача сделать некий контейнер для файлов. Из требований:
Тысячи мелких файлов (5-100 кб) должны попадать и извлекаться в один большой файл, а так же чтоб была возможность изменить (удалить) определенный файл.
Что не подошло:
zipfile и tarfile — не умеют удалять (изменять) файлы.
Базы данных sqlite3, dbm и пр:
Все нормально, но на одной из платформ, где планируется использовать приложение нет возможности собрать все то, остается только pure python скрипты.
Есть варианты?

Answer 1

[bagyr]

Сделать что-то вроде файловой системы CP\M: каждый файл разбиваем на чанки фиксированного размера и их пишем в архив, сохраняя где-то какой чанк какому файлу принадлежит. Поверх этого реализовать итерацию по файлам, сохранение, удаление, чтение, запись.
Костыль эпичный, но как сделать проще, чтобы архив не рос при операциях на файлах без перезаписи, не представляю.

Answer 2

[rPman]

Требуется эффективное размещение файлов внутри контейнера? Терпимо ли двух-трех кратное превышение размера в соотношении с суммарным объемом файлов, но при необходимости можно запустить процедуру перестройки всего архива.
habrahabr.ru/qa/10694/#answer_46206

Код очень простой, за вечер набрать сможет любой (вопрос в разнообразии обслуживающих утилит)

Answer 3

[sergeypid]

Вот такую БД нашел на чистом питоне: buzhug.sourceforge.net/

Comments

[sergeypid]

алсо
pypi.python.org/pypi/KirbyBase/1.9
gadfly.sourceforge.net/

[kAIST]

К сожалению, не одна не подошла, например, потому что создает несколько файлов, а не один как нужно.

Answer 4

[niko83]

Как делает фэйсбук для хранения кучи фотографий «Изображения стали хранить в больших бинарных файлах (blob), предоставляя приложению информацию о том, в каком файле и с каким отступом (по сути, идентификатором) от начала расположена каждая фотография. Такой сервис в Facebook получил название Haystack и оказался в десять раз эффективнее „простого“ подхода и в три раза эффективнее „оптимизированного“. Как говорится, все гениальное просто!»
Взято от сюда: www.xakep.ru/post/55510/

Comments

[kAIST]

Спасибо. Так и сделал в итоге.

Answer 5

[eaa]

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

Посмотрите еще на dar — там в рассылке пробегала инфа и были предложения сделать возможность менять архив, но автор сильно упирался и отказывался от такого функционала. Не знаю, может что продвинулось с тех пор.

Comments

[zapimir]

Как может быстро читаться tar? У него нет отдельного списка файлов, там нужно последовательно читать все заголовки. Быстро читает тот же zip, rar и аналоги, у которых в конце файла находится список содержимого.

[eaa]

tar очень быстро читается. При последовательном доступе. Он же родился во времена ленточных накопителей (Tape ARchive), что такое прямой доступ он не знает ;). А для рандомного доступа я упомянул dar (ну и zip, rar тоже конечно это делают).

Answer 6

[kAIST]

Всем спасибо. В итоге сейчас сделал свой костыль:
Так как постоянному изменению подлежит лишь малая часть данных (список файлов, флаги, атрибуты файлов), а операция удаления файла очень редкая), сделал так:
Тупо пишем в файл содержимое другого файла, в конце файла блок метаданных ( json с тем чем нужно (плюс список файлов с адресами начала файла и длинны) и в конце добиваем размером этого блока. )
Когда нужно дописать новый файл, делаем seek к началу блока с метаданными и пишем туда, опять добавляя в конец измененный блок с метаданными. Если нужно изменить метаданные, просто меняем их в конце файла, не трогая весь файл.
Удаление — редко используемая функция, и как правило удалять файлы нужно большим количество. Это уж можно сделать, путем перебора всего файла, записывая в новый нужное и пропуская ненужное

Comments

[Maxim Avanov]

Вы сейчас на 99% описали то же самое, что сделано тут — habrahabr.ru/qa/20231/#answer_82472

Answer 7

[impass]

где планируется использовать приложение нет возможности собрать все то

Нечто embedded что ли? Так компилятор же есть, наверняка какую-нибудь из key-value БД собрать всё-таки можно.

Comments

[kAIST]

Честно? Есть! python-for-android.readthedocs.org/en/latest/
Но sqlite3 не собирается, а собрать что то другое я не могу, ибо знаний не хватает.
В итоге сделал так как выше, не думаю что у других методов будет производительность выше. У меня структура очень простая, а read write seak truncate все равно через Си сделаны.

Answer 8

[Maxim Avanov]

Elliptics от Яндекса делает такую штуку. А также умеет shared-nothing DHT. Есть биндинги для Python.

Answer 9

[smashrod]

можно сделать ещё в начале большого файла хеш таблицу смещений, тогда можно будет по файлу находить шустро без внешнего знания чего либо.

Хороший пример файловой бд есть у Стивенса в книге по Си, там идея расписана как организовать key-val бд, тут как раз было бы тоже самое.

Comments

[kAIST]

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