2013-05-08 16 views
5

मेरी टीम को निम्नलिखित समस्या का हल ढूंढने की आवश्यकता है:मैं उच्च उपलब्धता वाले योगों की स्थिरता कैसे सुनिश्चित करूं?

हमारा एप्लिकेशन उपयोगकर्ताओं को उद्यम के लिए कुल बिक्री, उत्पाद द्वारा कुल योग, क्षेत्र द्वारा कुल योग, क्षेत्र x उत्पाद द्वारा कुल योग, क्षेत्रों x विभाजन द्वारा योग, आदि आपको विचार मिलता है। ऐसे कई मूल्य हैं जिन्हें उन कुल योगों को प्राप्त करने के लिए एकत्रित करने की आवश्यकता है जिन्हें उन्हें फ्लाई पर गणना नहीं की जा सकती है - हमें उन्हें सभ्य प्रतिक्रिया समय प्रदान करने के लिए पूर्व-योग करना होगा, एक प्रक्रिया जिसमें लगभग 5 मिनट लगते हैं।

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

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

हमें आश्चर्य है कि हमें इस बारे में कोई चर्चा नहीं मिल रही है और हम चिंतित हैं कि हम इस समस्या से अधिक इंजीनियरिंग कर रहे हैं या शायद यह समस्या नहीं है जो हम सोचते हैं। किसी भी सलाह की सराहना की है।

+0

हमारे पास कई पूर्व-योग थे, लेकिन हम अंतिम स्थिरता से खुश थे, इसलिए हमें चालाक चाल के साथ आने की आवश्यकता नहीं थी। आपका प्रस्तावित दृष्टिकोण व्यवहार्य दिखता है। –

+0

@sergio धन्यवाद!आपकी आखिरी टिप्पणी मुझे आशा देती है। – RonR

उत्तर

2

यह एक दिलचस्प समस्या थी इसलिए मैंने ट्रेन पर इसके बारे में सोचा, और मैं डेटाबेस में प्रत्येक पंक्ति के लिए टाइमस्टैम्प संग्रहीत करने के विचार के साथ आया था। (मुझे लगता है कि इस तकनीक का नाम है, लेकिन यह मुझे बचता है और गुगलिंग इसे नहीं ढूंढ रहा है ...)

टाइमस्टैम्प इंगित करेगा कि यह पंक्ति कब डाली गई थी। इसके अलावा:

-अगर पंक्तियों को अद्यतन किया जा सकता है, तो आपके पास पंक्ति में दो 'संस्करण' होंगे, एक दूसरे से एक और हालिया।

-अगर पंक्तियां हटा दी जा सकती हैं, तो वहां एक 'हटाई गई संस्करण' पंक्ति होने की आवश्यकता होगी जो इसे हटाए जाने पर निर्दिष्ट करता है।

अब आप इस तरह के रूप कर सकते हैं:

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

2) मुझे नहीं पता कि यह कितना व्यवहार्य/गारंटी है कि यह विश्वसनीय है, लेकिन आप 2 अलग-अलग 2 जनवरी 2000 को मध्यरात्रि में 'अलग-अलग गणना वाले योग' कर सकते थे, आप 1 जनवरी 2000 मध्यरात्रि के अपडेट लेते हैं और अपडेट करते हैं उन्हें केवल उस डेटा के साथ बदल दिया गया है जो उस समय से बदल दिया गया है - आपको इतनी ऐतिहासिक डेटा को पुनः संयोजित करने से बचा रहा है।(निश्चित रूप से, जब आप पंक्तियों को अपडेट या हटाए जाते हैं तो 24 घंटे से अधिक पुराने होने पर विचार किया जाता है)

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

+0

हां, इसे "पंक्ति संस्करण" कहा जाता है लेकिन मुझे नहीं लगता कि यह हमारी स्थिति में कैसे मदद करेगा। अपडेट "ए" में होंगे लेकिन हमें अभी भी "बी" होना चाहिए क्योंकि "बी" में पूरी तरह से अलग स्कीमा है जो क्वेरी के लिए अनुकूलित है। – RonR

+0

@RonR ठीक है, अगर आप सी से छुटकारा पा सकते हैं और अभी भी उच्च उपलब्धता + स्थिरता है, तो यह बात है, है ना? जब आप नए समेकन की गणना करते हैं तो आप उन्हें नए टाइमस्टैम्प के साथ जोड़ते हैं जो इंगित करते हैं कि वे उस टाइमस्टैम्प तक डेटा के लिए मान्य हैं - यदि आप अभी भी पुराने योग का उपयोग कर रहे हैं तो आप अभी भी उस टाइमस्टैम्प तक पंक्तियों का संदर्भ लेंगे, अगर आप स्वैप करते हैं नए समेकन आप उस टाइमस्टैम्प तक पंक्तियों को संदर्भित करते हैं। – Patashu

+0

सहमत हैं कि यह बात है। मैंने आपके प्रारंभिक प्रतिक्रिया की गलत व्याख्या की है जिसमें यह सुझाव दिया गया है कि सबकुछ केवल "ए" के साथ किया जा सकता है। – RonR

2

यदि फ्लाई पर अपडेट की गणना नहीं की जा सकती है, तो परिणामों के कैशिंग को अन्य डेटाबेस में कर रहे हैं तेजी से प्रतिक्रिया समय के साथ उपलब्धता के मुद्दे को हल करें।

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

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

शायद लेनदेन अलगाव पर एक खोज निरंतरता पर चर्चा के लिए और अधिक परिणाम बदलेगी।

+0

हम्म। इसमें कुछ अतिरिक्त जटिलताओं की लागत पर 2 डेटाबेस स्वैप करने की आवश्यकता के साथ बांटने के तरीके के रूप में निश्चित संभावनाएं हैं। धन्यवाद! – RonR

1

मुझे लगता है कि आप Data Warehousing अवधारणाओं

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

...

ईटीएल आधारित डाटा गोदाम के विपरीत, एकीकृत स्रोत डेटा प्रणालियों और डेटा गोदाम सभी एकीकृत कर रहे हैं के बाद से वहाँ आयामी या संदर्भ डेटा का कोई परिवर्तन है। यह एकीकृत डेटा वेयरहाउस आर्किटेक्चर एकीकृत स्रोत डेटा सिस्टम के लेनदेन संबंधी डेटा पर डेटा वेयरहाउस के कुल डेटा से ड्रिल का समर्थन करता है।

+0

हां, यह आधे समाधान है - कुल मिलाकर अलग डेटाबेस, समेकन, प्रवृत्ति इत्यादि के प्रश्नों के लिए डिज़ाइन किया गया है, लेकिन दूसरा आधा बड़ा सवाल है: स्थिरता की गारंटी देते समय हम dw को कैसे अपडेट करते हैं? – RonR

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