लेन-देन का क्रम संख्या और आइसोलेशन

इस पेज पर, लेन-देन से जुड़े डेटा के कॉन्टेंटशन, सीरियलाइज़ेशन, और अलगाव के बारे में बताया गया है. लेन-देन के कोड के सैंपल के लिए, लेन-देन और एक साथ कई डेटा डालना लेख पढ़ें.

लेन-देन और डेटा कंटेंट

किसी लेन-देन के पूरा होने के लिए ज़रूरी है कि लेन-देन के बाहर की कार्रवाइयों से, लेन-देन के लिए पढ़े गए दस्तावेज़ों में कोई बदलाव न किया गया हो. अगर कोई दूसरा ऑपरेशन उनमें से किसी दस्तावेज़ में बदलाव करने की कोशिश करता है, तो वह ऑपरेशन ट्रांज़ैक्शन के साथ डेटा कंटेंशन की स्थिति में चला जाता है.

डेटा कंटेंशन: जब एक ही दस्तावेज़ को कंट्रोल करने के लिए, दो या उससे ज़्यादा ऑपरेशन एक-दूसरे से मुकाबला करते हैं. उदाहरण के लिए, एक लेन-देन के लिए किसी दस्तावेज़ को एक जैसा बनाए रखने की ज़रूरत हो सकती है, जबकि एक साथ किए जा रहे किसी दूसरे ऑपरेशन में उस दस्तावेज़ के फ़ील्ड की वैल्यू अपडेट करने की कोशिश की जा रही हो.

Cloud Firestore, किसी एक ऑपरेशन में देरी करके या उसे पूरा न करके, डेटा को लेकर होने वाली समस्या को हल करता है. Cloud Firestore क्लाइंट लाइब्रेरी, डेटा के लिए हो रहे संघर्ष की वजह से पूरा न हो पाने वाले लेन-देन को अपने-आप दोबारा ट्रांज़ैक्ट करने की कोशिश करती हैं. तय संख्या में कोशिश करने के बाद, लेन-देन की प्रोसेस पूरी नहीं हो पाती और गड़बड़ी का मैसेज दिखता है:

ABORTED: Too much contention on these documents. Please try again.

यह तय करते समय कि किस ऑपरेशन को पूरा नहीं किया जाना है या किसमें देरी करनी है, यह क्लाइंट लाइब्रेरी के टाइप पर निर्भर करता है.

मोबाइल/वेब SDK टूल, ऑप्टिमिज़्म के साथ एक साथ कई टास्क करने की सुविधा का इस्तेमाल करते हैं.
सर्वर क्लाइंट लाइब्रेरी, एक साथ कई टास्क करने की सुविधा के कंट्रोल का इस्तेमाल करती हैं.

मोबाइल/वेब SDK टूल में डेटा कंटेंट

मोबाइल/वेब SDK टूल (Apple प्लैटफ़ॉर्म, Android, वेब, C++), डेटा के लिए होने वाले विवाद को हल करने के लिए, ऑप्टिमिज़्म के साथ काम करने वाले एक से ज़्यादा उपयोगकर्ताओं के कंट्रोल का इस्तेमाल करते हैं.

ऑप्टिमिस्टिक कंसिस्टेंसी कंट्रोल: इस धारणा के आधार पर कि डेटा पर होड़ होने की संभावना नहीं है या डेटाबेस लॉक को होल्ड करना कारगर नहीं है. ऑप्टिमिज़्म ट्रांज़ैक्शन, डेटा में बदलाव करने से रोकने के लिए, डेटाबेस लॉक का इस्तेमाल नहीं करते.

मोबाइल/वेब SDK टूल, ऑप्टिमिज़्म के साथ काम करने वाले एक से ज़्यादा टास्क को कंट्रोल करने की सुविधा का इस्तेमाल करते हैं. ऐसा इसलिए, क्योंकि ये ऐसे एनवायरमेंट में काम कर सकते हैं जहां टास्क पूरा होने में ज़्यादा समय लगता है और नेटवर्क कनेक्शन भरोसेमंद नहीं होता. ज़्यादा इंतज़ार वाले माहौल में दस्तावेज़ों को लॉक करने से, डेटा को ऐक्सेस करने में बहुत ज़्यादा समय लगेगा.

