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

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

लेन-देन और डेटा से जुड़ी समस्याएं

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

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

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 के लिए कॉन्फ़िगर किया गया है, तब भी मोबाइल क्लाइंट, optimistically काम करते हैं.

मोबाइल/वेब 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 का इस्तेमाल करके, समस्या को हल करता है.

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

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

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

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