Как Управлять набором данных вместе с приложением?
Код и конфигурационные файлы приложения сохраняются в репозитории кода. Но иногда, как часть проекта, у меня также есть некоторые данные (который в некоторых случаях может быть> 100 МБ,> приблизительно 1 ГБ), который хранится в базе данных. Мерзавец делает хорошее задание в обработке кода и его изменений, но как группа разработчиков может легко совместно использовать данные?
Это действительно не помещается в систему управления версии кода, поскольку это - главным образом большие двоичные файлы и сделало бы получение по запросу обновлений кошмаром. Но это действительно должно синхронизироваться с репозиторием, потому что некоторые изменения кода изменяют схему (т.е. миграции).
Как Вы обрабатываете такие ситуации?
3 ответа
У нас есть данные и схема, хранящиеся в xml, и мы используем liquibase для обработки обновлений как схемы, так и данных. Преимущество здесь в том, что вы можете сравнивать файлы, чтобы увидеть, что происходит, это прекрасно работает с любой системой контроля версий, и вы можете автоматизировать это.
Из-за размера вашей базы данных это означает, что файл «версии 0» довольно большой. Но, используя стратегию миграции, после этого обновления должны быть управляемыми, поскольку они будут только дельтами. Вы также можете преобразовать существующие миграции один к одному в liquibase, что может быть лучше, чем метод большого взрыва.
Вы также можете использовать стратегию @belisarius, если ваши дельты очень велики, поэтому каждому разработчику не нужно применять дельту индивидуально.
Обычно мы используем схему синхронизации или репликации базы данных.
У каждого разработчика есть 2 копии базы данных, одна для работы, а другая только для хранения версии синхронизации.
При синхронизации кода скрипт синхронизирует и БД (центральную БД против "мертвой" девелоперской копии). После этого каждый разработчик обновляет свою рабочую копию. Иногда разработчику необходимо сохранить часть своих данных, поэтому эти вторые обновления не всегда управляются стандартным сценарием.
Она так же надежна, как и схема репликации… иногда (в зависимости от БД) это не приносит хороших новостей.
Мне кажется, что ваша база данных имеет много параллелей с зависимостью от двоичной библиотеки: она большая (ну, намного больше, чем разумная библиотека кода!), двоичная и имеет свои собственные версии, которые должны соответствовать различным версиям вашей кодовой базы.
Имея это в виду, почему бы не интегрировать менеджер зависимостей (например, Apache Ivy) в процесс сборки и позволить ему управлять вашей базой данных? Это похоже на задачу, для которой был создан менеджер зависимостей.
Что касается самого размера данных/загрузки, я не думаю, что есть какое-то чудодейственное средство (за исключением серьезной инфраструктуры предварительной загрузки документов), если только вы не можете сериализовать данные в дельта-совместимый формат (XML/JSON). /SQL, о котором вы упомянули).
Второй подход (возможно, не совсем совместимый с управлением зависимостями): если это позволяют особенности вашего кода, вы можете сохранить второй файл, представляющий собой ручное сравнение, которое может взять базовую (версию 0) базу данных и вызвать ее. на версию X. Каждому разработчику необходимо будет поддерживать чистую версию 0. Пул (версии с измененной БД) будет состоять из: извлечения файла различий, копирования версии 0 в рабочую базу данных, применения файла различий. Обратите внимание, что применение файла различий может занять некоторое время для значительной базы данных, поэтому вы можете не сэкономить столько времени по сравнению с прямой загрузкой, как кажется на первый взгляд.