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

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

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

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

डेटा कंटेंशन

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

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

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

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

एक साथ कई काम करने से जुड़े कंट्रोल

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

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

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

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

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

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

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

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

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

कॉन्करंसी मोड देखना

अपने डेटाबेस के सर्वर-साइड कॉनकरेंसी मोड को देखने के लिए, gcloud firestore databases describe कमांड चलाएं:

gcloud firestore databases describe \
  --project=PROJECT_ID \
  --database=DATABASE_ID

कॉन्करंसी मोड बदलना

अपने डेटाबेस के सर्वर-साइड कॉनकरेंसी मोड को बदलने के लिए, gcloud firestore databases update कमांड चलाएं:

gcloud firestore databases update \
  --project=PROJECT_ID \
  --database=DATABASE_ID \
  --concurrency-mode=CONCURRENCY_MODE

जहां:

• CONCURRENCY_MODE, PESSIMISTIC या OPTIMISTIC है.
• PROJECT_ID आपके Google Cloud प्रोजेक्ट का आईडी है.
• DATABASE_ID आपके Cloud Firestore डेटाबेस का आईडी है.

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

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

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

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

सर्वर क्लाइंट लाइब्रेरी (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 विवाद को हल करने के लिए, ऑप्टिमिस्टिक और पेसिमिस्टिक कॉनकरंसी कंट्रोल का इस्तेमाल करता है.

लेन-देन के दौरान आइसोलेशन

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

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

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