ज़मीन पर काम करने वाले फ़्लीट से मिलने वाले, रीयल टाइम के आस-पास के सिग्नल, कारोबारों के लिए कई तरह से काम के होते हैं. उदाहरण के लिए, कारोबार इनका इस्तेमाल इन कामों के लिए कर सकते हैं:
- अपने फ़्लीट की परफ़ॉर्मेंस की निगरानी करना और संभावित समस्याओं की पहचान करना
- ईटीए और ट्रैकिंग की सटीक जानकारी देकर, ग्राहक सेवा को बेहतर बनाना
- कमियों की पहचान करके और उन्हें ठीक करके, लागत कम करना
- ड्राइवर के बर्ताव की निगरानी करके और संभावित खतरों की पहचान करके, सुरक्षा को बेहतर बनाना
- ड्राइवर के रूट और शेड्यूल को ऑप्टिमाइज़ करके, काम की रफ़्तार बढ़ाना
- वाहन की जगह और सेवा के घंटों को ट्रैक करके, नियमों का पालन करना
इस दस्तावेज़ में बताया गया है कि डेवलपर, Google Maps Platform की "Mobility services" ("Last Mile Fleet Solution" (LMFS) या "On-demand Rides and Deliveries Solution" (ODRD)) से मिलने वाले सिग्नल को, कार्रवाई करने लायक कस्टम इवेंट में कैसे बदल सकते हैं. इसमें GitHub पर उपलब्ध, Fleet Events Reference Solution के मुख्य कॉन्सेप्ट और डिज़ाइन से जुड़े फ़ैसलों के बारे में भी बताया गया है.
यह दस्तावेज़ इनके लिए काम का है:
- आर्किटेक्ट जो Google Maps Platform की "Mobility services" और इसके मुख्य कॉम्पोनेंट "Fleet Engine" के बारे में जानते हैं. "Mobility services" का इस्तेमाल पहली बार करने वाले लोगों के लिए, हमारा सुझाव है कि वे अपनी ज़रूरतों के हिसाब से, Last Mile Fleet Solution और/या On-demand Rides and Deliveries Solution, के बारे में जानकारी हासिल करें.
- आर्किटेक्ट जो Google Cloud के बारे में जानते हैं. Google Cloud का इस्तेमाल पहली बार करने वाले लोगों के लिए, हमारा सुझाव है कि वे Google Cloud पर स्ट्रीमिंग डेटा पाइपलाइन बनाना लेख पढ़ें.
- अगर आपका टारगेट अन्य एनवायरमेंट या सॉफ़्टवेयर स्टैक हैं, तो Fleet Engine के इंटिग्रेशन पॉइंट और मुख्य बातों को समझने पर फ़ोकस करें. ये बातें, आपके लिए अब भी काम की होंगी.
- वे लोग जिनकी दिलचस्पी यह जानने में है कि फ़्लीट से इवेंट कैसे जनरेट किए जा सकते हैं और उनका इस्तेमाल कैसे किया जा सकता है.
इस दस्तावेज़ को पढ़ने के बाद, आपको स्ट्रीमिंग सिस्टम के मुख्य एलिमेंट और बातों के बारे में बुनियादी जानकारी मिल जाएगी. साथ ही, आपको Google Maps Platform और Google Cloud के उन बिल्डिंग ब्लॉक के बारे में भी पता चल जाएगा जिनसे Fleet Events Reference Solution बनता है.
Fleet Events Reference Solution की खास जानकारी
Fleet Events Reference Solution, ओपन सोर्स सॉल्यूशन है. इसकी मदद से, Mobility के ग्राहक और पार्टनर, Fleet Engine और Google Cloud के कॉम्पोनेंट पर मुख्य इवेंट जनरेट कर सकते हैं. फ़िलहाल, रेफ़रंस सॉल्यूशन, Last Mile Fleet Solution का इस्तेमाल करने वाले ग्राहकों के लिए उपलब्ध है. आने वाले समय में, यह On-demand Rides and Delivery के लिए भी उपलब्ध होगा.
यह सॉल्यूशन, टास्क या यात्राओं से जुड़े खास डेटा में होने वाले बदलावों के आधार पर, इवेंट अपने-आप जनरेट करता है. इन इवेंट का इस्तेमाल करके, स्टेकहोल्डर को सूचनाएं भेजी जा सकती हैं. साथ ही, अपने फ़्लीट के लिए अन्य कार्रवाइयां ट्रिगर की जा सकती हैं. यहां कुछ सूचनाओं के उदाहरण दिए गए हैं:
- टास्क के लिए ईटीए में बदलाव
- टास्क के लिए ईटीए में बदलाव
- टास्क के लिए ईटीए में बदलाव
- टास्क के लिए ईटीए में बदलाव
- TaskOutcome स्टेटस में बदलाव
रेफ़रंस सॉल्यूशन के हर कॉम्पोनेंट को, अपने कारोबार की ज़रूरतों के हिसाब से बनाया जा सकता है.
लॉजिकल बिल्डिंग ब्लॉक
डायग्राम : इस डायग्राम में, Fleet Events Reference Solution बनाने वाले मुख्य बिल्डिंग ब्लॉक दिखाए गए हैं
रेफ़रंस सॉल्यूशन में ये कॉम्पोनेंट शामिल हैं:
- इवेंट का सोर्स: वह जगह जहां से ओरिजनल इवेंट स्ट्रीम आती है. "Last Mile Fleet Solution" या "On-demand Rides and Deliveries Solution" का इंटिग्रेशन, Cloud Logging के साथ होता है. इससे, Fleet Engine RPC कॉल लॉग को डेवलपर के लिए उपलब्ध इवेंट स्ट्रीम में बदला जा सकता है. यह इस्तेमाल करने के लिए मुख्य सोर्स है.
- प्रोसेसिंग: इस ब्लॉक में, रॉ आरपीसी कॉल लॉग को स्टेट में बदलाव वाले इवेंट में बदला जाता है.
यह ब्लॉक, लॉग इवेंट की स्ट्रीम पर काम करता है. इस तरह के बदलाव का पता लगाने के लिए, इस कॉम्पोनेंट को स्टेट स्टोर की ज़रूरत होती है, ताकि नए आने वाले इवेंट की तुलना पिछले इवेंट से करके बदलाव का पता लगाया जा सके. ऐसा हो सकता है कि इवेंट में हमेशा काम की सारी जानकारी शामिल न हो. ऐसे मामलों में, यह ब्लॉक ज़रूरत के हिसाब से बैकएंड को लुकअप कॉल कर सकता है.
- स्टेट स्टोर: कुछ प्रोसेसिंग फ़्रेमवर्क, इंटरमीडिएट डेटा को अपने-आप सेव करते हैं. हालांकि, अगर ऐसा नहीं है, तो स्टेट को सेव करने के लिए, K-V टाइप डेटा परसिस्टेंस सेवा का इस्तेमाल किया जा सकता है. ऐसा इसलिए, क्योंकि ये किसी वाहन और इवेंट टाइप के लिए यूनीक होने चाहिए.
- सिंक (कस्टम इवेंट): स्टेट में हुए बदलाव की जानकारी, किसी भी ऐसे ऐप्लिकेशन या सेवा के लिए उपलब्ध होनी चाहिए जिसे इससे फ़ायदा मिल सकता है. इसलिए, इस कस्टम इवेंट को डाउनस्ट्रीम इस्तेमाल के लिए, इवेंट डिलीवरी सिस्टम पर पब्लिश करना एक सही विकल्प है.
- डाउनस्ट्रीम सेवा: यह वह कोड है जो जनरेट किए गए इवेंट का इस्तेमाल करता है और आपके इस्तेमाल के उदाहरण के हिसाब से कार्रवाइयां करता है.
सेवा चुनना
"Last Mile Fleet Solution" या "On-demand Rides and Deliveries Solution" (तीसरी तिमाही के आखिर में उपलब्ध होगा) के लिए, रेफ़रंस सॉल्यूशन लागू करने के लिए, "सोर्स" और "सिंक '' के लिए टेक्नोलॉजी चुनना आसान है. वहीं दूसरी ओर, "प्रोसेसिंग" के लिए कई विकल्प मौजूद हैं. रेफ़रंस सॉल्यूशन के लिए, Google की इन सेवाओं को चुना गया है.
डायग्राम : इस डायग्राम में, रेफ़रंस सॉल्यूशन लागू करने के लिए, Google Cloud की सेवा दिखाई गई है
Cloud Project का लेआउट
हमारा सुझाव है कि आप डिफ़ॉल्ट रूप से, मल्टी-प्रोजेक्ट डिप्लॉयमेंट का इस्तेमाल करें. ऐसा इसलिए, ताकि Google Maps Platform और Google Cloud के इस्तेमाल को साफ़ तौर पर अलग किया जा सके और इसे अपनी पसंद के बिलिंग अरेंजमेंट से जोड़ा जा सके.
इवेंट का सोर्स
"Last Mile Fleet Solution" और "On-demand Rides and Deliveries Solution" , एपीआई अनुरोध और जवाब के पेलोड को Cloud Logging में लिखते हैं. Cloud Logging, लॉग को अपनी पसंद की एक या उससे ज़्यादा सेवाओं तक पहुंचाता है. यहां Cloud Pub/Sub पर रूट करना एक सही विकल्प है. इससे, बिना कोडिंग के लॉग को इवेंट स्ट्रीम में बदला जा सकता है.
- लॉगिंग | फ़्लीट परफ़ॉर्मेंस (LMFS के उपयोगकर्ताओं के लिए)
- लॉगिंग | यात्रा और ऑर्डर की प्रोसेस (ODRD के उपयोगकर्ताओं के लिए)
- Pub/Sub पर रूट किए गए लॉग देखना : लॉगिंग → Pub/Sub इंटिग्रेशन की खास जानकारी
सिंक
Google Cloud में, Cloud Pub/Sub रीयल टाइम के आस-पास मैसेज डिलीवरी सिस्टम है. जिस तरह सोर्स से इवेंट, Pub/Sub पर डिलीवर किए जाते हैं, उसी तरह कस्टम इवेंट भी डाउनस्ट्रीम इस्तेमाल के लिए, Pub/Sub पर पब्लिश किए जाते हैं.
प्रोसेसिंग
इवेंट की प्रोसेसिंग में, इन कॉम्पोनेंट की भूमिका होती है. अन्य बिल्डिंग ब्लॉक की तरह, प्रोसेसिंग कॉम्पोनेंट पूरी तरह से सर्वरलेस होते हैं और अप और डाउन, दोनों तरह से अच्छी तरह से स्केल होते हैं.
- शुरुआती रिलीज़ के लिए, Cloud Functions को कंप्यूट
प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सकता है (*)
- यह सर्वरलेस है. लागत मैनेज करने के लिए, इसे स्केल किया जा सकता है
- प्रोग्रामिंग लैंग्वेज के तौर पर Java का इस्तेमाल किया जा सकता है. ऐसा इसलिए, क्योंकि Fleet Engine से जुड़े एपीआई के लिए क्लाइंट लाइब्रेरी उपलब्ध हैं. इससे, इसे लागू करना आसान हो जाता है
- Cloud Firestore को स्टेट स्टोर के तौर पर इस्तेमाल किया जा सकता है
- यह सर्वरलेस की-वैल्यू स्टोर है
- Cloud Pub/Sub को इंटिग्रेशन पॉइंट के तौर पर इस्तेमाल किया जा सकता है
अपस्ट्रीम और डाउनस्ट्रीम कॉम्पोनेंट के साथ
- यह रीयल टाइम के आस-पास इंटिग्रेशन है
फ़ंक्शन को डिफ़ॉल्ट सेटिंग के साथ इस्तेमाल किया जा सकता है. हालांकि, इन्हें फिर से कॉन्फ़िगर भी किया जा सकता है. कॉन्फ़िगरेशन पैरामीटर, डिप्लॉयमेंट स्क्रिप्ट के ज़रिए सेट किए जाते हैं. इनके बारे में, संबंधित Terraform मॉड्यूल के README में पूरी जानकारी दी गई है.
*ध्यान दें: इस रेफ़रंस सॉल्यूशन में, ऐसे वैकल्पिक तरीके रिलीज़ करने की योजना है जिनसे अलग-अलग ज़रूरी शर्तें पूरी की जा सकती हैं.
डिप्लॉयमेंट
रेफ़रंस सॉल्यूशन के डिप्लॉयमेंट की प्रोसेस को दोहराने, पसंद के मुताबिक बनाने, सोर्स कोड को कंट्रोल करने, और सुरक्षित बनाने के लिए, Terraform को ऑटोमेशन टूल के तौर पर चुना गया है. Terraform, IaC (Infrastructure as Code) टूल है, जिसका इस्तेमाल बड़े पैमाने पर किया जाता है. यह Google Cloud के लिए बेहतर तरीके से काम करता है.
- Google Cloud Platform Provider: "Google Cloud Platform Provider" के साथ काम करने वाले रिसॉर्स का दस्तावेज़
- Terraform का इस्तेमाल करने के सबसे सही तरीके: Google Cloud में इसे लागू करने के सबसे सही तरीके के बारे में जानकारी
- Terraform Registry: Google और कम्यूनिटी के साथ काम करने वाले अन्य मॉड्यूल
Terraform मॉड्यूल
रेफ़रंस सॉल्यूशन के डिप्लॉयमेंट के लिए, एक बड़ा मॉड्यूल बनाने के बजाय, ऑटोमेशन के फिर से इस्तेमाल किए जा सकने वाले ब्लॉक को Terraform मॉड्यूल के तौर पर लागू किया जाता है. इनका इस्तेमाल अलग-अलग किया जा सकता है. मॉड्यूल में, कॉन्फ़िगर किए जा सकने वाले कई वैरिएबल होते हैं. इनमें से ज़्यादातर की डिफ़ॉल्ट वैल्यू होती हैं, ताकि आप तुरंत काम शुरू कर सकें. हालांकि, आपके पास अपनी ज़रूरतों और प्राथमिकताओं के हिसाब से इन्हें पसंद के मुताबिक बनाने की सुविधा भी होती है.
रेफ़रंस सॉल्यूशन में शामिल मॉड्यूल:
- Fleet Engine के लिए लॉगिंग का कॉन्फ़िगरेशन: Fleet Engine के साथ इस्तेमाल करने के लिए, Cloud Logging से जुड़े कॉन्फ़िगरेशन को ऑटोमेट करें. रेफ़रंस सॉल्यूशन में, इसका इस्तेमाल Fleet Engine से जुड़े लॉग को किसी तय Pub/Sub विषय पर रूट करने के लिए किया जाता है.
- Fleet Events के लिए Cloud Function का डिप्लॉयमेंट: इसमें, सैंपल फ़ंक्शन कोड का डिप्लॉयमेंट शामिल होता है. साथ ही, यह सुरक्षित तरीके से अलग-अलग प्रोजेक्ट को इंटिग्रेट करने के लिए ज़रूरी अनुमति सेटिंग के ऑटोमेशन को भी मैनेज करता है.
- पूरे रेफ़रंस सॉल्यूशन का डिप्लॉयमेंट: यह पिछले दो मॉड्यूल को कॉल करता है और पूरे सॉल्यूशन को रैप करता है.
सुरक्षा
IAM को, कम से कम विशेषाधिकार के सिद्धांत लागू करने के लिए अपनाया जाता है. इसके साथ ही, Google Cloud के सुरक्षा से जुड़े सबसे सही तरीके भी लागू किए जाते हैं. जैसे, सेवा खाते के तौर पर काम करना. Google Cloud, सुरक्षा पर ज़्यादा कंट्रोल पाने के लिए आपको क्या-क्या सुविधाएं देता है, यह बेहतर तरीके से समझने के लिए, ये लेख पढ़ें.
अगली कार्रवाइयां
अब आपके पास Fleet Events Reference Solution को ऐक्सेस करने और इसके बारे में ज़्यादा जानने का विकल्प है. शुरू करने के लिए, GitHub पर जाएं.
अपेंडिक्स
अपनी ज़रूरतें इकट्ठा करना
हमारा सुझाव है कि आप प्रोसेस की शुरुआत में ही अपनी ज़रूरतें इकट्ठा कर लें.
सबसे पहले, रीयल टाइम के आस-पास के इवेंट में आपकी दिलचस्पी क्यों है या आपको इनका इस्तेमाल क्यों करना है, इस बारे में जानकारी इकट्ठा करें. यहां कुछ सवाल दिए गए हैं जिनसे आपको अपनी ज़रूरतों को समझने में मदद मिलेगी.
- इवेंट स्ट्रीम के काम की होने के लिए, उसमें कौनसी जानकारी होनी चाहिए?
- क्या नतीजे, Google की सेवाओं में कैप्चर किए गए या जनरेट किए गए डेटा से ही निकाले जा सकते हैं? या, इंटिग्रेट किए गए बाहरी सिस्टम से डेटा को बेहतर बनाने की ज़रूरत है? अगर हां, तो वे सिस्टम कौनसे हैं और वे कौनसे इंटिग्रेशन इंटरफ़ेस ऑफ़र करते हैं?
- कारोबार के तौर पर, आपको किन मेट्रिक को मेज़र करना है? इन्हें कैसे तय किया जाता है?
- अगर आपको इवेंट के आधार पर मेट्रिक का अनुमान लगाना है, तो इसके लिए किस तरह के एग्रीगेशन की ज़रूरत होगी? लॉजिकल चरणों को समझने की कोशिश करें. (उदाहरण के लिए, संसाधनों की कमी के दौरान परफ़ॉर्मेंस का अनुमान लगाने के लिए, पीक घंटों के दौरान फ़्लीट के सबसेट के लिए, एसएलओ के मुकाबले ईटीए/एटीए की तुलना करें.)
- बैच के बजाय, इवेंट पर आधारित मॉडल में आपकी दिलचस्पी क्यों है? क्या यह कम लेटेंसी (कार्रवाई में लगने वाला समय) या इंटिग्रेशन (तेज़ी) के लिए है?
- अगर कम लेटेंसी के लिए है, तो "कम" की परिभाषा तय करें. मिनट? सेकंड? एक सेकंड से भी कम? और कितनी लेटेंसी?
- क्या आपने टीम के तौर पर, पहले से ही किसी टेक्नोलॉजी स्टैक और उससे जुड़ी स्किल में निवेश किया है? अगर हां, तो वह क्या है और वह कौनसे इंटिग्रेशन पॉइंट उपलब्ध कराता है?
- क्या ऐसी कोई ज़रूरी शर्तें हैं जिन्हें आपके मौजूदा सिस्टम पूरा नहीं कर सकते या आपके फ़्लीट से आने वाले इवेंट को प्रोसेस करते समय उन्हें पूरा करने में मुश्किल हो सकती है?
डिज़ाइन से जुड़े सिद्धांत
किसी भी काम को करने से पहले, उसकी प्रोसेस के बारे में सोचना हमेशा काम का होता है. इससे डिज़ाइन से जुड़े फ़ैसले लेने में मदद मिलती है. खास तौर पर, तब जब आपके पास चुनने के लिए कई विकल्प हों.
- आसान विकल्पों को डिफ़ॉल्ट के तौर पर चुनें.
- कम समय में वैल्यू पाने वाले विकल्पों को डिफ़ॉल्ट के तौर पर चुनें. कम कोड, सीखने में कम समय लगना.
- लेटेंसी और परफ़ॉर्मेंस के लिए, ज़्यादा से ज़्यादा ऑप्टिमाइज़ेशन के बजाय, अपने सेट किए गए बार को पूरा करने का लक्ष्य रखें. साथ ही, ज़्यादा ऑप्टिमाइज़ेशन से बचें, क्योंकि इससे अक्सर जटिलता बढ़ जाती है.
- लागत के लिए भी यही बात लागू होती है. लागत को सही रखें. ऐसा हो सकता है कि अभी आप ऐसी स्थिति में न हों कि ज़्यादा वैल्यू वाली, लेकिन महंगी सेवाओं का इस्तेमाल कर सकें.
- एक्सपेरिमेंटल फ़ेज़ में, स्केल अप करने के साथ-साथ स्केल डाउन करना भी ज़रूरी हो सकता है. ऐसे प्लैटफ़ॉर्म का इस्तेमाल करें जो कैप के साथ स्केल अप करने और स्केल डाउन (आदर्श रूप से शून्य तक) करने की सुविधा देता हो, ताकि कुछ न करने पर भी आपको पैसे खर्च न करने पड़ें. हमेशा चालू रहने वाले इन्फ़्रास्ट्रक्चर के साथ बेहतर परफ़ॉर्मेंस को बाद में इस्तेमाल किया जा सकता है. ऐसा तब किया जा सकता है, जब आपको इसकी ज़रूरत का भरोसा हो.
- ऑब्ज़र्व करें और मेज़र करें, ताकि बाद में यह पता लगाया जा सके कि आपको किस पर काम करना है.
- सेवाओं को एक-दूसरे से अलग रखें. इससे बाद में, एक-एक करके सेवाओं को बदलना आसान हो जाता है.
- आखिरी और सबसे ज़रूरी बात, सुरक्षा को कमज़ोर नहीं रखा जा सकता. पब्लिक क्लाउड एनवायरमेंट पर चलने वाली सेवा के तौर पर, सिस्टम के लिए कोई भी असुरक्षित दरवाज़ा नहीं हो सकता.
स्ट्रीमिंग के कॉन्सेप्ट
अगर आपने इवेंट पर आधारित या स्ट्रीमिंग का इस्तेमाल पहली बार किया है, तो कुछ मुख्य कॉन्सेप्ट के बारे में जानना ज़रूरी है. इनमें से कुछ कॉन्सेप्ट, बैच प्रोसेसिंग से काफ़ी अलग हो सकते हैं.
- स्केल : बैच प्रोसेसिंग में, आम तौर पर आपको प्रोसेस किए जाने वाले डेटा की मात्रा के बारे में पता होता है. हालांकि, स्ट्रीमिंग में ऐसा नहीं होता. किसी शहर में ट्रैफ़िक जाम होने की वजह से, किसी खास इलाके से अचानक कई इवेंट जनरेट हो सकते हैं. आपको इसे प्रोसेस करना होगा.
- विंडोइंग : इवेंट को एक-एक करके प्रोसेस करने के बजाय, अक्सर ऐसा होता है कि आपको किसी टाइमलाइन पर इवेंट को छोटे-छोटे "विंडो" में ग्रुप करना होता है, ताकि उन्हें एक यूनिट के तौर पर इस्तेमाल किया जा सके. "फ़िक्स्ड विंडो (उदाहरण के लिए, हर कैलेंडर दिन)", "स्लाइडिंग विंडो (पिछले पांच मिनट)", "सेशन विंडो (इस यात्रा के दौरान)" जैसी अलग-अलग विंडोइंग रणनीतियां होती हैं. आपको इनमें से किसी एक को चुनना होता है. विंडो जितनी लंबी होगी, नतीजे दिखाने में उतनी ही ज़्यादा देरी होगी. अपनी ज़रूरतों के हिसाब से सही मॉडल और कॉन्फ़िगरेशन चुनें.
- ट्रिगर करना : कुछ मामलों में, आपके पास अपेक्षाकृत लंबी विंडो के अलावा कोई दूसरा विकल्प नहीं होता. हालांकि, आपको इवेंट जनरेट करने के लिए, विंडो के आखिर तक इंतज़ार नहीं करना होता. इसके बजाय, बीच-बीच में इंटरमीडिएट नतीजे जनरेट करने होते हैं. इस कॉन्सेप्ट को उन मामलों में लागू किया जा सकता है जहां पहले तुरंत नतीजे जनरेट करने और फिर उन्हें बाद में ठीक करने की वैल्यू होती है. मान लें कि डिलीवरी के 25%, 50%, और 75% पूरे होने पर, इंटरमीडिएट स्टेटस जनरेट करना है.
- ऑर्डर करना : ज़रूरी नहीं है कि इवेंट, सिस्टम तक उसी क्रम में पहुंचें जिस क्रम में वे जनरेट किए गए थे. खास तौर पर, उन मामलों में जहां मोबाइल नेटवर्क पर बातचीत शामिल होती है. इससे, देरी और जटिल रूटिंग पाथ जुड़ जाते हैं. आपको "इवेंट टाइम" (जब इवेंट असल में हुआ) और "प्रोसेस टाइम" (जब इवेंट सिस्टम तक पहुंचा) के बीच का अंतर पता होना चाहिए. साथ ही, इवेंट को उसी हिसाब से मैनेज करना चाहिए. आम तौर पर, आपको "इवेंट टाइम" के आधार पर इवेंट प्रोसेस करने होते हैं.
- मैसेज डिलीवरी - कम से कम एक बार बनाम ठीक एक बार: अलग-अलग इवेंट प्लैटफ़ॉर्म पर, इनके लिए अलग-अलग सहायता उपलब्ध होती है. आपको अपने इस्तेमाल के उदाहरण के हिसाब से, फिर से कोशिश करने या डुप्लीकेट डेटा हटाने की रणनीतियों पर विचार करना होगा.
- पूरा होना : ऑर्डर में बदलाव की तरह, मैसेज के खो जाने की भी संभावना होती है. ऐसा ऐप्लिकेशन और डिवाइस के बंद होने की वजह से हो सकता है. जैसे, डिवाइस की बैटरी लाइफ़ खत्म हो जाना, फ़ोन को अनजाने में नुकसान पहुंचना, टनल में कनेक्टिविटी खो जाना या कोई ऐसा मैसेज जो मिला, लेकिन स्वीकार की जा सकने वाली विंडो के बाहर मिला. अधूरे डेटा से आपके नतीजों पर क्या असर पड़ेगा?
यह पूरी सूची नहीं है, बल्कि एक परिचय है. यहां कुछ ऐसे लेख दिए गए हैं जिन्हें पढ़ने का सुझाव दिया जाता है. इनसे आपको हर कॉन्सेप्ट को बेहतर तरीके से समझने में मदद मिल सकती है.
योगदानकर्ता
Google इस दस्तावेज़ को मैनेज करता है. इसे मूल रूप से इन लोगों ने लिखा था.
मुख्य लेखक:
- मैरी पिशनी | प्रॉडक्ट मैनेजर, Google Maps Platform
- एथल बाओ| सॉफ़्टवेयर इंजीनियर, Google Maps Platform
- मोहनाद अल्मिसकी | सॉफ़्टवेयर इंजीनियर, Google Maps Platform
- नाओया मोरीतानी | सॉल्यूशन इंजीनियर, Google Maps Platform