मोबाइल/वेब SDK टूल में, ट्रांज़ैक्शन उन सभी दस्तावेज़ों का ट्रैक रखता है जिन्हें आपने ट्रांज़ैक्शन के दौरान पढ़ा है. लेन-देन की प्रोसेस पूरी होने के लिए ज़रूरी है कि लेन-देन के दौरान, उन दस्तावेज़ों में कोई बदलाव न हुआ हो. अगर कोई दस्तावेज़ बदला गया है, तो लेन-देन मैनेजर लेन-देन को फिर से आज़माता है. अगर कुछ बार कोशिश करने के बाद भी लेन-देन का नतीजा नहीं मिलता है, तो डेटा के इस्तेमाल को लेकर होने वाली समस्या की वजह से लेन-देन पूरा नहीं हो पाता.

सर्वर क्लाइंट लाइब्रेरी में डेटा कंटेंट

सर्वर क्लाइंट लाइब्रेरी (C#, Go, Java, Node.js, PHP, Python, Ruby), डेटा के लिए होने वाले संघर्ष को हल करने के लिए, एक साथ कई टास्क करने की सुविधा के कंट्रोल का इस्तेमाल करती हैं.

पेसिमिस्टिक कंसिस्टेंसी कंट्रोल: इस आधार पर कि डेटा का इस्तेमाल करने के लिए हो सकता है कि कई लोग एक साथ कोशिश कर रहे हों. पेसिमिस्टिक्स ट्रांज़ैक्शन, डेटाबेस लॉक का इस्तेमाल करके, अन्य ऑपरेशन को डेटा में बदलाव करने से रोकते हैं.

सर्वर क्लाइंट लाइब्रेरी, एक साथ कई टास्क करने की सुविधा के कंट्रोल का इस्तेमाल करती हैं. ऐसा इसलिए, क्योंकि वे कम इंतज़ार और डेटाबेस से भरोसेमंद कनेक्शन का अनुमान लगाती हैं.

सर्वर क्लाइंट लाइब्रेरी में, लेन-देन उन दस्तावेज़ों पर लॉक लगाते हैं जिन्हें वे पढ़ते हैं. किसी दस्तावेज़ पर लेन-देन का लॉक होने पर, उस दस्तावेज़ में अन्य लेन-देन, एक साथ कई बदलाव करने की सुविधा, और लेन-देन के अलावा अन्य बदलाव करने की सुविधा काम नहीं करती. कोई ट्रांज़ैक्शन, दस्तावेज़ को लॉक करने के बाद उसे अनलॉक कर देता है. अगर यह किसी वजह से टाइम आउट हो जाता है या काम नहीं करता है, तो यह अपने लॉक भी छोड़ देता है.

जब कोई लेन-देन किसी दस्तावेज़ को लॉक करता है, तो लिखने से जुड़े अन्य ऑपरेशन को लेन-देन के लॉक को हटाने का इंतज़ार करना पड़ता है. लेन-देन, कालांतर में होने के क्रम में लॉक होते हैं.

क्रम से लगाने की सुविधा

लेन-देन के बीच डेटा का फ़र्क़, डेटाबेस के अलग-अलग लेवल से जुड़ा होता है. डेटाबेस के अलगाव के लेवल से पता चलता है कि सिस्टम, एक साथ होने वाले ऑपरेशन के बीच के संघर्षों को कितनी अच्छी तरह मैनेज करता है. डेटाबेस से जुड़ी इन ज़रूरी शर्तों की वजह से, समस्या आती है:

लेन-देन के लिए, सटीक और एक जैसा डेटा होना ज़रूरी है.
संसाधनों का बेहतर तरीके से इस्तेमाल करने के लिए, डेटाबेस एक साथ कई कार्रवाइयां करते हैं.

कम अलगाव वाले सिस्टम में, किसी ट्रांज़ैक्शन में मौजूद रीड ऑपरेशन से, एक साथ किए जा रहे ऑपरेशन में किए गए ऐसे बदलावों का गलत डेटा पढ़ा जा सकता है जिन्हें स्वीकार नहीं किया गया है.

Serializable isolation, अलगाव के सबसे ऊंचे लेवल को तय करता है. सीरियलाइज़ किए जा सकने वाले डेटा को अलग करने का मतलब है कि:

यह माना जा सकता है कि डेटाबेस, लेन-देन को सीरीज़ में करता है.
एक साथ होने वाले ऑपरेशन में, बिना लागू किए गए बदलावों से लेन-देन पर कोई असर नहीं पड़ता.

यह गारंटी तब भी लागू होनी चाहिए, जब डेटाबेस एक साथ कई लेन-देन करता हो. डेटाबेस को एक साथ कई लेन-देन होने से जुड़े कंट्रोल लागू करने होंगे, ताकि इस गारंटी को तोड़ने वाले विरोधों को हल किया जा सके.

Cloud Firestore, ट्रांज़ैक्शन को सीरियलाइज़ किए जा सकने वाले आइसोलेशन की गारंटी देता है. Cloud Firestore में लेन-देन को क्रम से लगाया जाता है और कमिट करने के समय के हिसाब से अलग किया जाता है.

कमिट किए जाने के समय के हिसाब से, सीरियलाइज़ किए जा सकने वाले आइसोलेशन

Cloud Firestore हर लेन-देन के लिए एक समय तय करता है, जो किसी एक समय को दिखाता है. जब Cloud Firestore, डेटाबेस में लेन-देन के बदलावों को कमिट करता है, तो यह माना जा सकता है कि लेन-देन में सभी रीड और राइट, कमिट करने के समय ही होती हैं.

किसी लेन-देन को पूरा होने में कुछ समय लगता है. किसी लेन-देन को लागू करने की प्रोसेस, कमिट करने के समय से पहले शुरू हो जाती है. साथ ही, एक से ज़्यादा कार्रवाइयों को लागू करने की प्रोसेस ओवरलैप हो सकती है. Cloud Firestore, सीरियलाइज़ किए जा सकने वाले आइसोलेशन को बनाए रखता है और यह गारंटी देता है कि:

Cloud Firestore, लेन-देन को कमिट करने के समय के हिसाब से क्रम में कमिट करता है.
Cloud Firestore, लेन-देन को एक साथ होने वाले ऑपरेशन से अलग करता है. साथ ही, लेन-देन को बाद में कमिट करता है.

एक साथ होने वाली कार्रवाइयों के बीच डेटा के लिए होने वाले संघर्ष की स्थिति में, Cloud Firestore संघर्ष को हल करने के लिए, ऑप्टिमिज़्म और पेसिमिज़्म के आधार पर काम करने वाले कंसीक्यॉरिटी कंट्रोल का इस्तेमाल करता है.

लेन-देन के दौरान अलग-अलग डेटा को अलग-अलग रखना

लेन-देन के अलग-अलग होने की सुविधा, लेन-देन के दौरान किए जाने वाले लिखने के ऑपरेशन पर भी लागू होती है. किसी लेन-देन में की गई क्वेरी और रीड में, उस लेन-देन में पहले की गई लिखावट के नतीजे नहीं दिखते. भले ही, आपने किसी लेन-देन में किसी दस्तावेज़ में बदलाव किया हो या उसे मिटाया हो, लेकिन उस लेन-देन में दस्तावेज़ को पढ़ने पर, लेन-देन के लिखने के ऑपरेशन से पहले, दस्तावेज़ का वह वर्शन दिखता है जो कमिट करने के समय मौजूद था. अगर दस्तावेज़ उस समय मौजूद नहीं था, तो पढ़ने की कार्रवाई से कोई नतीजा नहीं मिलता.

डेटा कंटेंशन से जुड़ी समस्याएं

डेटा कंटेंशन और उसे हल करने के तरीके के बारे में ज़्यादा जानने के लिए, समस्या हल करने वाला पेज देखें.