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

इस पेज पर, ट्रांज़ैक्शनल डेटा कंटेंशन, सीरियलाइज़ेबिलिटी, और आइसोलेशन के बारे में बताया गया है. ट्रांज़ैक्शन कोड के सैंपल देखने के लिए, transactions and batched writes लेख देखें.

ट्रांज़ैक्शन और डेटा कंटेंशन

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

डेटा कंटेंशन

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

Cloud Firestore डेटा कंटेंशन को हल करने के लिए, किसी एक कार्रवाई में देरी करता है या उसे पूरा नहीं होने देता. The 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) use the बिल्ट-इन ट्रांज़ैक्शन की सुविधा का इस्तेमाल करती हैं. ये ट्रांज़ैक्शन, डेटाबेस-लेवल के concurrency mode की सेटिंग का इस्तेमाल करते हैं. साथ ही, डिफ़ॉल्ट सेटिंग, एडिशन पर निर्भर करती है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

किसी ट्रांज़ैक्शन के अंदर आइसोलेशन

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

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

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