तेजी से विज्ञापन-प्रसार प्रश्नों के लिए 100 एम रिकॉर्ड तालिका बनाने का एक अच्छा तरीका क्या है?

Question

परिदृश्य काफी सरल है, वहाँ 10 कॉलम (विश्लेषण डेटा की तरह) के साथ एक तालिका में 100M के बारे में रिकॉर्ड कर रहे हैं, और मैं उन 10 कॉलम के किसी भी संयोजन पर क्वेरी करने में सक्षम होना चाहिए। उदाहरण के लिए इस तरह कुछ:

• a = 3 && b > 100 के साथ कितने रिकॉर्ड पिछले 3 महीनों में हैं?

मूल रूप से सभी जिज्ञासाओं के का एक प्रकार कैसे गुण X साथ कई रिकॉर्ड समय अंतराल Y, जहां X उन 10 कॉलम के किसी भी संयोजन हो सकता है में देखते हैं होने जा रहे हैं।

डेटा में आते रहेंगे, यह सिर्फ 100M रिकॉर्ड की एक पूर्व दिए गए सेट नहीं है, लेकिन यह समय के साथ बढ़ रहा है।

चूंकि कॉलम चयन पूरी तरह से यादृच्छिक हो सकता है, के लिए इंडेक्स बनाना लोकप्रिय संयोजन संभवतः संभव नहीं है।

प्रश्न के दो भाग हैं:

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

Answer 1

आप एक SSAS घन का निर्माण और यह क्वेरी करने के लिए MDX का उपयोग करना चाहिए।

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

Answer 2

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

समानांतर मार्ग का पीछा, उद्योग मानक Hadoop है। आप अभी भी Hive के माध्यम से SQL शैली क्वेरी का उपयोग कर सकते हैं।

एक और NoSQL विकल्प के लिए एक स्तंभ डेटाबेस पर विचार करना होगा। यह क्यूब्स का उपयोग किए बिना विश्लेषण के लिए डेटा व्यवस्थित करने का एक वैकल्पिक तरीका है। वे तेजी से डेटा लोड करने में अच्छे हैं। वेक्टर वार क्षेत्र में नवीनतम खिलाड़ी है। मैंने इसे व्यक्तिगत रूप से उपयोग नहीं किया है, लेकिन पिछली रात लंदनडाटा बैठक में कोई मुझे इसके बारे में बता रहा था। Check it out।

बेशक, एसक्यूएल डेटाबेस से दूर जा रहे हैं - जो भी दिशा आप जाते हैं - एक सीधी सीखने की अवस्था होगी।

Answer 3

जहां तक ​​ओरेकल का संबंध है, यह संभवतः एक अंतराल विभाजित तालिका के रूप में संरचित किया जाएगा, जिसमें प्रत्येक कॉलम पर स्थानीय बिटमैप इंडेक्स के साथ संरचित किया जाएगा, और सीधे डेटा डालने या विभाजन एक्सचेंज के माध्यम से नया डेटा जोड़ा जा रहा है।स्तंभों की लोकप्रिय संयोजन के लिए

प्रश्नों materialized दृश्य, संभवतः रोलअप या घन प्रश्नों का उपयोग करने का एक सेट के साथ अनुकूलित किया जा सकता है।

Answer 4

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

मैं यह सोचते हैं कि आपके डेटा पूर्णांक, दिनांक या छोटे स्केलर्स है। लंबे तार आदि खेल बदल जाते हैं। मैं भी यह सोचते हैं रहा हूँ आप केवल तय तुलना (=, <,>, <>, आदि) का उपयोग कर रहे

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

बी) क्या आप "चयन " या "चयन गिनती ()" कर रहे हैं? यदि "चयन करें" नहीं है तो लंबवत विभाजन मई और इंजन और अन्य इंडेक्स के आधार पर मदद कर सकता है।

ग) प्रत्येक स्तंभ जहां मूल्यों व्यापक रूप से वितरित और न भी कई डुप्लिकेट हैं, कर रहे हैं के लिए एक स्तंभ अनुक्रमणिका बनाएँ। इंडेक्स YEAR_OF_BIRTH आम तौर पर ठीक होगा, लेकिन अनुक्रमण करना FEMALE_OR_MALE अक्सर अच्छा नहीं होता है - हालांकि यह अत्यधिक डेटाबेस इंजन विशिष्ट है।

डी) यदि आपके पास خ_OR_MALE और "वाई predicates" जैसे कॉलम हैं, तो आपके पास एक अलग समस्या है - अधिकांश पंक्तियों से महिलाओं की संख्या की गणना करने का व्यवहार किया जाएगा। आप अनुक्रमण का प्रयास कर सकते हैं, लेकिन इंजन पर निर्भर करता है।

ई) की कोशिश करो और कॉलम "शून्य नहीं" यदि संभव हो तो करना - आम तौर पर प्रति पंक्ति 1 बिट की बचत होती है और आंतरिक अनुकूलक आपरेशन को आसान बनाने में कर सकते हैं।

एफ) अपडेट/आवेषण। इंडेक्स बनाना अक्सर डालने प्रदर्शन को नुकसान पहुंचाता है, लेकिन यदि आपकी दर काफी कम है तो इससे कोई फर्क नहीं पड़ता। केवल 100 एम पंक्तियों के साथ, मुझे लगता है कि आपकी डालने की दर काफी कम है।

छ) मल्टी खंड कुंजी में मदद मिलेगी, लेकिन आप पहले से ही कहा है वे कोई जाने हैं।

ज) प्राप्त उच्च गति डिस्क (आरपीएम) - प्रश्नों के इन प्रकार के लिए समस्या आमतौर पर आईओ (टीपीसी-एच मानक आईओ के बारे में हैं, और आप एक "एच" समस्या की तरह लग रहे हैं)

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

Answer 5

उपर्युक्त सुझावों के अलावा, केवल एक अद्यतन भौतिक दृश्य पूछने पर विचार करें। मुझे लगता है कि मैं सिर्फ टेबल पर क्यूब() भौतिक दृश्य द्वारा एक चयन, गिनती (*) समूह बनाउंगा।

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

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

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

Answer 6

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

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

यदि संभव हो तो अन्य विकल्प हार्डवेयर को देखना होगा। मेरे पास सॉलिड स्टेट ड्राइव जैसे Fusion-IO का उपयोग करके अतीत में अच्छे परिणाम हुए हैं। यह क्वेरी समय को बड़े पैमाने पर कम कर सकता है। यह अच्छी डिजाइन के लिए एक प्रतिस्थापन नहीं है, लेकिन अच्छे डिजाइन और सही हार्डवेयर के साथ यह अच्छी तरह से काम करता है।