OLTP बनाम रिपोर्टिंग स्कीमा: क्या डिनॉर्मलाइज़ करें या सारांश तालिकाएँ जोड़ें?

क्यों OLTP और रिपोर्टिंग आपके स्कीमा को अलग दिशाओं में खींचते हैं

OLTP (online transaction processing) वही है जो आपकी ऐप दिन भर करती है: छोटे-छोटे ऑपरेशन जो तेज़ और सुरक्षित होने चाहिए। एक ऑर्डर बनाएँ, स्टेटस अपडेट करें, पेमेंट जोड़ें, एक संदेश लॉग करें। डेटाबेस तेज़ inserts और updates, कड़े नियम (जैसे foreign keys), और सरल क्वेरीज़ के लिए अनुकूलित होता है जो केवल कुछ पंक्तियों को छूते हैं।

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

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

एक एकल स्कीमा कभी-कभी दोनों की सेवा कर सकता है, खासकर शुरूआत में। लेकिन जैसे-जैसे डेटा बढ़ता है, आप आम तौर पर इन तरह के ट्रेडऑफ़ महसूस करना शुरू कर देते हैं:

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

इसीलिए टीमें सामान्यतः एक या अधिक रणनीतियाँ अपनाती हैं: सामान्य स्लाइस के लिए खास फ़ील्ड्स डिनॉर्मलाइज़ करना, बार-बार के टोटल्स के लिए सारांश तालिकाएँ जोड़ना, या रिपोर्टिंग व्यूज़/अलग रिपोर्टिंग स्कीमा बनाना ताकि OLTP प्रदर्शन सुरक्षित रहे और संख्याएँ सुसंगत रहें।

लेन-देन स्क्रीन और BI स्क्रीन में क्या बदलता है

लेन-देन स्क्रीन और BI स्क्रीन एक ही बिज़नेस फैक्ट दिखा सकती हैं, लेकिन वे आपके डेटाबेस से विपरीत व्यवहार की मांग करती हैं। यही OLTP बनाम रिपोर्टिंग स्कीमा निर्णय का मूल है।

लेन-देन स्क्रीन पर अधिकांश रिक्वेस्ट कुछ ही पंक्तियों को छूते हैं। उपयोगकर्ता ऑर्डर बनाता है, ग्राहक संपादित करता है, भुगतान वापस करता है, या स्टेटस बदलता है। डेटाबेस बहुत सारी छोटी inserts और updates से व्यस्त रहता है, और हर एक को तेज़ और सुरक्षित रूप से कन्फर्म करना आवश्यक है।

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

क्वेरी कैसे बदलती हैं

OLTP में, नॉर्मलाइज्ड तालिकाएँ और साफ़ रिश्ते आपके दोस्त होते हैं। आप डेटा सुसंगत रखते हैं, दोहराव से बचते हैं, और एक तथ्य को एक जगह अपडेट करते हैं।

BI में, जॉइन्स बॉटलनेक बन सकते हैं। डैशबोर्ड्स अक्सर उन चौड़ी तालिकाओं के साथ बेहतर काम करते हैं जिनमें पहले से ही वे फ़ील्ड शामिल हों जिनसे लोग फ़िल्टर करते हैं (दिनांक, क्षेत्र, उत्पाद श्रेणी, ओनर)। इससे रीड समय पर जॉइन का काम कम होता है और क्वेरीज़ सरल रहती हैं।

एक त्वरित तरीका अंतर पहचानने का:

• लेन-देन स्क्रीन: कई छोटे लिखे हुए ऑपरेशन, तेज़ पॉइंट रीड्स
• BI स्क्रीन: कम रिक्वेस्ट, पर भारी रीड्स के साथ समूह और फ़िल्टर
• OLTP डेटा: सुसंगतता के लिए नॉर्मलाइज्ड
• BI डेटा: अक्सर जॉइन्स और स्कैन घटाने के लिए पुनःआकारित

