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

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

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

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

डेटा कंटेंशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Cloud Firestore, लेन-देन को कमिट किए जाने के समय के हिसाब से कमिट करता है.
• Cloud Firestore, लेन-देन को एक साथ होने वाले उन ऑपरेशन से अलग रखता है जिन्हें बाद में कमिट किया जाता है.

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

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

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

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

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