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

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

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

Я хочу данные в репозитории:

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

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

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

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

Ответы

Ответ 1

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

http://git-scm.com/book/en/v2/Git-Tools-Submodules

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

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

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

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

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

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

Ответ 2

Это звучит как прекрасный повод попробовать git-annex:

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

Ответ 3

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

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

Ответ 4

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

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

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