CouchDB dan versi dokumen

12

Saat ini saya sedang mengerjakan aplikasi wiki-esque menggunakan CouchDB dan saya mencoba menerapkan skema versi dokumen. Cara saya melihatnya ada dua cara untuk melakukan ini:

Simpan setiap versi sebagai dokumen terpisah
Simpan versi lama sebagai lampiran pada satu dokumen.

Saat ini, saya punya bentuk # 1 yang berfungsi. Ketika pengguna mengedit dokumen dan menyimpannya, back-end pertama menyalin revisi sebelumnya ke dokumen baru dan kemudian menyimpan versi baru. Setiap dokumen memiliki larik 'riwayat' yang berisi data pada setiap versi (dokumen _id dari versi lama, cap waktu, editor, dll.).

Karena larik sejarah ini dapat menjadi sangat panjang untuk dokumen yang sering diperbarui, saya memiliki pandangan yang mengambil dokumen tanpa riwayat selama bacaan normal (dan tampilan lain untuk mengambil sejarah).

Pertanyaan saya adalah ini: Saya merasa tidak nyaman dengan pendekatan saya saat ini dan telah berpikir untuk mengubah metode 'attachment'. Tapi saya tidak yakin. Saya berharap seseorang yang mengenal CouchDB lebih baik daripada saya (Saya baru melakukan ini selama beberapa minggu - dan ini adalah proyek pertama saya menggunakan CouchDB ... dan NoSQL) dapat memberi tahu saya apa kelebihan dan kekurangan masing-masing pendekatan. Atau mungkin ada skema versi lain yang saya abaikan?

database-design couchdb

— James Adam
sumber

2

Meskipun saya tidak dapat berbicara dengan dampak kinerja sama sekali, sistem yang Anda gunakan "secara spiritual" sejalan dengan CouchDB. Menyimpan versi sebelumnya sebagai hierarki respons adalah idiomatis, karena berada dalam "leluhur spiritual" CouchDB, database dokumen Lotus Notes (NSF) (Damien Katz bekerja dalam pada yang satu sebelum mengembangkan yang lain, menjaga dan meningkatkan yang terbaik dari itu saat melemparkan persyaratan kompatibilitas cruft dan mundur / bugward, begitu banyak dari pertanyaan struktural yang lebih mendasar akan memiliki jawaban dalam Catatan.)

2

Menyimpan hanya perubahan akan menjadi ide yang baik, karena menyimpan dokumen lama sebagai dokumen terpisah atau lampiran pada revisi akhir basis data akan membuat overhead ke server basis data.

Saat Anda mengubah nilai kunci dalam dokumen Anda, tambahkan kunci baru bernama _h_i_s_<key_name>. Dalam yang baru dibuat (atau dibuat saat pembaruan terakhir), tambahkan objek seperti di bawah ini setelah setiap pengeditan / pembaruan: -

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

atau

    {
    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}],
    ....
    }

Pendekatan ini akan menghemat banyak ruang disk dan replikasi bandwidth dalam jangka panjang.

— Pembayaran Ravinder
sumber

0

Tanpa sepengetahuan CouchDB. Menyimpan setiap versi meskipun hanya berbeda dengan marginal dari pendahulunya adalah pemborosan. Saya sarankan menyimpan perubahan saja.

Anda mungkin ingin melihat di sini atau mencari versi data.

— xuma202
sumber

Jawaban ini gagal untuk mengatakan yang mana dari opsi 1 (dokumen terpisah) atau 2 (sebagai bagian dari dokumen) yang lebih baik.

— binki

0

bertahun-tahun kemudian ;-)

Anda tidak harus menyimpan perubahan karena CouchDB akan melakukannya untuk Anda. Jika dokumen diubah, revisi baru akan dibuat. Sadarilah bahwa ini secara fisik adalah dokumen lain dengan yang sama _idtetapi baru _rev(revisi) dan akan menghabiskan ruang pada disk Anda.

Yang pasti Anda harus menyimpan semua revisi apa artinya, bahwa Anda memerlukan disk yang sangat besar.

— awenkhh
sumber