MongoDB/NoSQL:Menyimpan Riwayat Perubahan Dokumen

Pertanyaan bagus, saya sendiri juga sedang menyelidikinya.

Buat versi baru pada setiap perubahan

Saya menemukan modul Versioning dari driver Mongoid untuk Ruby. Saya belum menggunakannya sendiri, tetapi dari apa yang saya temukan, itu menambahkan nomor versi ke setiap dokumen. Versi yang lebih lama disematkan dalam dokumen itu sendiri. Kelemahan utama adalah bahwa seluruh dokumen diduplikasi pada setiap perubahan , yang akan menghasilkan banyak konten duplikat yang disimpan saat Anda berurusan dengan dokumen besar. Pendekatan ini baik-baik saja ketika Anda berurusan dengan dokumen berukuran kecil dan/atau tidak terlalu sering memperbarui dokumen.

Hanya simpan perubahan di versi baru

Pendekatan lain adalah menyimpan hanya bidang yang diubah dalam versi baru . Kemudian Anda dapat 'meratakan' riwayat Anda untuk merekonstruksi versi dokumen apa pun. Ini agak rumit, karena Anda perlu melacak perubahan dalam model Anda dan menyimpan pembaruan dan penghapusan sedemikian rupa sehingga aplikasi Anda dapat merekonstruksi dokumen terbaru. Ini mungkin rumit, karena Anda berurusan dengan dokumen terstruktur daripada tabel SQL datar.

Simpan perubahan di dalam dokumen

Setiap bidang juga dapat memiliki sejarah individu. Merekonstruksi dokumen ke versi tertentu jauh lebih mudah dengan cara ini. Dalam aplikasi Anda, Anda tidak perlu melacak perubahan secara eksplisit, tetapi cukup buat versi baru properti saat Anda mengubah nilainya. Dokumen dapat terlihat seperti ini:

{
  _id: "4c6b9456f61f000000007ba6"
  title: [
    { version: 1, value: "Hello world" },
    { version: 6, value: "Foo" }
  ],
  body: [
    { version: 1, value: "Is this thing on?" },
    { version: 2, value: "What should I write?" },
    { version: 6, value: "This is the new body" }
  ],
  tags: [
    { version: 1, value: [ "test", "trivial" ] },
    { version: 6, value: [ "foo", "test" ] }
  ],
  comments: [
    {
      author: "joe", // Unversioned field
      body: [
        { version: 3, value: "Something cool" }
      ]
    },
    {
      author: "xxx",
      body: [
        { version: 4, value: "Spam" },
        { version: 5, deleted: true }
      ]
    },
    {
      author: "jim",
      body: [
        { version: 7, value: "Not bad" },
        { version: 8, value: "Not bad at all" }
      ]
    }
  ]
}

Menandai bagian dari dokumen sebagai dihapus dalam versi masih agak canggung. Anda bisa memperkenalkan state bidang untuk bagian yang dapat dihapus/dipulihkan dari aplikasi Anda:

{
  author: "xxx",
  body: [
    { version: 4, value: "Spam" }
  ],
  state: [
    { version: 4, deleted: false },
    { version: 5, deleted: true }
  ]
}

Dengan masing-masing pendekatan ini, Anda dapat menyimpan versi terbaru dan rata dalam satu koleksi dan data riwayat dalam koleksi terpisah. Ini akan meningkatkan waktu kueri jika Anda hanya tertarik pada versi dokumen terbaru. Namun saat Anda membutuhkan versi terbaru dan data historis, Anda harus melakukan dua kueri, bukan satu. Jadi pilihan untuk menggunakan satu koleksi vs. dua koleksi terpisah harus bergantung pada seberapa sering aplikasi Anda membutuhkan versi historis .

Sebagian besar jawaban ini hanyalah dump otak dari pikiran saya, saya belum benar-benar mencoba semua ini. Melihat kembali, opsi pertama mungkin merupakan solusi termudah dan terbaik, kecuali jika biaya duplikat data sangat signifikan untuk aplikasi Anda. Opsi kedua cukup rumit dan mungkin tidak sepadan dengan usaha. Opsi ketiga pada dasarnya adalah pengoptimalan opsi dua dan seharusnya lebih mudah diterapkan, tetapi mungkin tidak sepadan dengan upaya implementasi kecuali Anda benar-benar tidak dapat menggunakan opsi satu.

Menantikan umpan balik tentang ini, dan solusi orang lain untuk masalah ini :)