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

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

लेन-देन और डेटा से जुड़े विवाद

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

डेटा से जुड़ा विवाद

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

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

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

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

एक साथ चलने वाली कार्रवाइयों को कंट्रोल करने की सुविधा

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

• PESSIMISTIC: Pessimistic concurrency controls, यह मानकर चलते हैं कि डेटा से जुड़े विवाद होने की संभावना है. Pessimistic transactions, डेटा में बदलाव करने से रोकने के लिए, डेटाबेस लॉक का इस्तेमाल करते हैं.

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

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

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

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

एक साथ चलने वाली कार्रवाइयों को कंट्रोल करने के मोड की डिफ़ॉल्ट सेटिंग

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

• मोबाइल / वेब SDK टूल, optimistic concurrency controls का इस्तेमाल करते हैं. मोबाइल और वेब SDK टूल, इस सेटिंग से अलग तरीके से काम करते हैं, क्योंकि वे हमेशा optimistic concurrency की नकल करते हैं.
• सर्वर क्लाइंट लाइब्रेरी, डेटाबेस सेटिंग के concurrency controls का इस्तेमाल करती हैं.

एक साथ चलने वाली कार्रवाइयों को कंट्रोल करने का मोड देखना

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

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

एक साथ चलने वाली कार्रवाइयों को कंट्रोल करने का मोड बदलना

अपने डेटाबेस के सर्वर-साइड concurrency mode को बदलने के लिए, 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 टूल, दस्तावेज़ के वर्शन पर राइट प्रीकंडीशन का इस्तेमाल करके, optimistic concurrency transactions की नकल करते हैं. यह नकल, डेटाबेस के concurrency mode की सेटिंग के बावजूद होती है. मोबाइल और वेब SDK टूल, लेन-देन की इन-बिल्ट सुविधा का इस्तेमाल नहीं करते. इसलिए, अगर डेटाबेस concurrency mode को PESSIMISTIC के लिए कॉन्फ़िगर किया गया है, तब भी मोबाइल क्लाइंट, optimistic तरीके से काम करते हैं.

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

सर्वर क्लाइंट लाइब्रेरी में डेटा से जुड़े विवाद

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

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

• Standard edition, pessimistic concurrency controls का इस्तेमाल करता है और यह मानकर चलता है कि इंतज़ार का समय कम होगा और डेटाबेस से भरोसेमंद कनेक्शन होगा.

क्रम से लगाए जा सकने की सुविधा के लिए आइसोलेशन

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

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

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

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

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

यह गारंटी तब भी लागू होनी चाहिए, जब डेटाबेस एक साथ कई लेन-देन करता हो. इस गारंटी को तोड़ने वाले विवादों को हल करने के लिए, डेटाबेस को concurrency controls लागू करने होंगे.

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

कमिट करने के समय के हिसाब से क्रम से लगाए जा सकने की सुविधा के लिए आइसोलेशन

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

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

• Cloud Firestore लेन-देन को कमिट करने के समय के हिसाब से क्रम से कमिट करता है.
• Cloud Firestore लेन-देन को एक साथ चलने वाली उन कार्रवाइयों से आइसोलेट करता है जिन्हें बाद में कमिट किया जाता है.

एक साथ चलने वाली कार्रवाइयों के बीच डेटा से जुड़े विवाद की स्थिति में, Cloud Firestore विवाद को हल करने के लिए, optimistic और pessimistic concurrency controls का इस्तेमाल करता है.

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

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

डेटा से जुड़े विवाद की समस्याएं

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