MongoDB के साथ काम करने वाले Firestore के लिए Change Streams की मदद से, ऐप्लिकेशन किसी कलेक्शन या पूरे डेटाबेस में किए गए रीयल-टाइम बदलावों (डेटा डालना, अपडेट करना, और मिटाना) को ऐक्सेस कर सकते हैं. चेंज स्ट्रीम, अपडेट को बदलाव के समय के हिसाब से क्रम में लगाती है.
Change Streams को MongoDB के साथ काम करने वाले एपीआई और MongoDB के पारंपरिक ड्राइवर के ज़रिए ऐक्सेस किया जा सकता है. MongoDB के साथ काम करने वाले Firestore में, Change Streams को लागू करने से, डेटा को लिखने और पढ़ने की किसी भी क्षमता को मैनेज किया जा सकता है. इसके लिए, डेटा को लिखने और पढ़ने की प्रोसेस को एक साथ चलाने के लिए, अपने-आप पार्टिशन करने की सुविधा को लागू किया जाता है. इससे आपको हाई-थ्रूपुट वर्कलोड बनाने में मदद मिलती है. Cloud Firestore और अन्य स्टोरेज सेवाओं के बीच, डेटा माइग्रेशन और डेटा सिंक करने के इन्फ़्रास्ट्रक्चर को भी बेहतर बनाया जा सकता है.
MongoDB ड्राइवर के साथ काम करने के अलावा, Cloud Firestore का इस्तेमाल करके, चेंज स्ट्रीम को एक साथ पढ़ा जा सकता है. इससे आपको एक साथ कई हाई-थ्रूपुट रीड वर्कलोड बनाने में मदद मिलती है. हर स्ट्रीम, नतीजों के अच्छी तरह से बांटे गए हिस्से को दिखाती है.
चेंज स्ट्रीम में ये सुविधाएं काम करती हैं:
- डेटाबेस या कलेक्शन के स्कोप के साथ कॉन्फ़िगर की जा सकने वाली चेंज स्ट्रीम.
- चेंज स्ट्रीम के लिए डेटा के रखरखाव की अवधि, जो इसे बनाते समय तय की जाती है. डिफ़ॉल्ट रूप से, डेटा सात दिनों तक सेव रहता है. हालांकि, इसे कम से कम एक दिन के लिए सेव किया जा सकता है. डेटा को सेव रखने की अवधि, एक दिन से लेकर ज़्यादा से ज़्यादा सात दिनों तक हो सकती है. डेटा को सेव रखने की अवधि को, बनाने के बाद बदला नहीं जा सकता. डेटा के रखरखाव की अवधि बदलने के लिए, आपको बदलाव की स्ट्रीम को हटाना होगा और उसे फिर से बनाना होगा.
delete,insert,update, औरdrop, ऐसे इवेंट हैं जिनमें बदलाव किया जा सकता है. इन्हेंdb.collection.watch()औरdb.watch()का इस्तेमाल करके देखा जा सकता है.updateDescription.updatedFieldsमें अपडेट के अंतर शामिल हैं.fullDocumentऔरfullDocumentBeforeChangeके सभी विकल्प.- अपडेट के लिए पूरा दस्तावेज़ देखा जा रहा है.
- बदले जाने, अपडेट किए जाने या मिटाए जाने से पहले, दस्तावेज़ की प्री-इमेज.
- बदले जाने या अपडेट किए जाने के बाद, दस्तावेज़ की इमेज.
- एक घंटे से ज़्यादा पुरानी इमेज के लिए, पिछले समय की रिकवरी (पीआईटीआर) की सुविधा चालू करनी होगी.
- फिर से शुरू करने के सभी विकल्प, जिनमें
resumeAfterऔरstartAfterशामिल हैं. - बदलावों पर नज़र रखने के लिए
watch()का इस्तेमाल करते समय, एग्रीगेशन के चरणों को चेन किया जा सकता है. जैसे,$addFields,$match,$project,$replaceRoot,$replaceWith,$set, और$unset.
चेंज स्ट्रीम कॉन्फ़िगर करना
किसी डेटाबेस के लिए मौजूदा चेंज स्ट्रीम बनाने, हटाने या देखने के लिए, Google Cloud कंसोल का इस्तेमाल करें.
भूमिकाएं और अनुमतियां
चेंज स्ट्रीम बनाने, मिटाने, और उनकी सूची बनाने के लिए, प्रिंसिपल के पास क्रमशः datastore.schemas.create, datastore.schemas.delete, और datastore.schemas.list की पहचान और ऐक्सेस मैनेजमेंट (आईएएम) अनुमतियां होनी चाहिए.
उदाहरण के लिए, Datastore इंडेक्स एडमिन (roles/datastore.indexAdmin) की भूमिका, ये अनुमतियां देती है.
चेंज स्ट्रीम बनाना
इससे जुड़े चेंज स्ट्रीम कर्सर को खोलने से पहले, आपको एक चेंज स्ट्रीम बनानी होगी. कलेक्शन या डेटाबेस बनाते समय, चेंज स्ट्रीम को अपने-आप चालू करने की सुविधा काम नहीं करती.
चेंज स्ट्रीम बनाने के लिए, Google Cloud Console का इस्तेमाल करें.
-
Google Cloud console में, डेटाबेस पेज पर जाएं.
- सूची में से, MongoDB के साथ काम करने वाला Firestore डेटाबेस चुनें. Firestore Studio पैनल खुलता है.
- एक्सप्लोरर पैनल में, चेंज स्ट्रीम नोड ढूंढें. इसके बाद, ज़्यादा कार्रवाइयां पर क्लिक करें और चेंज स्ट्रीम बनाएं को चुनें.
- चेंज स्ट्रीम का कोई यूनीक नाम, स्कोप, और डेटा के रखरखाव की अवधि डालें. इसके बाद, सेव करें पर क्लिक करें
बदलावों की स्ट्रीम देखना
Google Cloud Console में, Change Streams के बारे में जानकारी देखी जा सकती है.
-
Google Cloud console में, डेटाबेस पेज पर जाएं.
- सूची में से, MongoDB के साथ काम करने वाला Firestore डेटाबेस चुनें. Firestore Studio पैनल खुलता है.
- Explorer पैनल में, Change streams नोड ढूंढें.
- नोड को खोलने या बंद करने के लिए, नोड को टॉगल करें पर क्लिक करें.
चेंज स्ट्रीम मिटाना
चेंज स्ट्रीम मिटाने के लिए, Google Cloud Console का इस्तेमाल करें.
-
Google Cloud console में, डेटाबेस पेज पर जाएं.
- सूची में से, MongoDB के साथ काम करने वाला Firestore डेटाबेस चुनें. Firestore Studio पैनल खुलता है.
- Explorer पैनल में, Change streams नोड ढूंढें.
- नोड को खोलने या बंद करने के लिए, नोड को टॉगल करें पर क्लिक करें.
- एक्सप्लोरर में, वह चेंज स्ट्रीम ढूंढें जिसे आपको मिटाना है.
- ज़्यादा कार्रवाइयां पर क्लिक करें और फिर चेंज स्ट्रीम मिटाएं को चुनें.
- डायलॉग बॉक्स में, चेंज स्ट्रीम का नाम डालकर मिटाने की पुष्टि करें. इसके बाद, मिटाएं पर क्लिक करें.
चेंज स्ट्रीम कर्सर खोलना या फिर से शुरू करना
यहां दिए गए उदाहरणों में, बदलाव की स्ट्रीम के कर्सर को बनाने, फिर से शुरू करने, और कॉन्फ़िगर करने का तरीका बताया गया है.
चेंज स्ट्रीम कर्सर बनाने से पहले, आपको डेटाबेस या कलेक्शन के लिए, साफ़ तौर पर चेंज स्ट्रीम बनानी होगी.
चेंज स्ट्रीम कर्सर बनाना
नया चेंज स्ट्रीम कर्सर बनाने के लिए, MongoDB ड्राइवर में watch तरीके का इस्तेमाल करें.
किसी डेटाबेस में होने वाले सभी बदलावों को सुनने के लिए, डेटाबेस के दायरे में आने वाली बदलाव स्ट्रीम बनाएं. इसके बाद, db ऑब्जेक्ट पर watch तरीके को कॉल करें.
let cursor = db.watch()
किसी कलेक्शन के लिए कर्सर बनाने के लिए, आपको पहले उस कलेक्शन के लिए चेंज स्ट्रीम बनानी होगी. इसके बाद, उससे जुड़े कलेक्शन पर watch तरीके को कॉल करें.
let cursor = db.my_collection.watch()
चेंज स्ट्रीम कर्सर बनाने के बाद, स्ट्रीमिंग शुरू की जा सकती है.
उदाहरण के लिए, अगर कोई दस्तावेज़ डाला जाता है और कर्सर पर tryNext को कॉल किया जाता है, तो आपको बदलाव की स्ट्रीम पर बदलाव दिखेगा.
let doc = db.my_collection.insertOne({value: "hello world"}) console.log(cursor.tryNext())
अगर दस्तावेज़ को अपडेट और मिटाया जाता है, तो आपको वे बदलाव, बदलावों की स्ट्रीम में दिखते हैं:
db.my_collection.updateOne({"_id": doc.insertedId}, {$set: {value: "hello world!"}}) db.my_collection.deleteOne({"_id": doc.insertedId}}) // Prints the update event console.log(cursor.tryNext()) // Prints the delete event console.log(cursor.tryNext())
चेंज स्ट्रीम को फिर से शुरू करना
चेंज स्ट्रीम को फिर से शुरू करने के लिए, resumeAfter या startAfter विकल्प का इस्तेमाल करें.
बदलाव लॉग में यह तय करने के लिए कि resumeAfter और startAfter को कहां से फिर से शुरू करना है, रीज़्यूम टोकन का इस्तेमाल करें.
// Create a cursor and add one event to the change stream. let cursor = db.my_collection.watch(); db.my_collection.insertOne({value: "hello world"}); let event = cursor.tryNext(); // Get the resume token from the event. let resumeToken = event._id; // Add a new event to the change stream. db.my_collection.insertOne({value: "foobar"}); // Create a new cursor by using the resume token as a starting point. let newCursor = db.my_collection.watch({resumeAfter: resumeToken}) // Log the change event containing the "foobar" value. console.log(newCursor.tryNext())
startAfter का इस्तेमाल करने के लिए:
// Start after the resume token. let startAfterCursor = db.my_collection.watch({startAfter: resumeToken})
अपडेट और मिटाने की प्रोसेस में, पहले और बाद की इमेज शामिल करना
ज़रूरत पड़ने पर, अपडेट और मिटाने वाले बदलाव के इवेंट में, दस्तावेज़ों की पहले और बाद की इमेज शामिल की जा सकती हैं. इमेज की उपलब्धता, पिछले समय की रिकवरी (पीआईटीआर) विंडो पर निर्भर करती है. साथ ही, एक घंटे से ज़्यादा पुरानी दस्तावेज़ की इमेज पढ़ने के लिए, आपको पीआईटीआर चालू करना होगा.
चेंज स्ट्रीम, पीआईटीआर विंडो का फ़ायदा उठाती हैं. इससे, बदलाव के किसी इवेंट से पहले और बाद में दस्तावेज़ का व्यू मिलता है. डिफ़ॉल्ट रूप से, अपडेट इवेंट में एक updateDescription फ़ील्ड होता है. यह फ़ील्ड, अपडेट की कार्रवाई से बदले गए फ़ील्ड का डेल्टा होता है.
किसी बदलाव वाले इवेंट में, बदलाव से पहले और बाद की इमेज शामिल करने के लिए, आपको बदलाव वाली स्ट्रीम क्वेरी में fullDocumentBeforeChange और fullDocument विकल्प तय करने होंगे.
let cursor = db.my_collection.watch({ "fullDocument": "required", "fullDocumentBeforeChange": "required" })
अगर क्वेरी, पीआईटीआर के डेटा के रखरखाव की विंडो से बाहर के किसी दस्तावेज़ को पढ़ने की कोशिश करती है या पीआईटीआर चालू नहीं है, तो required वैल्यू, सर्वर साइड पर गड़बड़ी का मैसेज दिखाती है.
गड़बड़ी दिखाने के बजाय, whenAvailable वैल्यू का इस्तेमाल करके null वैल्यू को दिखाया जा सकता है. ऐसा तब किया जा सकता है, जब इमेज अब उपलब्ध न हों.
let cursor = db.my_collection.watch({ "fullDocument": "whenAvailable", "fullDocumentBeforeChange": "whenAvailable" })
अपडेट में मौजूदा इमेज शामिल करें
डिफ़ॉल्ट रूप से, अपडेट इवेंट में एक updateDescription फ़ील्ड होता है. यह फ़ील्ड, अपडेट ऑपरेशन से बदले गए फ़ील्ड का डेल्टा होता है. इसके बजाय, पूरे दस्तावेज़ का सबसे नया वर्शन देखने के लिए, fullDocument विकल्प में updateLookup वैल्यू का इस्तेमाल करें.
इस सुविधा के लिए, पीआईटीआर की ज़रूरत नहीं होती. यह दस्तावेज़ को खोजने का काम करती है.
let cursor = db.my_collection.watch({ "fullDocument": "updateLookup", })
एक साथ कई रीड ऑपरेशन
थ्रूपुट बढ़ाने के लिए, firestoreWorkerConfig विकल्प का इस्तेमाल करके, चेंज स्ट्रीम क्वेरी को कई वर्कर में बांटा जा सकता है. हर वर्कर, दस्तावेज़ों के अलग-अलग सेट में किए गए बदलावों को दिखाने के लिए ज़िम्मेदार होता है. आपको runCommand या aggregate क्वेरी का इस्तेमाल करके, एक पैरलल कर्सर बनाना होगा.
उदाहरण के लिए, चेंज स्ट्रीम को तीन वर्कर में इस तरह बांटा जा सकता है:
let cursor1 = db.my_collection.aggregate([{ "$changeStream": { "firestoreWorkerConfig": {numWorkers: 3, workerId: 0 }} }]); let cursor2 = db.my_collection.aggregate([{ "$changeStream": { "firestoreWorkerConfig": {numWorkers: 3, workerId: 1 }} }]); let cursor3 = db.my_collection.aggregate([{ "$changeStream": { "firestoreWorkerConfig": {numWorkers: 3, workerId: 2 }} }]);
स्ट्रीम और बैकअप बदलना
बैकअप को वापस लाने की प्रोसेस में, न तो चेंज स्ट्रीम कॉन्फ़िगरेशन और न ही चेंज स्ट्रीम डेटा उपलब्ध होता है. अगर आपने Change Streams की सुविधा वाले डेटाबेस को पहले जैसा किया है, तो आपको डेस्टिनेशन डेटाबेस में उन Change Streams को फिर से बनाना होगा. इससे उस डेटाबेस के लिए कर्सर खोले जा सकेंगे.
बिलिंग
- चेंज स्ट्रीम के लिए, रीड यूनिट और स्टोरेज की लागत चुकानी पड़ती है. चेंज स्ट्रीम की कीमत देखें.
- रीड रिक्वेस्ट के समय से एक घंटे से ज़्यादा पुरानी इमेज को शामिल करने के लिए, आपको पीआईटीआर चालू करना होगा. इसके लिए, पीआईटीआर की लागत चुकानी होगी.
व्यवहार में अंतर
यहां दिए गए सेक्शन में, MongoDB के साथ काम करने वाले Firestore और MongoDB के बीच, चेंज स्ट्रीम में मौजूद अंतर के बारे में बताया गया है.
updateDescription
updateDescription, update इवेंट में मौजूद एक दस्तावेज़ है. इसमें उन फ़ील्ड के बारे में बताया गया है जिन्हें अपडेट करने की प्रोसेस के दौरान अपडेट किया गया या हटाया गया. Cloud Firestore में, ये अहम अंतर हैं:
updateDescriptionमें,truncatedArraysऔरdisambiguatedPathsफ़ील्ड में अपने-आप जानकारी नहीं भरती.updateDescription.updatedFields, किसी दस्तावेज़ में बदलाव करने से पहले और बाद की इमेज के बीच के कैननिकल अंतर को दिखाता है.
मान लें कि किसी दस्तावेज़ की शुरुआती स्थिति यह है:
db.my_collection.insertOne({ _id: 1, root: { array: [{a: 1}, {b: 2}, {c: 3}] } })
पहला सिनेरियो: अरे के सिर्फ़ पहले एलिमेंट को बदलना.
इस स्थिति में, Cloud Firestore का व्यवहार MongoDB से मेल खाता है.
db.my_collection.updateOne( {_id: 1}, {'$set': {"root.array.0.a": 100}} ) { updatedFields: {"root.array.0.a": 100}, removedFields: [] }
दूसरी स्थिति: पूरे कलेक्शन को ओवरराइट करना
इस स्थिति में, ऑपरेशन सिर्फ़ पहले कलेक्शन फ़ील्ड को अपडेट करता है, लेकिन पूरे कलेक्शन को ओवरराइट कर देता है.
Cloud Firestore अपडेट डिफ़, इन दोनों स्थितियों में अंतर नहीं करता. साथ ही, दोनों के लिए एक ही updateDescription.updatedFields दिखाता है:
db.my_collection.updateOne( {_id: 1}, {'$set': {"root.array": [{a: 100}, {b: 2}, {c: 3}]}} ) // In other implementations, updatedFields reflects the mutation itself { updatedFields: { "root.array": [{a: 100}, {b: 2}, {c: 3}] }, removedFields: [] } // Firestore updatedFields is the diff between the before and after versions of the document { updatedFields: {"root.array.0.a": 100}, removedFields: [] }
आगे क्या करना है
- बड़े पैमाने पर डेटा को पढ़ने और लिखने की प्रोसेस को समझना
- क्वेरी को लागू करने की प्रोसेस को ऑप्टिमाइज़ करना