Версія CouchDB та документація

12

Зараз я працюю над програмою wiki-esque за допомогою CouchDB і намагаюся реалізувати схему версії документа. Як я це бачу, є два способи зробити це:

Зберігайте кожну версію як окремий документ
Зберігайте старіші версії як додатки до одного документа.

Зараз у мене працює форма №1 роботи. Коли користувач редагує документ і зберігає його, бек-енд спочатку копіює попередню версію в новий документ, а потім зберігає нову версію. Кожен документ має масив 'історія', який містить дані про кожну версію (документ _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
джерело