समवर्तीता और ताज़गी

OLTP को अपडेट्स के लिए उच्च समवर्तीता चाहिए। लंबी चलने वाली रिपोर्टिंग क्वेरियाँ ब्लॉक कर सकती हैं या उन अपडेट्स को धीमा कर सकती हैं, खासकर जब वे बड़े रेंज स्कैन करती हैं।

ताज़गी की अपेक्षाएँ भी बदल जाती हैं। कुछ डैशबोर्ड्स को लगभग रीयल-टाइम चाहिए (जैसे सपोर्ट क्यूज़)। अन्य घंटा-वार या दिन भर ठीक रहते हैं (वित्त, प्रदर्शन)। यदि आप शेड्यूल पर रिफ्रेश कर सकते हैं तो आपको सारांश तालिकाएँ, materialized views, या अलग रिपोर्टिंग स्कीमा उपयोग करने की स्वतंत्रता मिलती है।

यदि आप ये स्क्रीन AppMaster में बनाते हैं, तो देर से योजना बनाना मदद करता है: अपना ट्रांज़ैक्शनल मॉडल साफ़ रखें, फिर रिपोर्टिंग डेटा को विशेष रूप से डैशबोर्ड फ़िल्टर और एग्रीगेट्स के लिए आकार दें।

रिपोर्टिंग के लिए समायोजन की संकेतक

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

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

सामान्य संकेत ये हैं:

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

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

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

कब डिनॉर्मलाइज़ करना सही रहेगा

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

यह OLTP बनाम रिपोर्टिंग स्कीमा निर्णय में एक आम मोड़ है: लेन-देन स्क्रीन को साफ़, अपडेट-हितैषी तालिकाएँ चाहिए, जबकि BI-स्टाइल स्क्रीन को कम जॉइन्स के साथ तेज़ रीड्स चाहिए। एनालिटिक्स के लिए कुछ फ़ील्ड कॉपी करना हर पेज लोड पर पाँच टेबल्स जॉइन करने से सस्ता पड़ सकता है।

डिनॉर्मलाइज़ करें जब यह स्पष्ट रूप से आपको स्पीड और सरल क्वेरीज़ दे और आप लिखने के पाथ को सुरक्षित रख सकें। मुख्य बात यह है कि डुप्लिकेट किए गए फ़ील्ड्स को व्युत्पन्न डेटा मानें, न कि "उपयोगकर्ता संपादित कर सकता है" वाला दूसरा स्रोत। एक स्रोत ऑफ़ ट्रूथ रखें, और हर कॉपी को कोड या नियंत्रित प्रक्रिया से अपडेट कराएँ।

अच्छे उम्मीदवार हैं फ़ील्ड जो:

• डैशबोर्ड में लगातार पढ़े जाते हैं पर शायद ही संपादित होते हैं (ग्राहक नाम, उत्पाद श्रेणी)
• बार-बार जोड़ने पर महँगे होते हैं (many-to-many रिश्ते, गहरे चेन)
• जल्दी फ़िल्टर और समूह करने के लिए चाहिए (क्षेत्र, टीम, प्लान टियर)
• सत्यापित करने में आसान हों (विश्वसनीय तालिका से कॉपी किए गए, न कि फ्री-टेक्स्ट)

स्वामित्व मायने रखता है। किसी को (या किसी जॉब को) डुप्लिकेट्स को सुसंगत रखने की ज़िम्मेदारी लेनी चाहिए, और यह तय करना चाहिए कि स्रोत बदलने पर क्या होता है।

उदाहरण: एक सेल्स डैशबोर्ड ऑर्डर्स को सेल्स रेप और क्षेत्र द्वारा समूहित करता है। हर बार Orders -> Customers -> Regions को जॉइन करने के बजाय, आप ऑर्डर के निर्माण के समय region_id ऑर्डर पर स्टोर कर सकते हैं। यदि बाद में ग्राहक क्षेत्र बदलता है, तो आपका नियम हो सकता है "ऐतिहासिक ऑर्डर्स मूल क्षेत्र रखते हैं" या "रात में पुराने ऑर्डर्स को बैकफिल करें"। एक चुनें, दस्तावेज़ बनाएं, और लागू करें।

