अच्छा सवाल है, मैं खुद को भी देख रहा था।
प्रत्येक परिवर्तन पर एक नया संस्करण बनाएँ
मैं रूबी के लिए मोंगॉयड ड्राइवर के संस्करण मोड में आया था । मैंने स्वयं इसका उपयोग नहीं किया है, लेकिन जो मुझे मिल सकता है , वह प्रत्येक दस्तावेज़ में एक संस्करण संख्या जोड़ता है। पुराने संस्करण दस्तावेज़ में ही एम्बेडेड हैं। मुख्य दोष यह है कि प्रत्येक परिवर्तन पर पूरे दस्तावेज़ को डुप्लिकेट किया जाता है , जिसके परिणामस्वरूप जब आप बड़े दस्तावेज़ों के साथ काम कर रहे हैं तो बहुत सारी डुप्लिकेट सामग्री संग्रहीत की जाएगी। यह तब ठीक है जब आप छोटे आकार के दस्तावेज़ों के साथ काम कर रहे हैं और / या बहुत बार दस्तावेजों को अपडेट नहीं करते हैं।
केवल एक नए संस्करण में परिवर्तन स्टोर करें
एक और दृष्टिकोण केवल नए संस्करण में केवल परिवर्तित फ़ील्ड्स को संग्रहीत करना होगा । फिर आप दस्तावेज़ के किसी भी संस्करण को फिर से बनाने के लिए अपने इतिहास को 'समतल' कर सकते हैं। यह हालांकि जटिल है, क्योंकि आपको अपने मॉडल में परिवर्तनों को ट्रैक करने और अद्यतनों को स्टोर करने और इस तरह से हटाने की आवश्यकता है कि आपका एप्लिकेशन अप-टू-डेट दस्तावेज़ को फिर से संगठित कर सके। यह मुश्किल हो सकता है, क्योंकि आप फ्लैट 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 }
]
}
इनमें से प्रत्येक दृष्टिकोण के साथ आप एक संग्रह में एक अप-टू-डेट और चपटा संस्करण स्टोर कर सकते हैं और एक अलग संग्रह में इतिहास डेटा। यदि आप केवल किसी दस्तावेज़ के नवीनतम संस्करण में रुचि रखते हैं तो यह क्वेरी समय में सुधार करना चाहिए। लेकिन जब आपको नवीनतम संस्करण और ऐतिहासिक डेटा दोनों की आवश्यकता होती है, तो आपको एक के बजाय दो प्रश्न करने होंगे। इसलिए एक ही संग्रह बनाम दो अलग-अलग संग्रह का उपयोग करने का विकल्प इस बात पर निर्भर होना चाहिए कि आपके आवेदन को ऐतिहासिक संस्करणों की कितनी बार आवश्यकता है ।
इस जवाब में से अधिकांश सिर्फ मेरे विचारों का एक मस्तिष्क डंप है, मैंने वास्तव में अभी तक इसमें से कोई भी कोशिश नहीं की है। उस पर पीछे मुड़ते हुए, पहला विकल्प संभवतः सबसे आसान और सबसे अच्छा समाधान है, जब तक कि आपके आवेदन के लिए डुप्लिकेट डेटा का ओवरहेड बहुत महत्वपूर्ण न हो। दूसरा विकल्प काफी जटिल है और शायद प्रयास के लायक नहीं है। तीसरा विकल्प मूल रूप से विकल्प दो का अनुकूलन है और इसे लागू करना आसान होना चाहिए, लेकिन संभवतः कार्यान्वयन प्रयास के लायक नहीं है जब तक कि आप वास्तव में विकल्प एक के साथ नहीं जा सकते।
इस पर प्रतिक्रिया के लिए आगे देख रहे हैं, और समस्या के अन्य लोगों के समाधान :)