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

इस पेज पर, लेन-देन के डेटा के टकराव, सीरियलाइज़ेशन, और आइसोलेशन के बारे में बताया गया है. लेन-देन के कोड सैंपल के लिए, लेन-देन और बैच में किए गए राइट ऑपरेशन देखें.

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

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

डेटा कंटेंशन

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

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

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

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

कॉन्करेंसी कंट्रोल

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

• PESSIMISTIC: Pessimistic concurrency controls assume that data contention is likely. पेसिमिस्टिक ट्रांज़ैक्शन, डेटाबेस लॉक का इस्तेमाल करते हैं. इससे अन्य कार्रवाइयों को डेटा में बदलाव करने से रोका जा सकता है.

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

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

• OPTIMISTIC: Optimistic concurrency controls यह मानते हैं कि डेटा कंटेंशन की संभावना कम है या डेटाबेस लॉक को होल्ड करना असरदार नहीं है. ऑप्टिमिस्टिक ट्रांज़ैक्शन, डेटा में बदलाव करने से अन्य कार्रवाइयों को रोकने के लिए डेटाबेस लॉक का इस्तेमाल नहीं करते

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

कॉन्करेंसी मोड की डिफ़ॉल्ट सेटिंग

Standard वर्शन के लिए, डिफ़ॉल्ट वैल्यू PESSIMISTIC होती है. Enterprise वर्शन के लिए डिफ़ॉल्ट वैल्यू OPTIMISTIC है. हालांकि, यह इस बात पर भी निर्भर करता है कि क्लाइंट लाइब्रेरी किस तरह की है:

• मोबाइल/वेब SDK टूल, ऑप्टिमिस्टिक कॉन्करेंसी कंट्रोल का इस्तेमाल करते हैं. मोबाइल और वेब SDK टूल, इस सेटिंग से अलग काम करते हैं. ऐसा इसलिए, क्योंकि वे हमेशा ऑप्टिमिस्टिक कॉन्करेंसी का इस्तेमाल करते हैं.

• सर्वर क्लाइंट लाइब्रेरी, डेटाबेस सेटिंग के कॉन्करेंसी कंट्रोल का इस्तेमाल करती हैं.

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

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

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

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

सर्वर क्लाइंट लाइब्रेरी (C#, Go, Java, Node.js, PHP, Python, Ruby) में, पहले से मौजूद लेन-देन की सुविधा का इस्तेमाल किया जाता है. ये लेन-देन, डेटाबेस-लेवल की कंकरेंसी मोड सेटिंग का इस्तेमाल करते हैं. साथ ही, डिफ़ॉल्ट सेटिंग, वर्शन पर निर्भर करती है:

• Enterprise वर्शन में, डिफ़ॉल्ट रूप से ऑप्टिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल किया जाता है. इससे उन कार्रवाइयों को सपोर्ट किया जा सकता है जो पूरे कलेक्शन को स्कैन करती हैं. ऑप्टिमिस्टिक कंकरेंसी कंट्रोल की मदद से, स्कैन करने की उन कार्रवाइयों से बचा जा सकता है जो बड़ी संख्या में दस्तावेज़ों को लॉक कर देती हैं.

• स्टैंडर्ड एडिशन, पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करता है. साथ ही, यह कम लेटेन्सी और डेटाबेस से भरोसेमंद कनेक्शन को मानता है.

क्रम से लगाया जा सकता है

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

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

कम आइसोलेशन लेवल वाले सिस्टम में, किसी लेन-देन के दौरान पढ़ने की कार्रवाई, एक साथ होने वाली कार्रवाई में बिना कमिट किए गए बदलावों से गलत डेटा पढ़ सकती है.

सीरियलाइज़ेबल आइसोलेशन, सबसे ज़्यादा आइसोलेशन लेवल तय करता है. सीरियलाइज़ेबल आइसोलेशन का मतलब है कि:

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

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

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

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

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

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

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

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

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

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

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

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