यदि आप AppMaster में PostgreSQL का उपयोग कर रहे हैं, तो यह प्रकार का डिनॉर्मलाइज़्ड फ़ील्ड Data Designer में मॉडल करना आसान है, बशर्ते आप यह लॉक करें कि कौन इसे लिख सकता है और इसे लगातार अपडेट किया जाए।

बचने योग्य डिनॉर्मलाइज़ेशन जाल

डिनॉर्मलाइज़ेशन BI स्क्रीन तेज़ कर सकता है, पर यह "दो सच्चाइयों" बनाने का आसान तरीका भी है। सबसे सामान्य विफलता वही तथ्य कई जगहों पर दोहराने की है बिना स्पष्ट बता दिए कि असहमति होने पर कौन सा फ़ील्ड जीतता है। यदि आप order_total और line items दोनों स्टोर करते हैं, तो आपको एक नियम चाहिए कि order_total कैलकुलेट है, उपयोगकर्ता द्वारा डाला गया है, या पेमेंट प्रोवाइडर से कॉपी किया गया है।

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

अपने OLTP पाथ में बहुत चौड़ी तालिकाओं के साथ सावधान रहें। एक ही तालिका में कई डिनॉर्मलाइज़्ड कॉलम जोड़ना लिखने को धीमा कर सकता है, लॉक समय बढ़ा सकता है, और साधारण अपडेट्स को भारी बना सकता है। यह विशेष रूप से कष्टप्रद होता है जब आपके पास उच्च वॉल्यूम वाली तालिकाएँ हों जैसे events, order lines, या support messages।

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

व्यावहारिक उदाहरण: आपने हर order पर rep_name जोड़ दिया ताकि "Sales by Rep" डैशबोर्ड दिख सके। कोई रेप का नाम बदलता है या रीअसाइन होता है, और अब पिछले क्वार्टर की संख्या दो नामों में बंटी दिखती है। यदि आपको केवल डिस्प्ले के लिए नाम चाहिए तो एक स्थिर rep_id स्टोर करने पर विचार करें और नाम रिपोर्टिंग व्यू में हल करें, या जानबूझकर नाम का स्नैपशॉट लें और उसे rep_name_at_sale जैसा स्पष्ट लेबल दें।

डिनॉर्मलाइज़ करने से पहले पुष्टि कर लें:

• प्रत्येक दोहराए मान के लिए स्रोत ऑफ़ ट्रूथ परिभाषित करें और लिख दें।
• परिवर्तनीय टेक्स्ट फील्ड्स के बजाय स्थिर IDs पसंद करें।
• तय करें कि आप करंट-स्टेट रिपोर्टिंग चाहते हैं या प्वाइंट-इन-टाइम स्नैपशॉट्स।
• एक साफ़ रखरखाव तंत्र जोड़ें (trigger, job, या workflow step) और एक मालिक निर्दिष्ट करें।
• mismatches की निगरानी करें (सरल reconciliation क्वेरियाँ) ताकि त्रुटियाँ जल्दी सामने आएं।

यदि आप AppMaster में PostgreSQL का उपयोग करते हैं, तो रखरखाव को Business Process चरण से जोड़ना मदद करता है ताकि अपडेट्स लगातार हो, न कि "जब किसी को याद आए"।

कब सारांश या एग्रीगेट तालिकाएँ जोड़ें

सारांश तालिकाएँ तब समझ में आती हैं जब आपकी BI-स्टाइल स्क्रीन बार-बार एक ही टोटल्स की जरूरत मांगती हैं: दैनिक साइनअप्स, प्लान के अनुसार राजस्व, सक्रिय उपयोगकर्ता, रिफंड्स, बंद किए गए टिकट्स, और समान KPI।

