2010-07-26 11 views
25

हम एक ऐसे एप्लिकेशन का निर्माण कर रहे हैं जिसमें डेटाबेस है (हाँ, बहुत रोमांचक हुह :)। डेटाबेस मुख्य रूप से लेनदेन (ऐप का समर्थन करने के लिए) है और ऐप के हिस्से के रूप में कुछ "रिपोर्टिंग" भी करता है - लेकिन कुछ भी ज़ोरदार नहीं है।एक अलग रिपोर्टिंग डेटाबेस बनाने के लिए कब?

ऊपर और उससे परे हमारे पास कुछ रिपोर्टिंग आवश्यकताएं हैं - लेकिन वे इस समय बहुत अस्पष्ट और उच्च स्तर के हैं। हमारे पास एक मानक रिपोर्टिंग टूल है जिसका उपयोग हम घर में करते हैं जिसका उपयोग हम "भारी" रिपोर्टिंग करने के लिए करेंगे, क्योंकि आवश्यकताएं ठोस होंगी।

मेरा प्रश्न है: रिपोर्टिंग के लिए एक अलग डेटाबेस की आवश्यकता होने पर आप कैसे जानते हैं?

किस प्रकार के प्रश्न पूछने की आवश्यकता है? आप किस तरह की चीजें तय करेंगे कि एक अलग रिपोर्टिंग डेटाबेस आवश्यक था?

उत्तर

29

सामान्य रूप से, अधिक मिशन लेनदेन संबंधी ऐप और अधिक परिष्कृत रिपोर्टिंग आवश्यकताओं को अधिक महत्वपूर्ण बनाता है, और अधिक विभाजन समझ में आता है।

  1. जब लेनदेन प्रदर्शन महत्वपूर्ण है।
  2. जब लेनदेन संबंधी ऐप पर रखरखाव विंडो प्राप्त करना मुश्किल होता है।
  3. यदि रिपोर्टिंग न केवल इस ऐप से परिणाम को सहसंबंधित करने की आवश्यकता है, बल्कि अन्य एप्लिकेशन सिलो से भी।
  4. यदि रिपोर्टों को ट्रेंडिंग या अन्य प्रकार की रिपोर्टिंग का समर्थन करने की आवश्यकता है जो स्टार स्कीमा/बिजनेस इंटेलिजेंस पर्यावरण के लिए सबसे उपयुक्त हैं।
  5. यदि रिपोर्ट लंबी चल रही है।
  6. व्यवहार एप्लिकेशन एक महंगी हार्डवेयर संसाधन (क्लस्टर, मेनफ्रेम, आदि) पर है, तो
  7. आप विहित राज्य के लिए उदाहरण के लिए, राज्य के नाम लेनदेन डेटा पर डेटा सफाई/निकालने-बदलने लोड परिचालन (करने के लिए की जरूरत है संक्षिप्त रूपों)।

यह गैर-मामूली जटिलता को जोड़ता है, इसलिए आईएमओ, विभाजित करने का एक अच्छा कारण होना चाहिए।

+0

धन्यवाद - मुझे विचार करने के लिए अंक की अपनी संक्षिप्त सूची पसंद है। –

1

रिपोर्टिंग समस्याओं के लिए आपको एक अलग डेटाबेस की आवश्यकता होगी मुख्य कारण यह है कि रिपोर्ट की पीढ़ी ऐप की लेनदेन संबंधी जिम्मेदारियों में हस्तक्षेप करती है। जैसे यदि रिपोर्ट में 100% CPU/डिस्क/आदि का उत्पादन और उपयोग करने के लिए 20 मिनट लगते हैं ... उच्च गतिविधि के समय आप रिपोर्टिंग के लिए एक अलग डेटाबेस का उपयोग करने के बारे में सोच सकते हैं।

प्रश्नों के लिए के रूप में, यहाँ कुछ बुनियादी एक हैं:

  1. मैं गैर पीक आवर्स के दौरान उच्च तीव्रता रिपोर्ट कर सकता हूँ?
  2. क्या यह सिस्टम का उपयोग कर उपयोगकर्ताओं के साथ हस्तक्षेप करता है?
  3. यदि हां # 2, हस्तक्षेप की लागत क्या है, तो किसी अन्य डेटाबेस सर्वर की लागत, कोड को दोबारा प्रतिक्रिया देना आदि ...?
