एक वितरित डेटाबेस, माइक्रोसॉफ़्ट और ईआरपी में डेटा का सामान्यीकरण

नमस्कार, हेब्र!

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

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

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

एक विशिष्ट व्यावसायिक अनुप्रयोग को डेटा परिवर्तन श्रृंखला के रूप में दर्शाया जा सकता है:
"इनपुट => मॉडल => आउटपुट"। कोई भी संग्रहण योजना तीन चरम सीमाओं के बीच एक समझौता है:

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

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

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

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

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