Есть ли альтернативы для создания больших контейнерных файлов, которые являются кроссплатформенными?

Question

Ранее я задавал вопрос .

Проблема в том, что требования к нашей файловой структуре очень высоки.

Например, мы пытаемся создать контейнер, содержащий до 4500 файлов и 500 МБ данных.

Файловая структура этого контейнера состоит из

• БД SQLite (до 1 МБ)
• Текстовый xml-подобный файл

• Изображения в динамической структуре папок, которые составляют оставшиеся 4500 файлов

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

• Маленький дБ регулярно используется при обращении к контейнеру.

Tar, Zip и т.п. слишком медленные (даже при 0 сжатии). Я знаю, что медленный - это субъективно, но распаковка контейнера такого размера занимает более 20 секунд.

Есть мысли?

Answer 1

Поскольку вы, похоже, выполняете произвольные операции с файловой системой над своим контейнером (скажем, создание, удаление новых файлов в контейнере, перезапись существующих файлов, добавление), я думаю, вам следует использовать какую-то файловую систему. Выделите большой файл, затем создайте в нем структуру файловой системы.

Для файловой системы доступно несколько параметров: для Berkeley UFS и Linux ext2 / ext3 доступны библиотеки пользовательского режима. Также возможно, что вы где-нибудь найдете реализацию FAT. Убедитесь, что вы понимаете структуру файловой системы и выберите такую, которая позволяет расширять - я знаю, что ext2 довольно легко расширять (с помощью другой группы блоков), а FAT сложно расширять (необходимо добавить в FAT).

Кроме того, вы можете поместить формат виртуального диска в файловую систему, что позволяет произвольно перераспределять блоки. Тогда «свободные» блоки файловой системы не должны появляться на диске, и вы можете выделить виртуальный диск намного больше, чем будет настоящий файл контейнера.

Answer 2

Check Solid File System - похоже, что вам нужно.

Answer 3

Во-первых, спасибо за расширение вашего вопроса, это очень помогает в предоставлении лучших ответов.

Учитывая, что вам все равно понадобится база данных SQLite, вы смотрели на производительность помещения всего этого в базу данных? Мой опыт основан на SQL Server 2000/2005/2008, поэтому я не уверен в возможностях SQLite, но уверен, что это будет довольно быстрый вариант для поиска записей и получения данных, но при этом можно будет удалить и / или обновить параметры.

Обычно я бы не рекомендовал помещать файлы в базу данных, но, учитывая, что общий размер всех изображений составляет около 500 МБ для 4500 изображений, которые вы просматриваете чуть более 100 КБ, не так ли? Если вы используете динамический путь для хранения изображений, то в немного более нормализованной базе данных вы можете иметь таблицу «ImagePaths», которая сопоставляет каждый путь с идентификатором, тогда вы можете искать изображения с этим PathID и загружать данные из Колонка BLOB по мере необходимости.

XML-файл (ы) также может находиться в базе данных SQLite, что дает вам один «файл данных» для вашего приложения, который может без проблем перемещаться между Windows и OSX. Вы можете просто положиться на свой движок SQLite, чтобы обеспечить необходимую производительность и совместимость.

Как вы оптимизируете это, зависит от вашего использования, например, если вам часто нужно получить все изображения по определенному пути, тогда наличие PathID (как целое число для производительности) будет быстрым, но если вы показываете все изображения, которые начинаются с «A» и просто показывают путь как свойство, тогда индекс для столбца ImageName будет более полезным.

Я немного обеспокоен тем, что это звучит как преждевременная оптимизация, поскольку вам действительно нужно найти решение, которое работает «достаточно быстро», абстрагировать его механику так, чтобы ваше приложение (или оба приложения, если у вас есть и Mac, и PC) версии) использовать простой репозиторий или аналогичный, а затем вы можете изменить способ хранения / извлечения по своему усмотрению без каких-либо последствий для вашего приложения.

Answer 4

Три вещи.

1) То, что сказал Тимоти Уолтерс, верно, я более подробно остановлюсь.

2) 4500 файлов и 500 МБ данных - это просто много данных и запись на диск. Если вы работаете со всем набором данных, это будет медленно. Просто правда ввода / вывода.

3) Как уже упоминалось, подробностей по варианту использования нет.

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

В двух словах, вот что вы делаете.

Вы объединяете все файлы в один большой двоичный объект. Пока вы объединяете их, вы отслеживаете их имя файла, длину файла и смещение, с которого файл начинается в BLOB-объекте. Вы записываете эту информацию в блок данных, отсортированный по имени. Мы назовем это оглавлением или блоком оглавления.

Затем вы объединяете два файла вместе. В простом случае сначала у вас есть блок TOC, а затем блок данных.

Когда вы хотите получить данные из этого формата, найдите в TOC имя файла, возьмите смещение от начала блока данных, добавьте размер блока TOC и прочитайте байты данных FILE_LENGTH. Простой.

Если вы хотите быть умным, вы можете поместить оглавление в конец файла BLOB-объекта. Затем добавьте в самом конце смещение к началу оглавления. Затем вы переходите к концу файла, резервируете 4 или 8 байт (в зависимости от размера вашего номера), берете значение TH и еще дальше возвращаетесь к началу вашего оглавления. Тогда ты вернулся на круги своя. Вы делаете это, чтобы вам не нужно было перестраивать архив дважды в начале.

Если вы разместите ваш TOC в блоках (скажем, размером 1 КБ), то вы легко сможете выполнить двоичный поиск по TOC. Просто заполните каждый блок записями информации о файле, а когда вам не хватит места, напишите маркер, заполните нулями и перейдите к следующему блоку. Чтобы выполнить двоичный поиск, вы уже знаете размер оглавления, начните с середины, прочитайте имя первого файла и перейдите оттуда. Вскоре вы найдете блок, а затем прочитаете блок и отсканируете его на наличие файла. Это делает его эффективным для чтения, не имея всей TOC в оперативной памяти. Другое преимущество заключается в том, что для блокировки требуется меньше дисковой активности, чем для цепной схемы, такой как TAR (где вам нужно сканировать архив, чтобы что-то найти).

Я предлагаю вам также дополнить файлы размерами блоков, например, диски работают с блоками данных обычного размера, это тоже не сложно.

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

Что касается переносимости, я предлагаю вам хранить ваши двоичные числа в сетевом порядке, так как большинство стандартных библиотек имеют подпрограммы для обработки этих деталей для вас.

Answer 5

Образ диска ISO может помочь. Он должен легко хранить столько файлов и поддерживается многими программными средствами во всех основных операционных системах.

Answer 6

Работая в предположении, что вам нужен только доступ только для чтения к файлам, почему бы просто не объединить их все вместе и получить второй файл «index» (или индекс в заголовке), который сообщает вам файл имя, начальная позиция и длина. Все, что вам нужно сделать, это найти начальную точку и прочитать правильное количество байтов. Метод зависит от вашего языка, но в большинстве из них он довольно прост.

Самым сложным становится создание файла данных + индекса, и даже это довольно просто!