+0

डेटाबेस इस समस्या को अस्वीकार करने के लिए डिज़ाइन किए गए हैं। एक उचित सेटअप डेटाबेस और रिपोर्टिंग सिस्टम में कोई समस्या नहीं होनी चाहिए। – northpole

+3

सभी डेटाबेस सही नहीं हैं, और कभी-कभी किसी समस्या पर अधिक हार्डवेयर फेंकने का दृष्टिकोण लेना डेवलपर्स, डीबीए, प्रोजेक्ट मैनेजर्स आदि को किराए पर लेने से कहीं अधिक सस्ता है ...अधिक अनुकूलित डेटाबेस डिज़ाइन के लिए एप्लिकेशन को रिकोड करने के लिए। आपकी टिप्पणी यह ​​कहने के समान है कि जेट इंजन प्रोप विमानों के सभी मुद्दों को अस्वीकार करते हैं। हालांकि यह सच है, एक प्रोप प्लेन अभी भी निर्माण, उड़ान भरने और बनाए रखने के लिए बहुत सस्ता है (पायलट के उच्च स्तर के रूप में भी आवश्यकता नहीं है)। –

1

असल में, जब ऐप से डेटाबेस लोड रिपोर्टिंग के लिए डेटाबेस लोड के साथ असंगत हो जाता है। यह इस कारण हो सकता है:

  • ऐप के डीबी प्रदर्शन को प्रभावित करने वाले डेटाबेस सर्वर संसाधनों की असामान्य मात्रा में उपभोग करने की रिपोर्ट करना।

    इस श्रेणी का एक हिस्सा ऐप डीबी काम लॉकिंग के कारण एक बड़ी धीमी रिपोर्ट क्वेरी पर इंतजार कर रहा है, हालांकि ट्यूनिंग लॉकिंग जैसी कम कठोर विधियों के साथ हल करना संभव हो सकता है।

  • रिपोर्टिंग क्वेरी ट्यूनिंग (उदा। इंडेक्स लेकिन उस तक सीमित नहीं) तक ऐप प्रश्नों के साथ बहुत असंगत हैं - सबसे गूंगा उदाहरण रिपोर्टिंग-उद्देश्य सूचकांक के कारण ऐप आवेषण को प्रभावित करने वाले हॉट स्पॉट की तरह कुछ होगा।

  • समय मुद्दों। जैसे डीबी रखरखाव के लिए उपलब्ध एकमात्र छोटी खिड़कियां (आवेदन के उपयोग के कारण) भारी रिपोर्टिंग कार्य के समय

  • डेटा की सरासर मात्रा (जैसे लॉगिंग, ऑडिटिंग, आंकड़े) की रिपोर्ट करना इतना बड़ा है कि आपका प्राथमिक डीबी सर्वर आर्किटेक्चर खराब है ऐसी रिपोर्टिंग के लिए समाधान (Sybase एएसई बनाम Sybase IQ देखें)। बीटीडब्लू, यह एक असली परिदृश्य है - हमने इस वजह से आईक्यू में अपनी प्रदर्शन रिपोर्टिंग को स्थानांतरित कर दिया।

+0

उचित अनुक्रमित टेबल और ट्यून किए गए प्रश्न उम्मीद है कि यह एक गैर-मुद्दा बनायेगा। मुझे विश्वास नहीं है कि प्रदर्शन को अलग-अलग बनाए रखने वाले डेटाबेस की आवश्यकता होगी। – northpole

+1

@ नॉर्थपोल - कभी-कभी आप अभी भी ट्यून नहीं कर सकते हैं। यदि अधिकतम ट्यूनिंग पर एक प्रश्न चलाने के लिए 1 घंटे लगते हैं, तो आप इसे दूर नहीं कर सकते हैं। उपर्युक्त उत्तर थोडा मानता है कि आप पहले से ही उतना ही बेहतर हो सकते हैं जितना हो सकता है। – DVK

+0

