अच्छा सवाल, मैं खुद भी इस पर गौर कर रहा था।
प्रत्येक परिवर्तन पर एक नया संस्करण बनाएं
मैं रूबी के लिए मोंगोइड ड्राइवर के वर्जनिंग मॉड्यूल में आया था। मैंने इसे स्वयं उपयोग नहीं किया है, लेकिन जो मुझे मिल सकता है, वह प्रत्येक दस्तावेज़ में एक संस्करण संख्या जोड़ता है। पुराने संस्करण दस्तावेज़ में ही एम्बेड किए गए हैं। मुख्य दोष यह है कि प्रत्येक परिवर्तन पर संपूर्ण दस्तावेज़ की प्रतिलिपि बनाई जाती है , जिसके परिणामस्वरूप जब आप बड़े दस्तावेज़ों के साथ काम कर रहे हों तो बहुत अधिक डुप्लिकेट सामग्री संग्रहीत की जाएगी। यह दृष्टिकोण ठीक है, हालांकि जब आप छोटे आकार के दस्तावेज़ों के साथ काम कर रहे हैं और/या अक्सर दस्तावेज़ों को अपडेट नहीं करते हैं।
केवल नए संस्करण में परिवर्तनों को संग्रहित करें
दूसरा तरीका यह होगा कि केवल बदले गए फ़ील्ड को नए संस्करण में संग्रहीत करें . फिर आप दस्तावेज़ के किसी भी संस्करण को फिर से बनाने के लिए अपने इतिहास को 'समतल' कर सकते हैं। हालांकि यह काफी जटिल है, क्योंकि आपको अपने मॉडल में बदलावों को ट्रैक करने और अपडेट को स्टोर करने और इस तरह से डिलीट करने की आवश्यकता है कि आपका एप्लिकेशन अप-टू-डेट दस्तावेज़ का पुनर्निर्माण कर सके। यह मुश्किल हो सकता है, क्योंकि आप फ्लैट SQL टेबल के बजाय संरचित दस्तावेज़ों के साथ काम कर रहे हैं।
दस्तावेज़ में परिवर्तन संगृहीत करें
प्रत्येक क्षेत्र का एक व्यक्तिगत इतिहास भी हो सकता है। किसी दिए गए संस्करण में दस्तावेज़ों का पुनर्निर्माण करना इस तरह से बहुत आसान है। अपने आवेदन में आपको परिवर्तनों को स्पष्ट रूप से ट्रैक करने की आवश्यकता नहीं है, लेकिन जब आप संपत्ति का मूल्य बदलते हैं तो बस उसका एक नया संस्करण बनाएं। दस्तावेज़ कुछ इस तरह दिख सकता है:
{
_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" }
]
}
]
}
दस्तावेज़ के हिस्से को किसी संस्करण में हटाए गए के रूप में चिह्नित करना अभी भी कुछ अजीब है। आप एक state का परिचय दे सकते हैं आपके एप्लिकेशन से हटाए/पुनर्स्थापित किए जा सकने वाले भागों के लिए फ़ील्ड:
{
author: "xxx",
body: [
{ version: 4, value: "Spam" }
],
state: [
{ version: 4, deleted: false },
{ version: 5, deleted: true }
]
}
इनमें से प्रत्येक दृष्टिकोण के साथ आप एक संग्रह में एक अप-टू-डेट और फ़्लैटेड संस्करण और एक अलग संग्रह में इतिहास डेटा संग्रहीत कर सकते हैं। यदि आप केवल किसी दस्तावेज़ के नवीनतम संस्करण में रुचि रखते हैं, तो इससे क्वेरी समय में सुधार होना चाहिए। लेकिन जब आपको नवीनतम संस्करण और ऐतिहासिक डेटा दोनों की आवश्यकता हो, तो आपको एक के बजाय दो क्वेरी करने की आवश्यकता होगी। इसलिए एकल संग्रह बनाम दो अलग-अलग संग्रहों का उपयोग करने का विकल्प इस पर निर्भर होना चाहिए कि आपके एप्लिकेशन को कितनी बार ऐतिहासिक संस्करणों की आवश्यकता है ।
इस उत्तर में से अधिकांश मेरे विचारों का सिर्फ एक मस्तिष्क डंप है, मैंने वास्तव में अभी तक इनमें से कोई भी कोशिश नहीं की है। इस पर पीछे मुड़कर देखें, तो पहला विकल्प शायद सबसे आसान और सबसे अच्छा समाधान है, जब तक कि डुप्लिकेट डेटा का ओवरहेड आपके एप्लिकेशन के लिए बहुत महत्वपूर्ण न हो। दूसरा विकल्प काफी जटिल है और शायद प्रयास के लायक नहीं है। तीसरा विकल्प मूल रूप से विकल्प दो का अनुकूलन है और इसे लागू करना आसान होना चाहिए, लेकिन संभवतः कार्यान्वयन प्रयास के लायक नहीं है जब तक कि आप वास्तव में विकल्प एक के साथ नहीं जा सकते।
इस पर प्रतिक्रिया और समस्या के अन्य लोगों के समाधान की प्रतीक्षा में :)
