मुझे यकीन है कि आपने इसे "यह निर्भर करता है" आते हुए देखा है।
यह सब कुछ पर निर्भर करता है। और विभाग ए के लिए ग्राहक डेटा साझा करने का समाधान विभाग बी के साथ ग्राहक डेटा साझा करने के लिए पूरी तरह से अलग हो सकता है।
मेरी पसंदीदा अवधारणा जो पिछले कुछ वर्षों में बढ़ी है वह है "अंतिम संगति" की अवधारणा। यह शब्द अमेज़ॅन से वितरित सिस्टम के बारे में बात कर रहा है।
आधार यह है कि एक वितरित उद्यम में डेटा की स्थिति अब पूरी तरह से सुसंगत नहीं हो सकती है, यह "आखिरकार" होगी।
उदाहरण के लिए, जब कोई ग्राहक रिकॉर्ड सिस्टम A पर अपडेट हो जाता है, तो सिस्टम B का ग्राहक डेटा अब पुराना हो गया है और मेल नहीं खा रहा है। लेकिन, "आखिरकार", ए से रिकॉर्ड कुछ प्रक्रिया के माध्यम से बी को भेजा जाएगा। तो, अंततः, दो उदाहरण मेल खाएंगे।
जब आप एक सिस्टम के साथ काम करते हैं, तो आपके पास "ईसी" नहीं होता है, बल्कि आपके पास तत्काल अपडेट होते हैं, एक "सत्य का स्रोत" होता है, और, आमतौर पर, दौड़ की स्थिति और संघर्षों को संभालने के लिए एक लॉकिंग तंत्र होता है।
आपके संचालन "ईसी" डेटा के साथ काम करने में जितने सक्षम होंगे, इन प्रणालियों को अलग करना उतना ही आसान होगा। एक साधारण उदाहरण बिक्री द्वारा उपयोग किया जाने वाला डेटा वेयरहाउस है। वे अपनी दैनिक रिपोर्ट चलाने के लिए DW का उपयोग करते हैं, लेकिन वे सुबह तक अपनी रिपोर्ट नहीं चलाते हैं, और वे हमेशा "कल" (या पहले) डेटा देखते हैं। इसलिए डीडब्ल्यू को दैनिक संचालन प्रणाली के साथ पूरी तरह से सुसंगत होने की कोई वास्तविक समय की आवश्यकता नहीं है। यह एक प्रक्रिया के लिए पूरी तरह से स्वीकार्य है, उदाहरण के लिए, व्यवसाय के करीब और बड़े, एकल अपडेट ऑपरेशन में लेन-देन और गतिविधियों को बड़े पैमाने पर स्थानांतरित करने के लिए।
आप देख सकते हैं कि यह आवश्यकता कैसे कई मुद्दों को हल कर सकती है। लेन-देन संबंधी डेटा के लिए कोई विवाद नहीं है, कोई चिंता नहीं है कि कुछ रिपोर्ट डेटा आंकड़े जमा करने के बीच में बदलने जा रहे हैं क्योंकि रिपोर्ट ने लाइव डेटाबेस के लिए दो अलग-अलग प्रश्न बनाए हैं। दिन के दौरान नेटवर्क और सीपीयू प्रोसेसिंग इत्यादि को चूसने के लिए उच्च विवरण वाली बकवास की आवश्यकता नहीं है।
अब, यह EC का एक अतिवादी, सरलीकृत और बहुत ही स्थूल उदाहरण है।
लेकिन Google जैसे बड़े सिस्टम पर विचार करें। खोज के एक उपभोक्ता के रूप में, हमें पता नहीं होता है कि किसी खोज परिणाम में Google कब और कितना समय लेता है, जब तक कि Google किसी खोज पृष्ठ पर कैसे पहुंच जाता है। 1ms? 1एस? 10s? 10 घंटे? यह कल्पना करना आसान है कि यदि आप Google के वेस्ट कोस्ट सर्वरों को हिट कर रहे हैं, तो आप उनके ईस्ट कोस्ट सर्वर को हिट करने की तुलना में एक अलग खोज परिणाम प्राप्त कर सकते हैं। किसी भी बिंदु पर ये दो उदाहरण पूरी तरह से संगत नहीं हैं। लेकिन बड़े पैमाने पर, वे ज्यादातर सुसंगत हैं। और उनके उपयोग के मामले में, उनके उपभोक्ता वास्तव में अंतराल और देरी से प्रभावित नहीं होते हैं।
ईमेल पर विचार करें। A, B को संदेश भेजना चाहता है, लेकिन इस प्रक्रिया में संदेश सिस्टम C, D, और E के माध्यम से भेजा जाता है। प्रत्येक सिस्टम संदेश को स्वीकार करता है, इसके लिए पूरी जिम्मेदारी लेता है, और फिर इसे दूसरे को सौंप देता है। प्रेषक देखता है कि ईमेल अपने रास्ते पर चल रहा है। रिसीवर वास्तव में इसे याद नहीं करता है क्योंकि वे जरूरी नहीं जानते कि यह आ रहा है। इसलिए, समय की एक बड़ी खिड़की है कि उस संदेश को सिस्टम के माध्यम से स्थानांतरित करने के लिए किसी को भी यह जानने या परवाह किए बिना कि यह कितना तेज़ है।
दूसरी ओर, A, B के साथ फ़ोन पर बात कर सकता था। "मैंने अभी-अभी भेजा है, क्या आपने अभी तक प्राप्त किया? अब? अब? अभी प्राप्त करें?"
इस प्रकार, प्रदर्शन और प्रतिक्रिया के किसी प्रकार का अंतर्निहित, निहित स्तर है। अंत में, "आखिरकार", A का आउटबॉक्स B इनबॉक्स से मेल खाता है।
ये देरी, पुराने डेटा की स्वीकृति, चाहे वह एक दिन पुराना हो या 1-5 वर्ष पुराना, आपके सिस्टम के अंतिम युग्मन को नियंत्रित करता है। यह आवश्यकता जितनी कम होगी, युग्मन उतना ही ढीला होगा, और डिज़ाइन के मामले में आपके पास जितना अधिक लचीलापन होगा।
यह आपके सीपीयू में कोर के लिए सही है। एक ही सिस्टम पर चलने वाले आधुनिक, मल्टी कोर, मल्टी-थ्रेडेड एप्लिकेशन में "समान" डेटा के अलग-अलग दृश्य हो सकते हैं, केवल माइक्रोसेकंड पुराने हैं। यदि आपका कोड एक दूसरे के साथ संभावित रूप से असंगत डेटा के साथ सही ढंग से काम कर सकता है, तो शुभ दिन, यह साथ में ज़िप करता है। यदि नहीं, तो आपको यह सुनिश्चित करने के लिए विशेष ध्यान देने की आवश्यकता है कि आपका डेटा पूरी तरह से संगत है, अस्थिर मेमोरी क्वालिफाई, या लॉकिंग कंस्ट्रक्शन आदि जैसी तकनीकों का उपयोग करके, जिनमें से सभी, अपने तरीके से, लागत प्रदर्शन।
तो, यह आधार विचार है। बाकी सभी फैसले यहीं से शुरू होते हैं। इसका उत्तर देना आपको बता सकता है कि अनुप्रयोगों को मशीनों में कैसे विभाजित किया जाए, कौन से संसाधन साझा किए जाते हैं, और उन्हें कैसे साझा किया जाता है। डेटा को स्थानांतरित करने के लिए कौन से प्रोटोकॉल और तकनीक उपलब्ध हैं, और हस्तांतरण करने के लिए प्रसंस्करण के मामले में इसकी लागत कितनी होगी। प्रतिकृति, भार संतुलन, डेटा शेयर इत्यादि। सभी इस अवधारणा पर आधारित हैं।
संपादित करें, पहली टिप्पणी के जवाब में।
सही, बिल्कुल। यहाँ खेल, उदाहरण के लिए, यदि B ग्राहक डेटा नहीं बदल सकता है, तो बदले हुए ग्राहक डेटा से क्या नुकसान है? क्या आप इसे थोड़े समय के लिए पुराना होने का "जोखिम" दे सकते हैं? शायद आपका ग्राहक डेटा धीरे-धीरे इतना आता है कि आप इसे तुरंत ए से बी में दोहरा सकते हैं। मान लें कि परिवर्तन को कतार में रखा गया है, कम मात्रा के कारण, आसानी से उठाया जाता है (<1s), लेकिन फिर भी यह मूल परिवर्तन के साथ "लेन-देन से बाहर" होगा, और इसलिए एक छोटी सी खिड़की है जहां ए होगा डेटा जो B नहीं करता है।
अब मन सचमुच घूमने लगता है। "अंतराल" के उस 1s के दौरान क्या होता है, सबसे खराब संभावित परिदृश्य क्या है। और क्या आप इसके आसपास इंजीनियर हो सकते हैं? यदि आप 1s अंतराल के आसपास इंजीनियर कर सकते हैं, तो आप 5s, 1m या उससे भी अधिक अंतराल के आसपास इंजीनियर करने में सक्षम हो सकते हैं। आप वास्तव में B पर कितने ग्राहक डेटा का उपयोग करते हैं? हो सकता है कि बी एक प्रणाली है जिसे इन्वेंट्री से ऑर्डर लेने की सुविधा के लिए डिज़ाइन किया गया है। केवल एक ग्राहक आईडी और शायद एक नाम से अधिक आवश्यक होने की कल्पना करना कठिन है। बस कुछ स्थूल रूप से यह पहचानने के लिए कि ऑर्डर किसके लिए है, जबकि इसे असेंबल किया जा रहा है।
पिकिंग सिस्टम को आवश्यक रूप से सभी ग्राहक जानकारी को पिकिंग प्रक्रिया के अंत तक प्रिंट करने की आवश्यकता नहीं है, और तब तक ऑर्डर किसी अन्य सिस्टम पर चला गया हो सकता है जो शायद अधिक वर्तमान है, विशेष रूप से, शिपिंग जानकारी, इसलिए अंत में पिकिंग सिस्टम को शायद ही किसी ग्राहक डेटा की आवश्यकता नहीं होती है। वास्तव में, आप पिकिंग ऑर्डर के भीतर ग्राहक जानकारी को एम्बेड और असामान्य कर सकते हैं, इसलिए बाद में सिंक्रनाइज़ करने की कोई आवश्यकता या अपेक्षा नहीं है। जब तक ग्राहक आईडी सही है (जो वैसे भी कभी नहीं बदलेगा) और नाम (जो शायद ही कभी बदलता है, यह चर्चा के लायक नहीं है), यही एकमात्र वास्तविक संदर्भ है जिसकी आपको आवश्यकता है, और आपकी सभी पिक स्लिप पूरी तरह से सटीक हैं सृजन।
चाल प्रणाली को तोड़ने और कार्य के लिए आवश्यक आवश्यक डेटा पर ध्यान केंद्रित करने की मानसिकता है। आपको जिस डेटा की आवश्यकता नहीं है उसे दोहराने या सिंक्रनाइज़ करने की आवश्यकता नहीं है। लोग असामान्यकरण और डेटा में कमी जैसी चीजों पर झगड़ते हैं, खासकर जब वे रिलेशनल डेटा मॉडलिंग की दुनिया से होते हैं। और अच्छे कारण के साथ, इस पर सावधानी से विचार किया जाना चाहिए। लेकिन एक बार जब आप वितरित हो जाते हैं, तो आप परोक्ष रूप से निरूपित हो जाते हैं। ठीक है, आप इसे अभी थोक में कॉपी कर रहे हैं। तो, आप इसके बारे में अधिक समझदार भी हो सकते हैं।
यह सब ठोस प्रक्रियाओं और कार्यप्रवाह की गहन समझ के माध्यम से कम किया जा सकता है। जोखिमों की पहचान करें और उनसे निपटने के लिए नीति और प्रक्रियाएं तैयार करें।
लेकिन कठिन हिस्सा शुरुआत में केंद्रीय डीबी को श्रृंखला तोड़ रहा है, और लोगों को निर्देश दे रहा है कि वे "यह सब नहीं कर सकते" जैसे वे उम्मीद कर सकते हैं जब आपके पास जानकारी का एक एकल, केंद्रीय, सही स्टोर हो।
