Стратегия управления версиями CouchDB
Будет ли следующее жизнеспособной стратегией для реализации управления версиями (используя "пример" в качестве образца типа документа):
Иметь один оригинальный документ, в котором поле типа называется example_original.
Все последующие изменения документа имеют тип example_change и идентификатор документа example_original в качестве ключа. Изменение также будет содержать метку времени.
Сохраните один документ с типом example_current, который является результатом example_original со всеми применимыми example_change. Новый документ example_change будет автоматически применен к этому документу.
Поиск конкретной версии будет состоять в получении документа example_original и применении желаемых изменений (в основном до определенной временной отметки, но это также может быть ряд изменений).
Я должен отметить, что мой вариант использования будет включать ограниченное количество изменений в оригинале. Большинство обновлений будут состоять из новых оригинальных документов. Несмотря на то, что это мой текущий вариант использования, меня также интересовали бы проблемы, которые могли бы возникнуть, если бы было внесено много изменений.
Какие плюсы и минусы вы видите в этом подходе?
4 ответа
Мое первое беспокойство: при получении определенной версии, можете ли вы применить изменения к оригиналу без изменения базы данных?
Вам когда-нибудь нужно будет что-то удалить из истории? Вы действительно уверены? Действительно, действительно уверен? Как насчет филиалов?
В общем, это выглядит как сложная стратегия. Имейте в виду, что я слышал о CouchDB, но никогда не использовал его. Я бы пошел на более простой подход:
Когда вы создаете документ, вы назначаете UUID. Не используйте имя, иначе у вас возникнут проблемы при переименовании. Добавьте поле версии, которое гласит "1". Создайте второй документ, который содержит список документов с тем же UUID или добавьте "родительский" указатель на первый документ.
Наличие "исторического документа" для каждого документа позволяет быстрее перемещаться по истории, но родительские указатели более "безопасны" (поскольку с ними нелегко создавать нелегальные структуры).
При создании новой ревизии повторно используйте UUID и назначьте новую уникальную версию. Обновите документ истории или родительский указатель.
Эта стратегия довольно проста в реализации и обеспечивает гибкость в дальнейшем. Вы можете легко удалить части истории, переименовать просто, и вы можете создавать ветви.
Простое управление версиями документов с CouchDB
Описанный в этой статье подход управления версиями в виде вложений должен соответствовать требованиям большинства пользователей к управлению версиями.
Каков деловой статус этих документов, особенно юридических? Я работал в ситуациях, когда ваше предложение было бы неприемлемым с точки зрения бизнеса, потому что нужно было доказать, что документ, представленный как v.3, действительно является версией 3 документа. Динамическое применение дельт не уменьшит соответствие требованиям.
Если, как вы говорите, изменения в документах происходят не часто, то вы не собираетесь экономить много места на диске, сохраняя дельты вместо целых документов. Хранение целых документов также позволяет надежно прогнозировать время поиска для любого документа. Это также уменьшает сложность процесса поиска.
Стратегия управления версиями с помощью CouchDB - никогда не сжимать базу данных, содержащую документы, для которых вам необходимо вести полную историю. Вы все еще можете сжать другие базы данных. Эта простая стратегия работает сегодня из коробки со стратегией редактирования разрешения конфликтов.
Удаление документа можно выполнить, написав новую версию без содержимого, но с удаленным набором свойств.
Ветви не могут быть сделаны таким образом, потому что механизм управления версиями предлагает один поток ревизий.
Теперь о возможном будущем CouchDB:
- Сегодня каждая ревизия содержит полную копию документа, но можно подумать, что оптимизации механизма CouchDB могут однажды сохранить дельты.
- Также возможно, что в будущем CouchDB предложит API для предотвращения сжатия определенных типов документов. Это позволило бы хранить все документы в одной базе данных. Это будет простой патч для CouchDB.
- Эта стратегия позволяет управлять ветвями документов, но, учитывая природу CouchDB в качестве базы данных документов, это разумная, но долгосрочная возможность.