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

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

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

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

डेटा कंटेंशन

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

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

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

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

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

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

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

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

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

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

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

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

Standard वर्शन के लिए, डिफ़ॉल्ट वैल्यू 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

where:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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