एक अच्छा संकेत है पुनरावृत्ति। यदि कई डैशबोर्ड कार्ड लगभग एक समान क्वेरियाँ चलाते हैं जिनमें वही GROUP BY होता है, तो आपका डेटाबेस बार-बार वही काम कर रहा होता है। 1,000 पंक्तियों पर यह ठीक लगता है और 10 मिलियन पर दर्दनाक हो जाता है। OLTP बनाम रिपोर्टिंग स्कीमा चर्चा में, यह अक्सर वह क्षण होता है जहाँ आप इंडेक्सTweaks बंद करके प्रीकंप्यूटिंग की ओर बढ़ते हैं।

आप अक्सर सारांश तब भी जोड़ते हैं जब आपको पहले से ज्ञात गति चाहिए। चार्ट सेकंडों में लोड होने चाहिए, "कभी-कभी तेज़, कभी-कभी धीमा" नहीं। एक सारांश तालिका महँगे स्कैन को छोटे लुकअप में बदल देती है।

सामान्य ट्रिगर्स जिनसे पता चलता है कि सारांश तालिका मदद करेगी:

• आपका डैशबोर्ड कई स्क्रीन या फ़िल्टर्स में एक ही GROUP BY बार-बार चलाता है।
• आप अक्सर टाइम बकेट्स (दिन/सप्ताह/महीना) और टॉप-एन सूचियाँ क्वेरी करते हैं।
• बेस टेबल्स append-heavy हैं (events, transactions, logs)।
• स्टेकहोल्डर्स एक ज्ञात कटऑफ़ पर स्थिर KPI संख्याएँ चाहते हैं (उदा., "मिडनाइट तक")।

रिफ्रेश रणनीति निर्णय का दूसरा हिस्सा है। आपके पास कुछ व्यावहारिक विकल्प हैं, यह निर्भर करता है कि संख्याएँ कितनी ताज़ा चाहिए:

• शेड्यूल्ड रिफ्रेश (हर 5 मिनट, घंटा-वार, रात भर) निरंतर वर्कलोड के लिए।
• ईवेंट-आधारित रिफ्रेश मुख्य क्रियाओं के बाद (नया ऑर्डर, सब्स्क्रिप्शन परिवर्तन) जब नज़दीकी-रीयल-टाइम महत्वपूर्ण हो।
• हाइब्रिड: शेड्यूल्ड बैकफिल प्लस छोटे इंक्रीमेंटल अपडेट्स।

तालिका को फोकस्ड और सरल रखें: उसका ग्रेन स्पष्ट होना चाहिए (उदा., प्रति दिन प्रति प्लान एक पंक्ति), और कॉलम वे मीट्रिक्स होने चाहिए जिन्हें आपके चार्ट सीधे पढ़ते हैं। यदि आप AppMaster में बना रहे हैं, तो यह अक्सर साफ़ फिट होता है: aggregates को PostgreSQL में स्टोर करें और उन्हें Business Process के माध्यम से शेड्यूल पर या संबंधित ईवेंट के बाद रिफ्रेश कराएँ।

सारांश तालिका चरण-दर-चरण डिज़ाइन कैसे करें

सारांश तालिका OLTP बनाम रिपोर्टिंग स्कीमा में एक जानबूझकर समझौता है: आप ट्रांज़ैक्शनल कच्ची तालिकाएँ रखते हैं, और एक छोटी तालिका जोड़ते हैं जो आम डैशबोर्ड प्रश्नों का तेज़ उत्तर देती है।

1) सबसे पहले ग्रेन चुनें

शुरू में तय करें कि एक पंक्ति का मतलब क्या है। यदि आप इसे गलत चुनते हैं, तो बाद में हर मीट्रिक समझाना कठिन हो जाएगा। सामान्य ग्रेन्स में प्रति दिन प्रति ग्राहक, प्रति ऑर्डर, या प्रति एजेंट प्रति दिन शामिल होते हैं।

