क्या सेवाओं के लिए SOA में डेटाबेस साझा करना बुरा है?

Question

मैं हाल ही में हॉफ और वुल्फ के एंटरप्राइज इंटीग्रेशन पैटर्न पढ़ रहा हूं, एसओए पर थॉमस एर्ल की कुछ किताबें और उदी दहन एट अल द्वारा विभिन्न वीडियो और पॉडकास्ट देख रहा हूं। CQRS और इवेंट ड्रिवेन सिस्टम पर।

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

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

मैंने सोचा था कि यह SOA में सीमाओं को लागू करने के तरीकों में से एक था - प्रत्येक सेवा का अपना डेटाबेस होना चाहिए, लेकिन फिर मैंने इसे पढ़ा:

/programming/4019902/soa-joining-data-across-multiple-services

और यह पता चलता है कि यह गलत काम है।

डेटाबेस को अलग करना डिकॉउलिंग सिस्टम का एक अच्छा तरीका लगता है, लेकिन अब मैं थोड़ा भ्रमित हूं। क्या यह एक अच्छा मार्ग है? क्या कभी यह अनुशंसा की जाती है कि आपको एक डेटाबेस को अलग करना चाहिए, एक SOA सेवा, एक DDD बाउंडेड संदर्भ, एक आवेदन, आदि।

Comments

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

— जेरेमी

मैं समझता हूं कि प्रश्न गलत है, यह उत्तर थे जिन्होंने मेरी सोच का पुनर्मूल्यांकन किया।

— पॉल टी डेविस

मुझे लगता है कि सेवाओं को

— बी

Answer 1

Decoupling केवल तभी काम करती है जब वास्तव में अलगाव हो। विचार करें कि क्या आपके पास ऑर्डर करने की व्यवस्था है:

• तालिका: ग्राहक
• तालिका: आदेश

अगर यह सब आपको मिल गया है, तो उन्हें डिकोड करने का कोई कारण नहीं है। दूसरी ओर, यदि आपके पास यह है:

• तालिका: ग्राहक
• तालिका: आदेश
• तालिका: CUSTOMER_NEWSLETTER

तब आप तर्क दे सकते हैं कि ORDER और CUSTOMER_NEWSLETTER दो पूरी तरह से अलग मॉड्यूल (ऑर्डर और मार्केटिंग) का हिस्सा हैं। शायद यह अलग डेटाबेस (प्रत्येक तालिका के लिए एक) में ले जाने के लिए समझ में आता है, और दोनों मॉड्यूल अपने स्वयं के डेटाबेस में आम ग्राहक तालिका तक पहुंच साझा करते हैं।

ऐसा करके आप प्रत्येक मॉड्यूल को सरल बना रहे हैं, लेकिन आप अपने डेटा स्तर की जटिलता को बढ़ा रहे हैं। जैसे-जैसे आपका एप्लिकेशन बड़ा और बड़ा होता जाता है, मैं अलग होने का फायदा देख सकता हूं। अधिक से अधिक "डेटा द्वीप" होंगे जो वास्तव में एक दूसरे से कोई संबंध नहीं रखते हैं। हालांकि, हमेशा कुछ डेटा होंगे जो सभी मॉड्यूल को क्रॉस-कट करते हैं।

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

Comments

-1। वे केवल अलग डेटाबेस में होना चाहिए अगर वहाँ उन्हें डालने के लिए एक कारण है। आपको "इसमें से कुछ पाने की ज़रूरत है" क्योंकि यह निश्चित रूप से आपके ऐप को अधिक जटिल बनाता है।

— स्कॉचचुल्थेस

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

— क्रिस स्नो

@scottschulthess हाँ, आपको जटिलता लागत का वजन करने की आवश्यकता है और यदि यह इसके लायक नहीं है तो आप बस सेवाओं में विभाजित नहीं हो सकते। विभाजन लेकिन मैंने जो साझा डेटाबेस का उपयोग किया है वह 3 विकल्पों में से सबसे खराब है।

— एडमांतीश

Answer 2

