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

12

В настоящее время я работаю над приложением wiki-esque, использующим CouchDB, и пытаюсь реализовать схему управления версиями документа. На мой взгляд, есть два способа сделать это:

Храните каждую версию как отдельный документ
Храните старые версии в виде вложений в одном документе.

Прямо сейчас у меня работает форма № 1. Когда пользователь редактирует документ и сохраняет его, серверная часть сначала копирует предыдущую редакцию в новый документ, а затем сохраняет новую версию. Каждый документ имеет массив 'history', который содержит данные о каждой версии (документ _id старой версии, метка времени, редактор и т. Д.).

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

Мой вопрос таков: я чувствую себя неловко из-за своего нынешнего подхода и думаю о переходе на метод «привязанности». Но я не уверен. Я надеюсь, что кто-то, кто знает CouchDB лучше меня (я занимался этим всего пару недель - и это мой первый проект с использованием CouchDB ... и NoSQL), может рассказать мне о плюсах и минусах каждого из них. подходить. Или есть какая-то другая схема управления версиями, которую я пропускаю?

database-design couchdb

— Джеймс Адам
источник

2

Хотя я не могу говорить о влиянии на производительность, система, которую вы используете, «духовно» соответствует CouchDB. Хранение предыдущих версий в виде иерархии ответов является идиоматическим, как это происходит с «духовным предком» CouchDB, базой данных документов Lotus Notes (NSF) (Дэмиен Кац глубоко работал над одной, прежде чем разрабатывать другую, сохраняя и улучшая ее лучшее). в то время как отбрасывая требования совместимости и обратной / ошибочной совместимости, многие из более простых структурных вопросов будут иметь ответы в Примечаниях.)

2

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

Когда вы меняете значение ключа в своем документе, добавляйте новый ключ с именем _h_i_s_<key_name>. Во вновь созданных (или созданных во время последнего обновления) добавляйте объекты, как показано ниже после каждого редактирования / обновления: -

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

или

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

Такой подход сэкономит много дискового пространства и пропускную способность репликации в долгосрочной перспективе.

— Равиндер Паял
источник

0

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

Возможно, вы захотите взглянуть здесь или искать версии данных.

— xuma202
источник

В этом ответе не сказано, какой из вариантов 1 (отдельные документы) или 2 (как часть документа) лучше.

— Бинки

0

годы спустя ;-)

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

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

— awenkhh
источник