ग्रेन का परीक्षण करने का सरल तरीका: क्या एक पंक्ति बिना "शायद" के अद्वितीय रूप से पहचानी जा सकती है? यदि नहीं, तो ग्रेन अभी भी अस्पष्ट है।

2) तालिका को सवालों के आधार पर डिज़ाइन करें, न कि कच्चे डेटा के

उन कुछ संख्याओं को चुनें जिन्हें आपकी BI स्क्रीन वास्तव में दिखाती हैं। केवल जो चाहिए वही स्टोर करें: sums और counts आमतौर पर ठीक रहते हैं, साथ में min/max जब रेंज चाहिए। यदि आपको "यूनिक ग्राहक" दिखाना है, तो तय करें कि क्या आपको सटीक distinct count चाहिए (भारी) या एक approximation (हल्का), और उस विकल्प को साफ़ लिखें।

यहाँ एक व्यावहारिक कदम अनुक्रम है:

• 5–10 डैशबोर्ड सवाल लिखें (उदा., "प्रति एजेंट प्रति दिन बिक्री")
• ऐसा ग्रेन चुनें जो अधिकतर प्रश्नों को एक पंक्ति से उत्तर दे सके
• कॉलम्स को केवल aggregates के रूप में परिभाषित करें (sum, count, min, max, संभवतः distinct)
• उन keys और indexes को जोड़ें जो आपके फ़िल्टर्स से मेल खाते हों (date, agent_id, customer_id)
• यह परिभाषित करें कि देर से आने वाले बदलाव (refunds, edits, cancellations) कैसे हैंडल होंगे

3) एक भरोसेमंद रिफ्रेश मेथड चुनें

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

यदि आप AppMaster के साथ बनाते हैं, एक आम पैटर्न है एक शेड्यूल्ड जॉब जो एक Business Process चलाकर कल और आज को फिर से गणना करे, जबकि पुराने दिन "फ्रीज़" रहते हैं।

4) मिलान जाँच जोड़ें

सारांश तालिका पर भरोसा करने से पहले, कुछ बुनियादी जाँचें जोड़ें जो इसे कच्ची तालिकाओं से तुलना करें:

• किसी दिनांतराल के लिए टोटल्स स्वीकार्य सीमा के भीतर मेल खाते हों
• काउंट्स मेल खाते हों (ऑर्डर्स, यूज़र्स, टिकट्स) उन ही फ़िल्टर्स के लिए
• कुछ एंटिटीज़ का एन-ड-एंड-टू-एन्ड स्पॉट-चेक करें (एक एजेंट, एक ग्राहक)
• गैप्स (मISSING दिन) और डुप्लिकेट्स (एक ही कुंजी दो बार) का पता लगाएं

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

अलग रिपोर्टिंग व्यूज़ और स्कीमा: वे क्या हल करते हैं

OLTP तालिकाएँ साफ़ रखने का मुख्य कारण सत्यता है। आप स्पष्ट नियम, मजबूत constraints, और ऐसी संरचना चाहते हैं जो बुरा डेटा बनाना कठिन करे। रिपोर्टिंग स्क्रीन कुछ अलग चाहती हैं: कम जॉइन्स, दोस्ताना नाम, और ऐसे मीट्रिक्स जो पढ़ने के लिए तैयार हों। यही असंगति अक्सर टीमों को कोर तालिकाओं को बदलने के बजाय एक रिपोर्टिंग लेयर जोड़ने के लिए प्रेरित करती है।

