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

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

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

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

डेटा कंटेंशन

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

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 टूल, दस्तावेज़ के वर्शन पर write preconditions का इस्तेमाल करके, ऑप्टिमिस्टिक कंकरेंसी ट्रांज़ैक्शन की नकल करते हैं. यह इम्यूलेशन, डेटाबेस के कॉन्करेंसी मोड की सेटिंग के बावजूद होता है. मोबाइल और वेब 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 कंटेंशन को हल करने के लिए, ऑप्टिमिस्टिक और पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करता है.

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

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

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

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