Как управлять набором данных вместе с приложением?
Код приложения и файлы конфигурации хранятся в репозитории кода. Но иногда, как часть проекта, у меня также есть некоторые данные (которые в некоторых случаях могут быть > 100 МБ, > 1 ГБ или около того), которые хранятся в базе данных. Git отлично справляется с обработкой кода и его изменений, но как команда разработчиков может легко делиться данными?
Он не подходит для системы управления версиями кода, так как это в основном большие двоичные файлы, и сделает вытягивание обновлений кошмаром. Но он должен быть синхронизирован с репозиторием, потому что некоторые изменения кода изменяют схему (т.е. миграции).
Как вы справляетесь с такими ситуациями?
Ответы
Ответ 1
У нас есть данные и схема, хранящиеся в xml, и используйте liquibase для обработки обновлений как для схемы, так и для данных. Преимущество здесь в том, что вы можете разделить файлы, чтобы увидеть, что происходит, он отлично работает с любым VCS, и вы можете его автоматизировать.
Из-за размера вашей базы данных это будет означать значительный файл версии 0. Но, используя стратегию миграции, после этого обновления должны быть управляемыми, поскольку они будут только дельтами. Возможно, вы сможете конвертировать существующие миграции один к одному в liquibase, который может быть приятнее, чем подход с большими возможностями.
Вы также можете использовать стратегию @belisarius, если ваши дельта очень велики, поэтому каждый разработчик не должен применять дельта индивидуально.
Ответ 2
Мне кажется, что ваша база данных имеет много параллелей с зависимостью бинарной библиотеки: она большая (ну, намного больше, чем разумная библиотека кодов!), двоичная, и имеет свои собственные версии, которые должны соответствовать различным версиям вашей кодовой базы.
С этой целью почему бы не интегрировать менеджера зависимостей (например, Apache Ivy) с процессом сборки и позволить ему управлять вашей базой данных? Это похоже на задачу, для которой был создан менеджер зависимостей.
Что касается чистого объема данных/загрузки, я не думаю, что есть волшебная пуля (за исключением некоторой серьезной инфраструктуры предварительной загрузки документа), если вы не можете сериализовать данные в дельта-способный формат (XML/JSON/SQL, о котором вы упомянули).
Второй подход (возможно, не так совместим с управлением зависимостями): если это позволяет код вашего кода, вы можете сохранить второй файл, который представляет собой ручную разницу, которая может занять базовую (версию 0) базу данных и поднять ее к версии X. Каждому разработчику необходимо сохранить чистую версию 0. Притяжение (версии с измененным БД) будет состоять из: pull diff file, copy version 0 to working database, apply diff file. Обратите внимание, что применение файла diff может занять некоторое время для значимого БД, поэтому вы не можете сэкономить столько времени на прямой загрузке, как кажется на первый взгляд.
Ответ 3
Обычно мы используем схему синхронизации базы данных или репликации.
Каждый разработчик имеет 2 копии базы данных, один для работы, а другой только для сохранения версии синхронизации.
Когда код синхронизируется, script также синхронизирует базу данных (центральный БД с "мертвой" копией разработчика). После этого каждый разработчик обновляет свою собственную рабочую копию. Иногда разработчик должен хранить некоторые свои данные, поэтому эти последние обновления не всегда управляются стандартным script.
Он такой же надежный, как схема репликации.... иногда (в зависимости от БД), который не представляет хороших новостей.
Ответ 4
DataGrove - это новый продукт, который дает вам контроль версий для баз данных. Мы позволяем вам хранить всю базу данных (схему и данные), тег, восстанавливать и совместно использовать базу данных в любой момент времени.
Это похоже на то, что вы ищете.
В настоящее время мы работаем над функциями, позволяющими поведение git -like (push-pull), чтобы разработчики могли делиться своими репозиториями на разных машинах, поэтому я могу загрузить последнюю версию своей базы данных, когда мне это нужно.
