Насколько я понимаю, git хэши SHA1 имели побочный эффект сокращения дискового хранилища, не дублируя идентичные объекты, и было введено сжатие zlib для явного сокращения дискового хранилища репозиториев. Позже были добавлены пакеты, в которых были добавлены дельты для дальнейшего уменьшения размера, а также сгруппированы несколько объектов в один файл для улучшения передачи по сети.
Я понял, что введение дельт уменьшает размер еще больше, и что группировка объектов в один файл может иметь некоторые улучшения сети.
Но действительно ли группирование файлов в пакете действительно необходимо на диске ? Я не уверен, в чем выгода, и кажется, что это может вызвать проблемы с производительностью во время сборки мусора, потому что потенциально большие файлы, возможно, придется перезаписывать из-за обрезки объекта (что, я знаю, несколько смягчается, если помещать большие сначала файлы).
Я просто не вижу выгоды от фактической группировки объектов в файл пакета. Это должно уменьшить количество разговоров при согласовании того, какие объекты необходимо передать? В этом случае создается впечатление, что файл .idx может «определить» виртуальный пакет, но оставить фактические объекты отдельными файлами на диске и только «упаковать» их при передаче.
Я в основном желая лучшего понимания файлов пакета и причин для них. Я работал с коллегой, у которого есть проблемное хранилище c, и понимание файлов пакета помогает мне помочь ему.
РАЗЪЯСНЕНИЕ: Мой главный вопрос не «почему файлы пакета полезны», это : Каково преимущество хранения отдельных объектов вместе в файле пакета вместо того, чтобы индекс указывал только на отдельные файлы? Какая выгода есть? Я вижу только тот недостаток, что приходится перезаписывать файлы пакета при удалении объектов. Я полностью использую преимущества deltas.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
Больше понимания того, как работают файлы пакета и почему:
- Файлы пакета в основном оптимизированы для сетевой передачи. , уменьшая общий размер передаваемых данных. Похоже, что это является движущей силой проектных решений.
- Чтобы восстановить объект, каждый файл пакета должен быть найден до тех пор, пока не будет найден идентификатор объекта / га sh.
- Структура файлов индекса позволяет осуществлять быстрый двоичный поиск, а структуры файлов индекса и пакета позволяют быстро находить базовые данные и дельты
- Файлы пакета являются автономными, что означает спецификацию c Пакетный файл должен содержать базовый файл и любые дельты, необходимые для создания единого объекта
Итак, я вижу следующее:
- Меньше индексных файлов, которые должны быть поиск, тем быстрее будет найден объект
- Наличие базы и всех дельт для связанных объектов в одном файле ОС повышает производительность воссоздания объекта, открывая только один файл (для фактических данных)
- Каждый бит и байт для передачи по сети имеют значение
Благодаря всему этому я осознаю, что моей основной проблемой является размер диск из пакета файлов. Чрезвычайно большие файлы на диске труднее обрабатывать в целом - как с точки зрения резервного копирования / восстановления, так и с точки зрения изменения содержимого.
Приведенные выше три момента, которые я наблюдал, не требуют того, что я имею в виду понимание, получение максимально возможного количества объектов в реальном файле .pack. Я вижу преимущество как можно большего количества записей в файле .idx для ускорения поиска объекта, но у меня есть предчувствие, что файлы .pack можно хранить в виде нескольких файлов меньшего размера и при этом достичь целей производительности сети и на диске. Даже такая простая схема, как отдельный файл пакета на базу, и это дельта-дерево. Существующая схема индекса все еще может сгруппировать их и сохранить существующую структуру пакета для передачи.
Во всяком случае, я думаю, что ответил на свой первоначальный вопрос немного большим исследованием, но раскрыл то, что я на самом деле жевал в затылке, и теперь это немного больше в гипотетическую сферу.