2009-12-31 11 views
5

मेरे डेटाबेस एप्लिकेशन के लिए, अपने कुछ प्रश्नों के लेन-देन के लिए स्नैपशॉट अलगाव को नियोजित करना महत्वपूर्ण आवश्यकताओं में से एक को हल करने के लिए बिल्कुल सही लगता है।एसक्यूएल स्नैपशॉट अलगाव सीमा

मुझे चिंता है, हालांकि, स्नैपशॉट अलगाव का चयन कैसे करें (जो मुझे विश्वास है कि डेटाबेस-व्यापी सक्षम होना चाहिए) अब हम बहुत अधिक मात्रा प्राप्त करने के बाद हमें काट लेंगे। स्नैपशॉट अलगाव की लागत क्या है? क्या यह एक निश्चित लागत, रैखिक, या ज्यामितीय है?

यदि मुझे उच्च मात्रा के बारे में चिंतित होने का अधिकार है, तो स्नैपशॉट अलगाव के समान एप्लिकेशन-स्तरीय कार्यक्षमता के लिए रणनीतियों/पैटर्न हैं जो बेहतर समग्र प्रदर्शन कर सकते हैं, लेकिन लागू करने के लिए अधिक समय/विशेषज्ञता ले सकते हैं?

धन्यवाद,

जेसन

उत्तर

10

किसी भी व्यक्ति के लिए जो लॉकिंग और डेटाबेस कार्यान्वयन पर पहले से ही एक विशेषज्ञ नहीं है, यह आपके दिमाग को लपेटने के लिए एक आश्चर्यजनक मुश्किल विषय हो सकता है।

मैं ह्यूगो कॉर्नेलिस (एसक्यूएल सर्वर एमवीपी) द्वारा इस series of posts on snapshot isolation को पढ़ने की अत्यधिक अनुशंसा करता हूं। स्नैपशॉट्स का उपयोग करते समय अब ​​तक यह सबसे पूरा विश्लेषण है जिसे मैंने व्यावहारिक विचारों के बारे में देखा है।

मुख्य मुद्दों को संक्षेप में प्रस्तुत करने के लिए:

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

आप अपने प्रश्नों को कैसे लिखते हैं, इस पर निर्भर करते हुए, आपको unexpected or inconsistent results के साथ समाप्त करने के लिए ट्रिगर्स का उपयोग करने की आवश्यकता भी नहीं हो सकती है।

मुझे नहीं पता कि लागत निश्चित या रैखिक हैं, हालांकि वे निश्चित रूप से ज्यामितीय नहीं हैं; मुझे पता है कि यह बिना किसी सिरदर्द का थोड़ा सा है। यह अक्सर आग और भूलने के विकल्प के बारे में बात करता है, लेकिन सच्चाई यह है कि, यदि आप नहीं जानते कि आप क्या कर रहे हैं तो आप तोड़ने वाले परिवर्तनों के साथ समाप्त हो सकते हैं (जिनके बारे में आप शायद नहीं पाएंगे जब तक कि बहुत देर हो चुकी हो!)।

यदि आप सुनिश्चित हैं कि इससे कोई अन्य समस्या नहीं आएगी तो हर तरह से इसका उपयोग करें।लेकिन अगर आपके किसी भी तर्क को गंदे पढ़ने के बारे में परवाह नहीं है (और यह कई प्रणालियों में SELECT प्रश्नों के आधे से अधिक पर लागू होता है), तो आपको READ UNCOMMITTED (जिसमें अधिक "विशेषज्ञता" शामिल है) के साथ बेहतर परिणाम मिलेगा - आपको क्या हो सकता है और कब) के बारे में बहुत सावधानी से सोचें।

अद्यतन: अनुप्रयोग स्तर विकल्प

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

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

+0

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

+0

इसके अलावा, क्या ऐप-स्तरीय विकल्प हैं? विभिन्न अलगाव स्तर अलग-अलग परिणाम देते हैं, लेकिन एक ऐप-स्तरीय पैटर्न स्नैपशॉट अक्षम के साथ केवल सीमित समेकित अलगाव का उपयोग करके समान लाभ प्राप्त कर सकता है। या ऐसा घर विकसित प्रयास प्रदर्शन को और भी खराब कर देगा। –

+1

मेरी राय और सीखने में पढ़ा गया अनौपचारिक केवल चरम किनारे के मामलों में उपयोग किया जाना है। यदि आप वास्तव में पढ़ाई के आसपास एक प्रणाली का निर्माण करते हैं तो दुःस्वप्न के साथ मजा आता है, मुझे उम्मीद है कि मेरा व्यक्तिगत डेटा आपके सिस्टम पर नहीं है। इसका उपयोग न करने के कई कारण हैं। यह सिर्फ गंदे पढ़ने के बाहर अप्रत्याशित परिणाम दे सकता है। एकमात्र बार जब मैं इसका उपयोग करता हूं तब होता है जब मेरे पास डेटा का एक बड़ा लेनदेन पंपिंग होता है और मैं इस बात की गहराई से गिनती चाहता हूं कि कितने रिकॉर्ड किए गए हैं। मैं यह विज्ञापन करता हूं। किसी भी SQL सर्वर गुरु से पढ़ें और देखें कि वे इसके बारे में क्या सोचते हैं। – Kuberchaun

1

स्नैपशॉट अलगाव अधिक हो अन्य अलगाव स्तरों की तुलना में performant पढ़ने के लिए होती है। डेटा को स्नैपशॉट में अलग करके, लेनदेन को पंक्तियों पर ताले हासिल करने की आवश्यकता नहीं होती है, जो अवरोध और डेडलॉक्स को रोकता है।

हालांकि, इसे tempdb डेटाबेस में पंक्ति संस्करण जानकारी लिखनी है। तो प्रत्येक लेनदेन के लिए, कुछ लिखने के समय की उम्मीद की जानी चाहिए।

बस बाकी सब कुछ की तरह, आपकी परिस्थितियां यह निर्देश देगी कि यह आपके लिए कम या ज्यादा प्रदर्शनकारी होगा या नहीं। यदि आपका आवेदन OLTP शैली है, तो यदि आपके लेन-देन डेडलॉकिंग के लिए प्रवण होते हैं तो यह प्रदर्शन में बड़ी वृद्धि हो सकती है।

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