कुंजी/जोड़ी तालिका बनाम एक्सएमएल फील्ड और एक्सपीएथ

Question

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

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

यह घटना डेटा लगातार स्ट्रीमिंग में रहेगा ताकि सम्मिलित समय क्वेरी समय के समान ही महत्वपूर्ण हो।

जब मैं विशिष्ट घटनाओं के लिए पूछता हूं तो मैं ईवेंट पर कुछ फ़ील्ड और कुंजी/मूल्य डेटा से डेटा का उपयोग करूँगा। एक्सएमएल तरीके के लिए मैं रिकॉर्ड्स को फ़िल्टर करने के लिए क्लॉज के हिस्से के रूप में बस एक Attributes.exists ('xpath') कथन का उपयोग करता हूं।

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

Answer 1

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

एक सच्ची लचीली स्कीमा के लिए, मैं एक्सएमएल से बेहतर विकल्प के बारे में नहीं सोच सकता। आप एक्सएमएल कॉलम इंडेक्स कर सकते हैं।

This article off MSDN एक्सएमएल स्टोरेज पर अधिक विस्तार से चर्चा करता है।

Answer 2

आपके पास 'लचीली' स्टोरेज तंत्र के लिए तीन प्रमुख विकल्प हैं।

• एक्सएमएल फ़ील्ड लचीले हैं लेकिन आपको ब्लॉब स्टोरेज के दायरे में डाल देते हैं, जो क्वेरी में धीमा है। मैंने एक्सपैथ प्रश्नों के साथ ब्लॉब्स से सामान खोदने के दौरान 30,000 पंक्तियों के छोटे डेटा सेट के खिलाफ प्रश्नों को 5 मिनट लगते हैं। यह अब तक का सबसे धीमा विकल्प है लेकिन यह लचीला है।

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

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

Answer 3

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

इस घटना डेटा लगातार इतनी बार सम्मिलित स्ट्रीमिंग हो जाएगा बस के रूप में क्वेरी बार के रूप में महत्वपूर्ण है।

विकल्प 3: तुम सच में लगातार स्ट्रीमिंग डेटा का एक बहुत है -, प्रक्रिया में SQLite, अलग db तालिका, या यहाँ तक कि अपने आप सर्वर साझा स्मृति में एक अलग कतार बना, आने वाले कच्चे घटना स्टोर करने के लिए & विशेषताओं, और एक और प्रक्रिया (निर्धारित कार्य, विंडोज सेवा, आदि) पार्स है जो तेजी से चयन के लिए जो भी पसंदीदा प्रारूप में ट्यून किया गया है। इष्टतम इनपुट, इष्टतम आउटपुट, किसी भी दिशा में स्केल करने के लिए तैयार, हर कोई खुश है।