जहां मैं काम करता हूं वहां हमारे पास एक ईएसबी हैजिसमें से 6 अलग-अलग एप्लिकेशन (या मुझे "एंडपॉइंट" कहना चाहिए) जुड़े हुए हैं। वे 6 एप्लिकेशन 2 डेटाबेस इंस्टेंस पर 3 अलग-अलग ओरेकल स्कीमा के साथ काम करते हैं। इनमें से कुछ एप्लिकेशन एक ही स्कीमा में सह-अस्तित्व में हैं क्योंकि वे संबंधित नहीं हैं, लेकिन क्योंकि हमारा डेटाबेस इन्फ्रास्ट्रक्चर एक बाहरी प्रदाता द्वारा प्रबंधित किया जाता है और एक नया स्कीमा प्राप्त करने में हमेशा के लिए लगता है (साथ ही, हमारे पास निश्चित रूप से डीबीए की पहुंच नहीं है) ... यह वास्तव में इतना लंबा समय लगता है कि एक बिंदु पर हमने विकास को जारी रखने के लिए एक मौजूदा स्कीमा "अस्थायी रूप से" का पुन: उपयोग करने के बारे में सोचा। डेटा के "पृथक्करण" को लागू करने के लिए, तालिका के नाम उपसर्ग हैं, उदाहरण के लिए "CST_" ग्राहक के लिए। इसके अलावा, हमें एक स्कीमा के साथ काम करना होगा कि कुछ वैध कारणों से हम पूर्ण परिवर्तन नहीं कर सकते हैं ... यह अजीब है मुझे पता है। बेशक, जैसा कि हमेशा होता है, "अस्थायी रूप से"

हमारे अलग-अलग एप्लिकेशन उनके संबंधित डेटाबेस स्कीमा से जुड़ते हैं और अपने पीएल / एसक्यूएल पैकेज के साथ काम करते हैं और हम खुद को टेबल / डेटा के साथ सीधे इंटरैक्ट करने के लिए मना करते हैं जो हमारे एप्लीकेशन डोमेन के बाहर है।

जब ESB से जुड़े एप्लिकेशन में से एक को अपने डोमेन से बाहर की जानकारी की आवश्यकता होती है, तो वह डेटा प्राप्त करने के लिए ESB पर संबंधित सेवा को कॉल करता है, भले ही वह जानकारी वास्तव में उसी स्कीमा में हो, सिद्धांत में केवल एक छोटे से बयान में शामिल होने की आवश्यकता होती है। SQL अनुरोधों में से एक ।

हम ऐसा करते हैं कि हमारे एप्लिकेशन डोमेन को अलग-अलग स्कीमा / डेटाबेस में विभाजित करने में सक्षम होने के लिए, और ESB पर सेवाओं के लिए अभी भी ठीक से काम करने के लिए जब ऐसा होता है (यह जल्द ही क्रिसमस है, हम उंगलियों को सहला रहे हैं)

अब, यह बाहर से अजीब और भयानक लग सकता है लेकिन इसके कारण हैं और मैं आपको यह दिखाने के लिए इस ठोस अनुभव को साझा करना चाहता था कि एक या अधिक डेटाबेस उतना महत्वपूर्ण नहीं है। रुको, यह है!, कई कारणों से (स्कॉट व्हिटलॉक के लिए +1, बैकअप के बारे में अंतिम पैराग्राफ देखें और इस तरह कि माया आपको परेशानी में डालती है) लेकिन यह भी उतना ही महत्वपूर्ण है कि मुझे लगता है कि आपकी एसओए सेवाओं को ठीक से डिज़ाइन किया गया हो, कम से कम यह मेरी राय है, और मैं डीबीए नहीं है। अंततः, आपके सभी डेटाबेस आपके "एंटरप्राइज़ डेटावेयरहाउस" के हैं, है ना?

अंत में, मैं स्कॉट व्हिटलॉक के अंतिम पैराग्राफ को विशेष रूप से इसे फिर से लिखना नहीं करूंगा

मैं चिंता को अलग करने के कारण अलग-अलग भौतिक डेटाबेस में तालिकाओं को अलग नहीं करूंगा।

वास्तव में सुपर महत्वपूर्ण है। अगर कोई कारण नहीं है, तो यह मत करो।

Answer 3

मैंने डेटा आर्किटेक्चर के कारण सॉफ़्टवेयर आर्किटेक्चर में सबसे खराब संभव बुरे सपने देखे हैं, और इस प्रकार की गड़बड़ी के खिलाफ सबसे अच्छा हथियार जो मैंने अभी तक आईडी डीडीडी-स्टाइल बाउंडेड कॉन्टेक्ट्स का सामना किया है। जो एक निश्चित अर्थ पर "SOA किया गया अधिकार" से बहुत दूर नहीं है।

