पंचक डेटा मॉडल और डेटा के सैकड़ों गीगाबाइट

हाल ही में, हमने बड़ी मात्रा में डेटा - सैकड़ों गीगाबाइट्स के साथ काम करते समय हमने क्यूडीएम नामक दृष्टिकोण का परीक्षण किया। कार्य के हिस्से के रूप में, हमने 12-24 मिलियन रिकॉर्ड संसाधित किए और साधारण तालिकाओं में समान कार्यक्षमता के साथ पंचक समाधान के प्रदर्शन की तुलना की।

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

हम अब यह भी जानते हैं कि ऐसी स्थिति में क्या करना है - समाधान काफी सरल और विश्वसनीय है, और हमारे पास मनमाने ढंग से बड़े डेटा के लिए एक समझौता समाधान आयोजित करने का अनुभव है।

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

उपयोगकर्ता केवल एक रिपोर्टिंग तिथि के भीतर सेट किए गए इस बड़े डेटा के साथ काम करते हैं, इसलिए, संदर्भ प्रणाली में, यह सब इस तिथि तक विभाजित तालिका में संग्रहीत किया जाता है। इस फॉर्म के लिए शेष 26 डेटा फ़ील्ड के इंडेक्स का उपयोग नहीं किया जाता है।

निश्चित रूप से, हमने जो पहली चीज़ की, वह थी कंस्ट्रक्टर में वांछित डेटा संरचना बनाना और वहां कई तारीखों को लोड करना। सबसे छोटी तिथियों में से एक को डाउनलोड करने में लगभग 14 घंटे लगते हैं, जो अस्वीकार्य रूप से लंबा है: 27 विशेषताओं के 12.5 मिलियन रिकॉर्ड, 5 क्षेत्रों के आधे अरब रिकॉर्ड में तीन सूचकांकों के निर्माण के साथ डालते हैं, जिनमें से दो समग्र हैं।

डिस्क पर इस डेटा की कुल मात्रा 18 जीबी से थोड़ी अधिक है।

यह इस फॉर्म की दो विशेषताओं पर ध्यान देने योग्य है:

1. यह लगभग खुद को सामान्य करने के लिए उधार नहीं देता है, इसके विपरीत, उदाहरण के लिए, फॉर्म 110 से, पिछले प्रकाशन में चर्चा की गई है
2. यह रिकॉर्ड की विशेषताओं पर अनुक्रमित का उपयोग नहीं करता है - यह उपयोगकर्ता के लिए एक मिनट प्रतीक्षा करने के लिए अधिक लाभदायक है कि अनुक्रमित पर पैसा खर्च करने की तुलना में

यह सबसे कट्टरपंथी मामला कहा जा सकता है जिसे आप तुलना के लिए चुन सकते हैं। ज्यादातर मामलों में, QDM डेटा और सामान्य डेटाबेस की मात्रा में अंतर इतना नाटकीय या बहुत छोटा नहीं है ।

तुलना के लिए, एक संबंधपरक डेटाबेस में एक नियमित तालिका में लोड किए गए समान डेटा को दिनांक के अनुसार सूचकांक के साथ 2.3 जीबी (8 गुना कम) लगता है, और उनका डाउनलोड आधे घंटे (28 गुना तेज) से कम होता है। दोनों ही मामलों में, डेटा को सीधे अनुक्रमणिका को अक्षम किए बिना, 100 हजार रिकॉर्ड के भागों में फ़ाइल से डाला गया था।

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

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

नीचे उन नमूनों के सारांश परिणाम दिए गए हैं जो हमने एकत्रित डेटा की एक कदमवार बढ़ती मात्रा के लिए बनाए थे:

जहां यह संभव था, हमने आंकड़ों को चुनने और खाता संख्या मुखौटा द्वारा रिकॉर्ड की संख्या का चयन करने के बाद, कई माप किए।

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

विभिन्न आदेशों की संख्या की तुलना करने के लिए लघुगणकीय पैमाने का उपयोग करके समान परिणामों का चित्रमय प्रदर्शन:

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

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

अगला, हमने अपने टेबल प्लगइन ( यहां वर्णित) को एक मनमाना डेटाबेस के लिए एक कनेक्टर को कॉल करने के लिए सिखाया ताकि यह पारदर्शी रूप से पंचक डेटा मॉडल और पारंपरिक तालिकाओं दोनों के साथ काम करे।

उपयोगकर्ता के दृष्टिकोण से, वह परवाह नहीं करता है कि वह किस डेटा स्रोत के साथ काम करता है जबकि वह परिचित इंटरफ़ेस में उसके लिए महत्वपूर्ण कार्य कर सकता है, उसकी रिपोर्ट प्राप्त कर सकता है:

अब हम शेष समान विशाल तालिकाओं को निकालेंगे, जो हमारे डेटाबेस में सैकड़ों में से केवल दो दर्जन हैं, एक अलग भंडारण में ताकि उनके साथ आराम से काम किया जा सके।

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

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