एक रिपोर्टिंग व्यू (या अलग रिपोर्टिंग स्कीमा) अनुवाद परत की तरह काम करता है। आपकी ऐप नॉर्मलाइज्ड तालिकाओं में लिखना जारी रखती है, जबकि BI-स्टाइल स्क्रीन उन ऑब्जेक्ट्स को पढ़ती हैं जिन्हें "महीना के अनुसार", "क्षेत्र के अनुसार", या "टॉप 10 उत्पाद" जैसे प्रश्नों के लिए डिज़ाइन किया गया है। यह अक्सर OLTP बनाम रिपोर्टिंग स्कीमा तनाव को बिना ट्रांज़ैक्शनल लॉजिक तोड़े सुलझाने का सबसे साधारण तरीका होता है।

व्यूज़ बनाम materialized कॉपी

लॉजिकल व्यूज़ तब श्रेष्ठ हैं जब डेटा वॉल्यूम मध्यम हो और क्वेरियाँ अपेक्षाकृत पूर्वानुमेय हों। वे एक स्रोत ऑफ़ ट्रूथ रखते हैं और आपके डैशबोर्ड क्वेरियों में लॉजिक की दोहराव कम करते हैं।

materialized कॉपीज़ (materialized views, summary tables, या replicated tables) तब समझ में आती हैं जब रिपोर्टिंग लोड भारी हो, कैलकुलेशन महँगा हो, या आपको पीक घंटों के दौरान स्थिर प्रदर्शन चाहिए।

एक त्वरित चयन मार्गदर्शिका:

• पढ़ने योग्य परिभाषाएँ और consistente definitions चाहिए तो logical views का उपयोग करें।
• डैशबोर्ड धीमे हैं या कोर लिखने के साथ प्रतिस्पर्धा कर रहे हैं तो materialized copies का उपयोग करें।
• क्लियर बाउंडरी और स्वामित्व चाहिए तो अलग reporting schema का उपयोग करें।
• रिपोर्टिंग पढ़ने के कारण write latency प्रभावित हो रही हो तो replica या अलग डेटाबेस का उपयोग करें।

जब रिपोर्टिंग लिखने से टकराती है

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

उदाहरण: एक सपोर्ट टीम डैशबोर्ड हर कुछ सेकंड में "ओपन टिकट्स SLA स्थिति के अनुसार" दिखाती है। OLTP सिस्टम टिकट्स लगातार अपडेट करता है। रिपोर्टिंग व्यूज़ (या प्रीकम्प्यूटेड स्टेटस काउंट्स) को रेप्लिका पर रखने से डैशबोर्ड तेज़ रहता है बिना टिकट अपडेट्स को धीमा किए। AppMaster प्रोजेक्ट्स में, यह पैटर्न आपके ट्रांज़ैक्शनल डेटा मॉडल को साफ़ रखते हुए रिपोर्टिंग-फ्रेंडली ऑब्जेक्ट्स डैशबोर्ड को देने में भी मदद करता है।

एक वास्तविक उदाहरण: सेल्स परफॉर्मेंस डैशबोर्ड बनाना

बिज़नेस एक Sales डैशबोर्ड मांगती है जो दैनिक राजस्व, दैनिक रिफंड्स, और पिछले 30 दिनों के लिए "टॉप प्रोडक्ट्स" सूची दिखाए। ट्रांज़ैक्शन स्क्रीन पर OLTP डेटाबेस साफ़ और नॉर्मलाइज्ड है: orders, payments, refunds, और line items अलग तालिकाओं में हैं। यह सत्यता और अपडेट्स के लिए अच्छा है, पर डैशबोर्ड को अब बहुत सारी पंक्तियाँ स्कैन और जॉइन करनी होंगी, फिर उन्हें दिन के अनुसार समूहित करना होगा।

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

विकल्प A: तेज़ फ़िल्टरिंग के लिए डिनॉर्मलाइज़ करें

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

अच्छे उम्मीदवार वे फ़ील्ड हैं जो शायद ही बदलते हों, जैसे उत्पाद श्रेणी या खरीद के समय का सेल्स क्षेत्र। आप स्रोत ऑफ़ ट्रूथ को नॉर्मलाइज्ड तालिकाओं में रखते हैं, पर BI-स्टाइल स्क्रीन तेज़ करने के लिए एक "क्वेरी-फ्रेंडली" कॉपी स्टोर करते हैं।