@ डीवीके, और आप अगला समाधान एक अलग लेकिन बराबर डेटाबेस बनाने और बनाए रखने के लिए होगा? ओरेकल क्लस्टर की तरह, नए हार्डवेयर, या एक नए डेटाबेस को एक साथ क्यों नहीं मानते? आप सुझाव देते हैं कि समय आपका मुख्य कारण है, लेकिन जब आप दोनों में वर्तमान डेटा रखने के लिए वास्तविक समय प्रतिकृति करना है तो आप अच्छे प्रदर्शन की अपेक्षा कैसे कर सकते हैं। – northpole

24

आमतौर पर, मैं शुरू में लेनदेन डेटाबेस की रिपोर्ट करने का प्रयास करता हूं।

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

आप किसी ऐसे रिपोर्टिंग डेटाबेस के लिए जाना है, तब याद वहाँ केवल कुछ कारणों तुम वहाँ जा रहे हैं कर रहे हैं:

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

अगला, रिपोर्टिंग उपयोग परिदृश्यों का समर्थन करने के लिए आपके पास एक अलग अनुक्रमण रणनीति हो सकती है। ये अतिरिक्त अनुक्रमणिका रिपोर्टिंग डेटाबेस में बनाए रखने के लिए ठीक हैं, लेकिन OLTP डेटाबेस में अनावश्यक ओवरहेड का कारण बनेंगे।

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

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

+0

+1 यह एकमात्र तरीका है जिसे इसे माना/किया जाना चाहिए। – northpole

+0

धन्यवाद - मुझे आपकी तर्क और व्याख्याएं पसंद हैं। –

6

@northpole:

उम्मीद है कि आप लगभग 2 वर्षों के बाद अपने जवाब मिल गया है। इस प्रश्न के लिए विज्ञान की बजाय अनुभव की आवश्यकता है।

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

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

जब आप ने कहा:

मैं वास्तविक समय के साथ पंक्तियों के लाखों लोगों के सैकड़ों के साथ रिपोर्टिंग के साथ परियोजनाओं पर काम सैकड़ों उपयोगकर्ता एक ही समय में आवेदन/डेटाबेस तक पहुंचने के साथ।

आपके कथन के साथ कुछ चीजें गलत हैं।

  1. सैकड़ों लाखों पंक्तियां बहुत हैं। आज भी मेमोनी टूल्स जैसे कॉग्नोस टीएम 1 या क्विक्यूव्यू में ऐसे परिणाम प्राप्त करने के लिए संघर्ष होगा। (एसएपी से एसएपी हाना को समझने के लिए कि उद्योग में दिग्गजों को कैसे संभाला जाता है)।

  2. यदि आपके पास डेटाबेस में लाखों पंक्तियां हैं, तो इसका मतलब यह नहीं है कि रिपोर्ट को उन सभी रिकॉर्डों के माध्यम से जाना होगा। हो सकता है कि रिपोर्ट लाखों लोगों पर काम न करे। शायद यही वह है जो आपने देखा था।

  3. लेनदेन संबंधी रिपोर्ट डैशबोर्ड से बहुत अलग हैं। अधिकांश डैशबोर्ड उपकरण डेटा को प्री-प्रोसेसिंग और कैश करते हैं।

मैं जानता हूँ कि मैं 2 साल बाद का जवाब दे रहा हूँ और मेरे विचारों को अच्छी तरह से आयोजित नहीं कर रहे हैं, लेकिन मेरी बात यह है कि यह सब तय करने के लिए जब अनुभव करने के लिए आता है: 1. डिजाइन एक नया स्कीमा 2. एक बनाने अर्थ डेटाबेस 3. एक ही लेन-देन संबंधी डेटाबेस पर काम 4. या यहां तक ​​कि एक रिपोर्टिंग उपकरण का उपयोग करें (जावा/JSF/अजाक्स/jQuery या JSP के साथ कभी कभी हस्तलिखित डैशबोर्ड्स ग्राहक के लिए ठीक काम करेगा)

0

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

0

मैं एक और कारण भी जोड़ूंगा जिसके लिए आप एक रिपोर्टिंग डेटाबेस का उपयोग कर सकते हैं, और यह है: सीक्यूआरएस पैटर्न (कमांड क्वेरी जिम्मेदारी पृथक्करण)।

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

पैटर्न में इसके लिए बहुत कुछ है, मैंने बस थोड़ा सा उल्लेख किया जो रिपोर्टिंग डेटाबेस के बारे में आपके प्रश्न के कारण दिलचस्प था।

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