ईटीएल (डाटाबेस डेटाबेस) एसओए में कैसे फिट करता है?

Question

आइए कल्पना करें कि हमारे आवेदन को संबंध डेटाबेस से दूसरे संबंध डेटाबेस में ईटीएल (निकालें, ट्रांसफॉर्म, लोड) डेटा की आवश्यकता है। सबसे सरल (और सबसे अधिक प्रदर्शन, आईएमएचओ) तरीका डाटाबेस के बीच लिंक बनाना और सरल संग्रहीत प्रक्रिया लिखना है। इस मामले में हम न्यूनतम तकनीकों और घटकों का उपयोग करते हैं, सभी सुविधाएं "बॉक्स से बाहर" हैं।

लेकिन क्या यह एसओए (सेवा उन्मुख वास्तुकला) के लिए अच्छा अभ्यास है? तंग युग्मन के बारे में क्या? क्या हम दृढ़ता से डेटाबेस को एक-दूसरे के साथ जोड़ते हैं?

ऐसा करने का एक और तरीका है: हम प्रत्येक पक्ष में 2 जावा एप्लिकेशन बनाते हैं और एसओएपी वेब सेवाओं द्वारा संवाद करते हैं। यह अधिक एसओए दोस्ताना है! लेकिन प्रदर्शन गिरावट और इसके लायक विफलता के अतिरिक्त अंक हैं?

इस मामले में सबसे अच्छा अभ्यास क्या होगा? ईटीएल एसओए के भीतर कैसे फिट हो सकता है?

Answer 1

ये सभी उत्तर अच्छे और सहायक हैं।

जैसा कि अब मैं समझता हूं कि एसओए आवेदन को लागू करने के बारे में नहीं है, लेकिन आर्किटेक्चर ("ए"), मुख्य रूप से एंटरप्राइज़ आर्किटेक्चर के बारे में है। एंटरप्राइज़ मुख्य प्रबंधन विधि सेवाओं ("एस") के लिए ज़िम्मेदारी का प्रतिनिधिमंडल है।

इसलिए यदि दो अलग-अलग जिम्मेदार खातों के साथ उद्यम संरचना में दो अलग-अलग व्यावसायिक कार्य हैं, तो हमें इसे दो अलग-अलग सेवाओं में अच्छी तरह परिभाषित अनुबंध (इंटरफेस), राजनीति और लेखा परीक्षा विधियों के साथ विभाजित करना चाहिए - यह मुख्य एसओए उद्देश्य है।

लेकिन यदि यह एक जिम्मेदार व्यक्ति के साथ परमाणु कार्य है, तो एसओए में बहुत आवश्यकता नहीं है और हमें सरल तकनीकों का उपयोग करना चाहिए और सरल और तेज़ ठोस सेवा आवेदन लागू करना चाहिए।

मेरे मूल प्रश्न के बारे में यह कार्य संदर्भ जानकारी की कमी है। अब मैं समझता हूं कि डेटाबेस लिंक सेवाओं में लागू नहीं किया जाना चाहिए, और यह खराब डिज़ाइन है क्योंकि एंटरप्राइज़ प्रबंधन संगतता नहीं है। लेकिन एक सेवा के भीतर यह अच्छा सरल समाधान हो सकता है।

सभी को उत्तर देने के लिए धन्यवाद।

Answer 2

एसओए में, आप Biztalk या SAP BusinessObjects Data Integrator प्रोसेसिंग के तरीके को अनुकूलित कर सकते हैं। असल में, यह एक शेड्यूलर नौकरी/विंडोज सेवा, या कुछ समान है। आप डेटा सेवा पुनर्प्राप्त करने के लिए शेड्यूलर के लिए दो सेवा बिंदु, 1 प्रदान करते हैं, और दूसरा शेड्यूलर डेटा भेजने के लिए प्रदान करता है। शेड्यूलर की ज़िम्मेदारी यहां समय-समय पर चलने और डेटा बदलने के लिए है।

तो, बुनियादी कदम होगा:

चरण 1: अनुसूचक चलाने के लिए और सेवा से डेटा प्राप्त एक

Scheduler --get--> Service A 
Service A --data--> Scheduler 

चरण 2: अनुसूचक कर डेटा परिवर्तन

[ Conversion --> Conversion --> Conversion --> Conversion ] 

चरण 3: शेड्यूलर डेटा को दूसरी सेवा

Scheduler --data--> Service B 

पर डेटा भेजता है

बिज़टॉक और एसएपी बिजनेस ऑब्जेक्ट डेटा इंटीग्रेटर दोनों में, चरण कॉन्फ़िगर करने योग्य हैं (वे जो भी सेवा से पुनर्प्राप्त कर सकते हैं और डेटा ट्रांसक्रिप्शन कर सकते हैं), इसलिए यह अधिक लचीला है।

हालांकि, अभी भी सामान्य समस्याएं हैं जो ईटीएल प्रसंस्करण के साथ हो सकती हैं। उदाहरण के लिए: डेटा बहुत बड़ा है, नेटवर्क प्रदर्शन प्रभाव, आरटीओ, डुप्लिकेट डेटा इत्यादि। इसलिए ईटीएल सर्वोत्तम प्रथाओं को अभी भी एक आवश्यकता है (स्टेजिंग टेबल, लॉगिंग आदि का उपयोग)।