विकल्प B: चार्ट और रैंकिंग के लिए दैनिक सारांश तालिकाएँ

यदि डैशबोर्ड चार्ट और टॉप सूचियों पर भारी है, तो सारांश तालिकाएँ आमतौर पर जीतती हैं। एक दैनिक फैक्ट तालिका जैसे daily_sales बनाएं जिसमें कॉलम हों: date, gross_revenue, refunds, net_revenue, orders_count। "टॉप प्रोडक्ट्स" के लिए एक daily_product_sales तालिका जोड़ें जो date और product_id से की गई हो।

ताज़गी और लागत किस तरह चुनाव बदलते हैं:

• नज़दीकी रीयल-टाइम चाहिए (हर मिनट): डिनॉर्मलाइज़ करें और लाइव क्वेरी करें, या सारांशों को बहुत बार रिफ्रेश करें।
• घंटा-वार या रात भर ठीक है: सारांश क्वेरी टाइम को काफी घटाते हैं।
• उच्च ट्रैफ़िक डैशबोर्ड्स: सारांश OLTP तालिकाओं पर लोड कम करते हैं।
• जटिल बिज़नेस नियम (रिफंड टाइमिंग, आंशिक भुगतान): सारांश परिणामों को सुसंगत और टेस्ट करने में आसान बनाते हैं।

AppMaster जैसे टूल्स में यह अक्सर साफ़ ट्रांज़ैक्शनल डेटा मॉडल प्लस एक शेड्यूल्ड प्रोसेस का नक्शा बनता है जो तेज़ डैशबोर्ड्स के लिए सारांश तालिकाएँ भरता है।

धीमे डैशबोर्ड और गलत संख्याओं के सामान्य गलतियाँ

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

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

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

मीट्रिक परिभाषा में बदलाव सबसे बड़ी उलझन लाते हैं। "Revenue" शुरू में paid invoices हो सकता है, फिर बाद में paid minus refunds बन जाए, और बाद में "recognized revenue" बन जाए। यदि आप लॉजिक को बिना versioning के ओवरराइट कर देते हैं, तो पिछले महीने का चार्ट बदल जाता है और कोई भी डैशबोर्ड पर भरोसा नहीं करता।

ये प्रैक्टिकल गार्डरेल अधिकांश समस्याओं को रोकते हैं:

• भारी डैशबोर्ड क्वेरियों को लिखने-भारी लेन-देन पाथ से अलग रखें जहाँ संभव हो (यहाँ तक कि केवल अलग रिपोर्टिंग तालिकाएँ ही सही हों)।
• व्यूज़ को कोड की तरह मानें: परिवर्तन की समीक्षा करें, प्रदर्शन टेस्ट करें, और दस्तावेज़ करें कि वे क्या जॉइन करते हैं।
• सारांश तालिकाओं के लिए freshness चेक जोड़ें (last updated time, row counts, sanity totals) और ब्रेक होने पर अलर्ट करें।
• मुख्य मीट्रिक्स का versioning करें, और ऐतिहासिक रिपोर्ट्स के लिए पुरानी परिभाषाएँ उपलब्ध रखें।

यदि आप AppMaster पर PostgreSQL के साथ BI-स्टाइल स्क्रीन बना रहे हैं, तो ये नियम और भी महत्वपूर्ण हो जाते हैं क्योंकि तेज़ iteration आसान है। स्पीड अच्छी है, पर केवल तब जब संख्याएँ सही रहें।

स्कीमा बदलने से पहले त्वरित चेकलिस्ट

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

