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

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

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

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

डेटा कंटेंशन

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

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

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

अपने डेटाबेस का सर्वर-साइड कंकरेंसी मोड देखने के लिए, 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

where:

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

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

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

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

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

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