2009-05-29 10 views
5

काम पर से दूर है, हम एक केंद्रीकृत एसक्यूएल सर्वर में डेटाबेस के साथ कई एप्लिकेशन नहीं है। जब भी किसी एप्लिकेशन को किसी अन्य एप्लिकेशन से डेटा के साथ काम करने की आवश्यकता होती है, तो यह केवल क्वेरीज़ करता है या डेटाबेस के माध्यम से इसे अपडेट करता है। मेरा मानना ​​है कि यह एंटरप्राइज़ इंटीग्रेशन पैटर्न बुक (होप & वूल्फ) में वर्णित "साझा डेटाबेस" पैटर्न है।पुनर्रचना साझा डाटाबेस पैटर्न

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

  • हम संदेश पैटर्न की ओर रीफैक्टरिंग शुरू करते हैं?
  • हम अनुप्रयोगों का अपना आवेदन डेटाबेस का प्रबंधन करने में से एक पुनर्रचना से शुरू करते हैं?
  • तो क्या अन्य अनुप्रयोगों के बारे में वर्तमान में डेटाबेस के माध्यम से है कि एक के साथ एकीकृत कर रहे हैं?
  • इस सबसे अच्छा तरीका हमारे डेटाबेस निर्भरता दसगुणा है या हम कहीं और शुरू कर दिया जाना चाहिए?

उत्तर

7

मैं एक 3 चरण संक्रमण सुझाव देना चाहेंगे।

  1. अपने प्रत्येक एप्लिकेशन में एक मैसेजिंग परत जोड़ें।
  2. नव निर्मित संदेश परत का उपयोग करने के लिए सभी क्रॉस-एप्लिकेशन डेटा पहुंच बदलें।
  3. आवश्यकतानुसार (अब-स्वतंत्र) डेटाबेस स्केल करें।

इसके अलावा, कहें कि आपके पास 3 एप्लिकेशन हैं; ए, बी, और सी

तुम भी 3 अलग संक्रमण के रूप में इस देख सकते हैं:

  • आवेदन एक

    • एक
    • बी में एक के लिए कॉल बदलें & सी
  • लिए संदेश जोड़ें

    आवेदन बी

    • संदेश बी को
    • बदलें जोड़े एक & सी
  • आवेदन सी ​​में बी को कॉल

    • सी
    • एक & बी में सी के लिए कॉल बदलें करने के लिए संदेश जोड़ें

इस बिंदु पर प्रक्रिया चरण 2 के अंत में समान होती है, और चरण 3 आगे बढ़ सकता है। अंतर यह है कि क्या यह एक प्रकार के रिफैक्टरिंग पर ध्यान केंद्रित करने या किसी एप्लिकेशन पर ध्यान केंद्रित करने के लिए अधिक उत्पादक है।

1

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

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

1

मैं यह भी विचार करता हूं कि अनुप्रयोग डेटाबेस का उपयोग कैसे करते हैं। आम तौर पर एक डेटाबेस (दोनों डिजाइन & कार्यान्वयन) दो अलग-अलग श्रेणियों में से एक में होना चाहिए: लेनदेन (OLTP) या रिपोर्टिंग (ओलाप)।

एक अच्छी तरह से डिज़ाइन (और कार्यान्वित) लेनदेन डेटाबेस को एक सामान्य लाइन-ऑफ-बिजनेस एप्लिकेशन परिदृश्य में उत्कृष्ट प्रदर्शन प्रदान करना चाहिए; इसी तरह, डेटा की जटिलता की बड़ी मात्रा में पूछताछ करते समय एक अच्छी तरह से डिज़ाइन किया गया (और कार्यान्वित) रिपोर्टिंग डेटाबेस उत्कृष्ट प्रदर्शन प्रदान करना चाहिए।

एक और महत्वपूर्ण भेद 'वास्तविक समय' और 'वास्तविक समय के नजदीक' के बीच का अंतर है।

मान लें कि आपके विभिन्न आवेदनों को लेनदेन (वास्तविक समय) संचालन और वर्तमान/पुराने डेटा पर कुछ रिपोर्टिंग करने की आवश्यकता है; आपको दो डेटा स्टोर्स की आवश्यकता होगी: एक लेनदेन वाला जो कि केवल 'वास्तविक समय' संचालन के समर्थन के लिए परिचालन गति के लिए बनाया गया है, और दूसरा जिसमें 'ऐतिहासिक' डेटा शामिल है जो पूरी तरह से रिपोर्टिंग के लिए बनाया जाएगा।

यह चाल यह पता लगाने के लिए है कि लेनदेन संबंधी डेटा स्टोर में आपको कितना डेटा रखना है, और इसे रिपोर्टिंग डेटा स्टोर में कब/कैसे ले जाना है।

संबंधित मुद्दे