Git + большой набор данных?

Question

Мы часто работаем над проектом, в котором нам передали большой набор данных (скажем, несколько файлов по 1 ГБ каждый), и пишем код для его анализа.

Весь код анализа находится в Git, поэтому каждый может проверить изменения в нашем центральном хранилище и из него. Но что делать с наборами данных, с которыми работает код?

Я хочу данные в хранилище:

• Когда пользователи впервые клонируют репозиторий, данные должны поставляться вместе с ним.
• Данные не на 100% только для чтения; время от времени точка данных исправляется, или происходит незначительное изменение форматирования. Если в данных происходят незначительные изменения, пользователи должны быть уведомлены при следующей проверке.

Однако мне не нужны данные в репозитории git:

• git, клонирование резервной копии (поэтому у меня есть две версии в моем домашнем каталоге) извлечет несколько ГБ данных, которые у меня уже есть. Я бы предпочел либо иметь его в фиксированном месте [установить правило, что данные должны быть в ~ / data], либо добавлять ссылки по мере необходимости.
• При наличии данных в хранилище копирование на флэш-накопитель может оказаться невозможным, что раздражает, когда я просто работаю над сотней строк кода.
• Если исправить ошибочную точку данных, я больше никогда не буду смотреть на ошибочную версию. Изменения в наборе данных могут отслеживаться в виде простого текстового файла или лицом, предоставившим данные (или просто не совсем).

Кажется, мне нужна установка с основным репозиторием для кода и вспомогательным репозиторием для данных. Какие-нибудь предложения или уловки для изящной реализации этого, либо в git, либо в POSIX в целом? Все, о чем я думал, в той или иной мере - клудж.

Answer 1

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

http://git -scm.com / книга / а / v2 / GIT-Tools-Подмодули

Примеры говорят о библиотеках, но это работает для больших раздутых вещей, таких как образцы данных для тестирования, изображения, фильмы и т. Д.

Вы сможете летать во время разработки, только останавливаясь здесь и там, если вам нужно посмотреть на новые версии гигантских данных.

Иногда даже не стоит отслеживать изменения в таких вещах.

Для решения ваших проблем с получением большего количества клонов данных: Если ваша реализация git поддерживает жесткие ссылки в вашей ОС, это должно быть очень просто.

Характер вашего гигантского набора данных также находится в игре. Если вы меняете некоторые из них, вы меняете гигантские капли или несколько рядов в миллионах? Это должно определить, насколько эффективным будет VCS при воспроизведении для него механизма уведомлений.

Надеюсь, это поможет.

Answer 2

Звучит как идеальная возможность попробовать git-annex :

git-annex позволяет управлять файлами с помощью git, не проверяя содержимое файла в git. Хотя это может показаться парадоксальным, но это полезно при работе с файлами, размер которых превышает git в настоящее время легко обрабатывается, будь то из-за ограничений в памяти, времени контрольной суммы или дискового пространства.

Answer 3

В качестве альтернативы данные могут находиться в неотслеживаемой (по git) папке, которая синхронизируется службой p2p.Мы используем это решение для набора данных в несколько десятков ГБ, и оно работает довольно хорошо.

• Набор данных совместно используется одноранговыми узлами.
• В зависимости от программного обеспечения p2p можно сохранять и восстанавливать более старые версии.
• Набор данных автоматически обновляется в случае изменений.

syncthing - это программное обеспечение, которое мы используем.

Answer 4

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

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