2012-03-12 19 views
8

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

जानकारी यहाँ है: - http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8004.htm - What is a View in Oracle?

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

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

+0

एक क्वेरी के आधार पर प्रदर्शित डेटा देखें। यह डेटा प्रतिकृति से बचाता है और एक नई तालिका बनाने के बजाय आपकी स्टोरेज स्पेस बचाता है। मुझे लगता है कि प्रदर्शन समस्या के लिए क्वेरी अनुकूलन देखें। – fn27

+0

मुझे लगता है कि आपका मतलब भौतिक दृश्य है, नहीं? – tbone

+0

ओह, अंतर को देखने की ज़रूरत है, मैंने अभी ऑरैकल का उपयोग करना शुरू कर दिया है। मैं केवल सरल दृश्य का उपयोग करता हूं, जैसे 'CREATE VIEW' – fn27

उत्तर

7

एक दृश्य केवल एक संग्रहीत क्वेरी है, इसलिए दृश्य क्वेरी के बीच प्रदर्शन और बेस टेबल के विरुद्ध एक समान क्वेरी जारी करने के बीच प्रदर्शन में कोई अंतर नहीं होना चाहिए।

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

यदि आप एक टेबल बनाने जा रहे हैं, तो मैं आमतौर पर सुझाव देता हूं कि आप materialized view इसके बजाय बनाने के लिए देखें। इसमें तालिका के प्रदर्शन लाभ हैं लेकिन ओरेकल इसे सिंक में रखने का ख्याल रखता है ताकि आपको इसके लिए बहुत से कस्टम कोड लिखने की आवश्यकता न हो।

लेकिन यह बिल्कुल स्पष्ट नहीं है कि डेटा को भौतिक बनाना पहले स्थान पर उचित समाधान है। क्या आप निश्चित हैं कि आप बस कुछ इंडेक्स नहीं खो रहे हैं?

+0

लेकिन भौतिक विचारों को जटिल प्रश्नों पर तेजी से ताज़ा नहीं किया जा सकता है, और यह एक समस्या होगी। अगर वह हर डीएमएल पर एमवी को रीफ्रेश करना चाहता है, तो एमवी का उपयोग करने का क्या फायदा है? –

+0

@AmirPashazadeh - लाभ यह है कि अंतर्निहित डेटा के साथ भौतिक डेटा को सिंक में रखने के लिए आपको कोड का एक गुच्छा लिखना, बनाए रखना और डीबग करना नहीं है। यदि आपके पास एक जटिल क्वेरी है कि ओरेकल एक तेज़ रीफ्रेशेबल भौतिक दृश्य नहीं बना सकता है, तो आपको भौतिक डेटा को लेनदेनपूर्वक संगत रखने के लिए कोड विकसित करने में कठिनाई होगी। –

+1

सहमत हैं, लेकिन मेरा मानना ​​है कि क्वेरी को अनुकूलित करना पहली चीज है, ज्यादातर समय क्वेरी ऑप्टिमाइज़ेशन जवाब है। –

5

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

5

विचार क्वेरी के लिए सिर्फ एक रैपर हैं, दृश्य का उपयोग करने का प्रदर्शन केवल एक क्वेरी का उपयोग करने के प्रदर्शन के समान होता है (यदि आप क्वेरी पार्सिंग ओवरहेड को अनदेखा करते हैं)।

तो एक दृश्य का उपयोग करने से आपकी समस्या में मदद नहीं मिलेगी, अगर आप बहुत सारे जॉइन का उपयोग कर रहे हैं।लेकिन ओरेकल में क्वेरी ऑप्टिमाइज़ेशन में बहुत सारे अनुभव के बाद मैं आपको कुछ नोट्स दे सकता हूं:

  1. जब संभव हो तो शामिल होने के बजाय उप-चयन (अपने चयन खंड के अंदर) का उपयोग करें; वहाँ कुछ मामले ऐसे हैं ऐसा नहीं किया जा सकता है, या यह इस तरह के रूप में है कि क्या करना है, अच्छा नहीं है:
    • जब आप भीतरी मिलती उपयोग कर रहे हैं परिणाम सेट से कुछ रिकॉर्ड निकालने के लिए -
    • आप कुछ शर्तें करना चाहते हैं उस कॉलम पर
    • आप उस कॉलम को सॉर्ट करना चाहते हैं।
  2. union के बजाय union all का उपयोग करें जहां यह किया जा सकता है।
  3. उपयोग coalesce जब यह उचित है, (यहां तक ​​कि उस पर का उपयोग पैरामीटर के रूप में उप-चयन के साथ)
  4. उचित अनुक्रमणिका बनाएँ (अपने निष्पादन योजना के अनुसार)
  5. से बचें अपने में शामिल होने और जहां खंड में संग्रहीत-कार्यों का उपयोग कर ।

ये चीजें हैं जो अब मेरे दिमाग में आईं। उम्मीद है कि यह मदद करेगा।

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