हालाँकि, डेटा ही समस्या पर हमला करने का सबसे अच्छा तरीका नहीं है। किसी को अपेक्षित / आवश्यक व्यवहार पर ध्यान केंद्रित करना चाहिए और डेटा को लाना चाहिए जहां यह मायने रखता है। हम इस तरह से कुछ दोहराव को समाप्त कर सकते हैं, लेकिन यह आमतौर पर ब्लॉक के साथ सिस्टम डेवलपमेंट की तुलना में डेटा-एकीकृत आर्किटेक्चर के साथ लगभग हमेशा जुड़ा हुआ नहीं है।

इसे सरल करने के लिए: यदि आप शिथिल युग्मित प्रणाली की तलाश कर रहे हैं, तो डेटा पर युग्मित न रहें। वेल एन्कैप्सुलेटेड सिस्टम और बीच में एक अच्छी तरह से संरचित संचार चैनल के लिए जाएं, "लिंगुआ फ्रेंका" के रूप में कार्य करना ।

Comments

और ... सीधे शीर्षक प्रश्न का उत्तर देते हुए: "हाँ, मैं इसे SOA में डेटाबेस साझा करने के लिए एक जोखिम भरा अभ्यास मानूंगा", अगर यह करने के लिए सबसे उचित चीज की तरह दिखता है, तो शायद कुछ गंभीर डिजाइन दोष है।

— जिओब्रांडो

Answer 4

डेटाबेस को डिकूप करना और उनके बीच डेटा को लगातार बनाए रखना एक विशेषज्ञ स्तर का कार्य है। गलत होने और डुप्लिकेट आदि की समस्याओं के साथ समाप्त करने के लिए बहुत आसान है, कि मौजूदा प्रणाली से बचने के लिए डिज़ाइन किया गया है। सच कहूँ तो, एक कार्य प्रणाली लेना और ऐसा करना उपयोगकर्ताओं के लिए वास्तविक मूल्य के लिए नए बग को पेश करने की बहुत अधिक गारंटी है।

Answer 5

यदि सही ढंग से किया जाता है, तो व्यावसायिक चिंताओं को अलग-अलग डेटाबेस (या कम से कम अलग-अलग स्कीमा) में अलग करना एक गुण है ।

कृपया CQRS पैटर्न के मार्टिन फॉलर का विवरण देखें :

जैसे-जैसे हमारी ज़रूरतें और अधिक परिष्कृत होती जाती हैं, हम लगातार [एक CRUD डेटास्टर की तरह एक सूचना प्रणाली का इलाज कर रहे हैं] से दूर चले जाते हैं ... CQRS ने जो परिवर्तन पेश किया है वह है कि वैचारिक मॉडल को अद्यतन और प्रदर्शन के लिए अलग-अलग मॉडल में विभाजित करना ... काफी भिन्नता के लिए जगह है। यहाँ। इन-मेमोरी मॉडल एक ही डेटाबेस साझा कर सकते हैं, जिस स्थिति में डेटाबेस दो मॉडलों के बीच संचार के रूप में कार्य करता है। हालाँकि, वे अलग-अलग डेटाबेस का उपयोग कर सकते हैं , प्रभावी ढंग से क्वेरी-साइड के डेटाबेस को एक वास्तविक समय रिपोर्टिंगडैटेबेस द्वारा बना सकते हैं। इस मामले में दो मॉडल या उनके डेटाबेस के बीच कुछ संचार तंत्र होना चाहिए।

और NServiceBus वास्तुकला सिद्धांत :

कमांड क्वेरी पृथक्करण

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

और कमांड और क्वेरी जिम्मेदारी अलगाव (CQRS)

कमान और क्वेरी जिम्मेदारी अलगाव

अधिकांश एप्लिकेशन डेटा लिखने से अधिक बार डेटा पढ़ते हैं। उस कथन के आधार पर, एक समाधान बनाना एक अच्छा विचार होगा जहां आसानी से आप अधिक डेटाबेस को पढ़ने के लिए जोड़ सकते हैं, है ना? तो क्या हुआ अगर हम सिर्फ पढ़ने के लिए समर्पित एक डेटाबेस सेट करते हैं? और भी बेहतर; क्या होगा अगर हम डेटाबेस को एक तरह से डिज़ाइन करते हैं तो इससे पढ़ने में तेज़ है? यदि आप CQRS वास्तुकला में वर्णित पैटर्न के आधार पर अपने अनुप्रयोगों को डिज़ाइन करते हैं, तो आपके पास एक समाधान होगा जो डेटा पढ़ने में स्केलेबल और तेज़ है।