अगला, गणना की सनियता जांचें। चिह्नित करें कौन से मीट्रिक्स जोड़ने योग्य (additive) हैं और कौन से विशेष लॉजिक चाहिए। राजस्व, मात्रा, और कुल कॉल सामान्यतः जोड़ने योग्य होते हैं। कन्वर्ज़न रेट, औसत ऑर्डर वैल्यू, और यूनिक ग्राहक नहीं होते। यह एक कदम सबसे सामान्य रिपोर्टिंग गलती रोकता है: तेज़ डैशबोर्ड पर गलत संख्याएँ।

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

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

प्रत्येक मीट्रिक के लिए तय करें कि "कितना ताज़ा काफी है" और फिर एक सरल validation नियम सेट करें। उदाहरण: "डैशबोर्ड में दैनिक ऑर्डर्स उस तारीख के ऑर्डर्स टेबल काउंट से 0.5% के भीतर मैच करने चाहिए" या "कुल राजस्व केवल पोस्टेड स्टेटस वाले इनवॉइस से मेल खाना चाहिए"।

अंत में, स्वामित्व पर सहमति बनाएं। नाम दें कि कौन स्कीमा परिवर्तनों को मंजूर करता है और कौन मीट्रिक परिभाषाओं का स्वामी है। यदि आप AppMaster में बना रहे हैं, तो उन परिभाषाओं को डेटा मॉडल और बिज़नेस प्रोसेसेस के साथ कैप्चर करें ताकि वही लॉजिक स्क्रीन और रिपोर्ट्स में लगातार उपयोग हो।

अगले कदम: एक पथ चुनें और सुरक्षित रूप से लागू करें

OLTP बनाम रिपोर्टिंग स्कीमा निर्णय को प्रदर्शन बग की तरह ट्रीट करें, न कि एक बड़े री-डिज़ाइन प्रोजेक्ट की तरह। माप से शुरू करें। 2–3 सबसे धीमी डैशबोर्ड क्वेरियों को खोजें, नोट करें कि वे कितनी बार चलती हैं, और उनका आकार कैप्चर करें: बड़े जॉइन्स, टाइम फ़िल्टर्स, "टॉप N" सूचियाँ, और दोहराए गए टोटल्स।

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

यहाँ एक सुरक्षित लागू करने का फ्लो है जो संख्याओं की विश्वसनीयता बनाए रखता है:

• डैशबोर्ड लक्ष्य परिभाषित करें (टाइम रेंज, समूहण, रिफ्रेश जरूरतें) और एक acceptance metric चुनें (उदा., लोड्स 2 सेकंड से कम)
• एक समय में एक परिवर्तन करें (एक डिनॉर्मलाइज़्ड फ़ील्ड, एक सारांश तालिका, या एक रिपोर्टिंग व्यू)
• निश्चित परीक्षण विंडो (कल, पिछले 7 दिन, पिछला पूरा महीना) का उपयोग कर OLTP स्रोत के खिलाफ टोटल्स को validate करें
• धीरे-धीरे रोल आउट करें और पूरे सप्ताह प्रदर्शन और शुद्धता पर नजर रखें
• "क्वेरी टाइम" और "रो काउंट्स" के लिए अलर्ट जोड़ें ताकि मौन ड्रिफ्ट जल्दी पकड़ी जा सके

यदि आप AppMaster में ये स्क्रीन बना रहे हैं, तो OLTP एंटिटी (वो जो ट्रांज़ैक्शन स्क्रीन और संपादनों के लिए उपयोग होती हैं) और रिपोर्टिंग एंटिटी (रीड-ऑप्टिमाइज़्ड मॉडल जो BI-स्टाइल पेज्स को पावर करते हैं) के बीच एक साफ़ विभाजन योजना बनाएं। वेब UI बिल्डर में BI स्क्रीन का प्रोटोटाइप बनाएं उपयोगकर्ताओं द्वारा सचमुच किन फिल्टर और डेट रेंजेस पर क्लिक किया जाता है उसे ध्यान में रखकर, फिर डेटा मॉडल को समायोजित करें।

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