Стратегия управления версиями CouchDB

Будет ли следующая жизнеспособная стратегия для внедрения версий (используя "пример" в качестве образца типа документа):

Есть один оригинальный документ, в котором поле типа имеет имя example_original.

Последующие изменения документа все имеют тип example_change и идентификатор example_original документа в качестве ключа. Это изменение также будет иметь временную метку.

Держите один документ с типом example_current, который является результатом example_original со всем применяемым example_change. Новый документ example_change будет автоматически применен к этому документу.

Поиск конкретной версии будет состоять в извлечении документа example_original и внесении необходимых изменений (в основном до определенной отметки времени, но также может быть несколько изменений).

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

Какие плюсы и минусы вы видите в этом подходе?

Ответ 1

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

Вам когда-нибудь понадобится удалить что-нибудь из истории? Вы действительно уверены? Неужели, правда, верно? Как насчет ветвей?

В целом, это выглядит как сложная стратегия. Имейте в виду, что я слышал о CouchDB, но никогда не использовал его. Я бы предложил более простой подход:

При создании документа вы назначаете UUID. Не используйте имя или вы будете сталкиваться с проблемами во время операций переименования. Добавьте поле версии, которое читает "1". Создайте второй документ, который содержит список документов с тем же UUID или добавьте "родительский" указатель на первый документ.

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

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

Ответ 2

Простая документация с CouchDB

Подход к версиям как вложения, описанный в этой статье, должен соответствовать большинству требований людей для управления версиями.

Ответ 3

Каков бизнес-статус этих документов, особенно законный? Я работал в ситуациях, когда ваше предложение не соответствовало бы деловой активности, из-за необходимости доказать, что документ, представленный как v.3, действительно является версией 3 документа. Динамическое применение дельт не приведет к сокращению горчицы.

Если, как вы говорите, изменения в документах редко, то вы не собираетесь экономить дисковое пространство, сохраняя дельта, а не целые документы. Сохранение целых документов также позволяет надежно предсказать время поиска для любого документа. Это также снижает сложность процесса поиска.

Ответ 4

Стратегия для управления версиями с помощью CouchDB заключается в том, чтобы никогда не уплотнять базу данных, содержащую документы, для которых вам необходимо сохранить полную историю. Вы все еще можете скомбинировать другие базы данных. Эта простая стратегия работает сегодня из коробки с помощью стратегии разрешения конфликтов.

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

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

Теперь о возможном будущем CouchDB:

Сегодня каждая ревизия содержит полную копию документа, но можно подумать, что оптимизация механизма CouchDB может в один прекрасный день хранить дельта.
Также возможно, что в будущем CouchDB предложит API для предотвращения уплотнения определенных типов документов. Это позволит сохранить все документы в одной базе данных. Это будет простой патч для CouchDB.
Эта стратегия позволяет управлять ветвями документов, но учитывая природу CouchDB как базы данных документов, это разумная, но долговременная возможность.