Как управлять набором данных вместе с приложением?

Question

Код приложения и файлы конфигурации хранятся в хранилище кода. Но иногда, как часть проекта, у меня также есть некоторые данные (которые в некоторых случаях могут быть> 100 МБ,> 1 ГБ или около того), которые хранятся в базе данных. Git отлично справляется с обработкой кода и его изменений, но как команда разработчиков может легко обмениваться данными?

Он не совсем подходит для системы контроля версий кода, так как это в основном большие двоичные файлы, и его обновление может стать кошмаром. Но он должен быть синхронизирован с репозиторием, потому что некоторые ревизии кода изменяют схему (т.е. миграции).

Как вы справляетесь с такими ситуациями?

Answer 1

Мы храним данные и схему в xml и используем liquibase для обработки обновлений как схемы, так и данных.Преимущество здесь в том, что вы можете различать файлы, чтобы увидеть, что происходит, они прекрасно работают с любой системой VCS, и вы можете автоматизировать ее.файл.Но, используя стратегию миграции, после этого обновления должны быть управляемыми, поскольку они будут только дельтами.Возможно, вы сможете конвертировать существующие миграции один к одному в liquibase , что может быть лучше, чем подход большого взрыва.

Вы также можете использовать стратегию @belisarius, еслиВаши дельты очень велики, поэтому каждому разработчику не нужно применять дельту индивидуально.

Answer 2

Мне кажется, что ваша база данных имеет много параллелей с зависимостью двоичной библиотеки: она большая (ну, намного больше, чем разумная библиотека кода!), Двоичная и имеет свои собственные версии, которые должны соответствовать различным версиямваша кодовая база.

Учитывая это, почему бы не интегрировать менеджер зависимостей (например, Apache Ivy ) с процессом сборки и позволить ему управлять вашей базой данных?Это похоже на задачу, для которой был создан менеджер зависимостей.

Что касается огромного размера данных / загрузки, я не думаю, что есть какая-то волшебная палочка (если не считать какой-либо серьезной инфраструктуры предварительной загрузки документов), если только вы не можете сериализовать данные в дельта-способный формат (XML / JSON / SQL вы упомянули).

Второй подход (возможно, не очень совместимый с управлением зависимостями): если специфика вашего кода позволяет это сделать, вы можете сохранить второй файл, который представляет собой ручной diff, который может принимать базовую (версия 0) базу данных идоведите его до версии X. Каждый разработчик должен будет поддерживать чистую версию 0. Тяга (версии с измененной БД) будет состоять из: извлечь файл diff, скопировать версию 0 в рабочую базу данных, применить файл diff.Обратите внимание, что применение файла diff может занять некоторое время для большой базы данных, поэтому вы можете не экономить столько времени при прямой загрузке, как кажется на первый взгляд.

Answer 3

Обычно мы используем схему синхронизации или репликации базы данных.

Каждый разработчик имеет 2 копии базы данных, одну для работы, а другую только для сохранения версии синхронизации.

Когда код синхронизируется, скрипт также синхронизирует базу данных (центральная БД по «мертвой» копии разработчика). После этого каждый разработчик обновляет свою рабочую копию. Иногда разработчику необходимо сохранить некоторые свои данные, поэтому эти вторые обновления не всегда выполняются стандартным сценарием.

Он такой же надежный, как схема репликации .... иногда (в зависимости от БД) это не является хорошей новостью.

Answer 4

DataGrove - это новый продукт, который предоставляет вам контроль версий для баз данных. Мы позволяем вам хранить всю базу данных (схему и данные), помечать, восстанавливать и совместно использовать базу данных в любой момент времени.

Это звучит как то, что вы ищете.

В настоящее время мы работаем над функциями, обеспечивающими поведение типа git (push-pull), чтобы разработчики могли делиться своими репозиториями на разных машинах, чтобы я мог загрузить последнюю версию вашей базы данных, когда она мне понадобится.