लेकिन क्या प्रदर्शन में गिरावट और विफलता के अतिरिक्त अंक इसके लायक हैं?

प्रदर्शन प्रभाव तब होगा जब से आपके पास अतिरिक्त कनेक्शन/प्रमाणीकरण चरण (webservice के लिए), और परिवहन चरण (प्रोटोकॉल के माध्यम से शेड्यूलर के लिए webservice) है। लेकिन त्रुटि-प्रवण के लिए, मुझे लगता है कि यह वही त्रुटि है जिसे आपको अन्य सेवा कॉल के साथ संभालने की आवश्यकता है।

क्या यह इसके लायक है? निर्भर करता है। यदि आप एक ही वातावरण (समान डेटाबेस) में काम कर रहे हैं तो यह बहस योग्य है। यदि आप अलग-अलग वातावरण में काम कर रहे हैं (उदाहरण के लिए दो अलग-अलग सिस्टम, Asp.Net से SAP तक, या कम से कम डेटाबेस उदाहरण), तो यह आर्किटेक्चर ईटीएल को संभालने का सबसे अच्छा शर्त है।

Answer 3

ईटीएल सामान्य रूप से एसओए में फिट बैठता है - उदा। एसओए सेवाएं एक दूसरे के बीच ईटीएल संचालन कर सकती हैं।

डाटाबेस-टू-डेटाबेस लिंकेज बहुत उपयोगी है जब आप डेटाबेस को दोहराना चाहते हैं या अन्य समान परिस्थितियों में। आम तौर पर, इस दृष्टिकोण के पास एसओए से कोई लेना देना नहीं है, जब तक कि नीचे के मामले मौजूद न हों।

डाटाबेस-टू-डेटाबेस लिंक एसओए में फिट नहीं होता है जब दोनों डेटाबेस एसओए सेवाओं द्वारा उपभोग किए जाते हैं। इस मामले में, आपको सेवाओं के माध्यम से संवाद करना चाहिए।

डेटाबेस-टू-डेटाबेस लिंकेज अभी भी एसओए में फिट बैठता है जब एसओए सेवा के लिए केवल एक डेटाबेस दृढ़ता है। दूसरे को एक विफलता या सरल प्रतिकृति के रूप में माना जा सकता है, जो सीधे एसओए से संबंधित नहीं है। इस मामले में, डेटाबेस-टू-डेटाबेस लिंकेज केवल डेटा से संबंधित चिंता बन जाता है, जिसे आपको रखने और हल करने की अनुमति है। करने के लिए - -

Answer 4

मेरे लिए वहाँ कई अंक DB में लापता हैं और db बाकी सेटअप आधारित: ETL प्रक्रिया में अपवाद:

जब डेटा के परिवर्तन वैध माना जाता है?
एक असफल परिवर्तन का परिणाम कैसे संभाला जाता है?
बस डेटा को फेंकना ज्यादातर मामलों में एक विकल्प नहीं है।
सिस्टम विफलता/पुनर्प्राप्ति
क्या होगा यदि एक/दोनों सिस्टम थोड़ी देर के लिए नीचे आ जाए? सिंक्रनाइज़ेशन कैसे संभाला जाता है? ईटीएल कब विफल हुआ और इसे फिर से शुरू किया जाना है?
तो डाटाबेस या आराम करने के बजाय - सेवाएं एक-दूसरे के साथ संवाद करती हैं - यह अपाचे कैमल जैसे माइग्रेशन टेक्नोलॉजीज का उपयोग करने या ईएसबी का उपयोग करने से अधिक संबंधित है जो ट्रांसफॉर्मेशन को संभाल सकता है, डेटा विभाजित कर सकता है, इसे असुरक्षित तरीके से संसाधित कर सकता है, इसे वापस रख सकता है एक साथ, निष्पादन अनुकूलन के लिए उचित निगरानी, ​​पुनर्प्राप्ति, लोड संतुलन है। यह अनिवार्य रूप से ईटीएल में 'ई' को गति नहीं देगा, न ही 'एल' (हालांकि यह दोनों में हो सकता है), लेकिन निश्चित रूप से 'टी' को गति देता है और डेटा अखंडता के लिए सकारात्मक परिणाम होता है।
और निश्चित रूप से: ईएसबी एसओए से संबंधित प्रौद्योगिकियां हैं। मेरे लिए अपाचे कैमल वास्तव में नहीं है हालांकि इसे एंटरप्राइज़ एकीकरण पैटर्न का संदर्भ कार्यान्वयन माना जाता है।

मूल रूप से इसके पीछे विचार यह है कि एटीएल सामग्री आधारित है और संरचना-आधारित समस्याओं नहीं है।
तो तुम इन तकनीकों के साथ क्या कर सकते हैं कुछ की तरह है: - DataExtractor - सत्यापनकर्ता
-
डीबी < ContentLengthBasedRouter - स्प्लिटर
(Ansynch) - Transformer1,
- ट्रांसफार्मर 2 ..
- एग्रीगेटर -
- ContentBasedRouter - Transformer3 -
- DataInserter
- मॉनिटर
और अधिक लेकिन था टी एक पाठ विवरण में अनुकूल नहीं है।