2009-04-03 14 views
7

हमारे डेटाबेस आर्किटेक्चर में दो SQL सर्वर 2005 सर्वर होते हैं जिनमें प्रत्येक डेटाबेस संरचना का उदाहरण होता है: सभी पढ़ने के लिए, और सभी लिखने के लिए एक। हम रीडिंग डेटाबेस को अद्यतित रखने के लिए लेनदेन संबंधी प्रतिकृति का उपयोग करते हैं।लेनदेन संबंधी प्रतिकृति के साथ उप-1-सेकंड विलंबता प्राप्त करना संभव है?

दो सर्वर वास्तव में बहुत उच्च-स्पीक हैं (लिखने वाले सर्वर में 32 जीबी रैम है), और एक फाइबर नेटवर्क के माध्यम से जुड़े हुए हैं।

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

1 सेकंड से नीचे विलंबता प्राप्त करने के लिए हमें किन कारकों को देखना चाहिए? क्या यह भी प्राप्त करने योग्य है?

वैकल्पिक रूप से, क्या प्रतिकृति का एक अलग तरीका है जिसे हमें विचार करना चाहिए? डेटा और लॉग फ़ाइलों के स्थानों के लिए सबसे अच्छा अभ्यास क्या है?

संपादित

सलाह और अंतर्दृष्टि के लिए सभी को धन्यवाद - मुझे विश्वास है कि विलंबता अवधि हम का सामना कर रहे हैं सामान्य; हम हमारी डीबी होस्टिंग कंपनी द्वारा गलत तरीके से नेतृत्व कर रहे थे कि किस विलंबता की अपेक्षा की जा सकती है!

हम तकनीक (शीर्षक "स्केलिंग डेटाबेस" के अंतर्गत) this MSDN article के तल के पास वर्णित का उपयोग कर रहे हैं, और हम इस चेतावनी के साथ ठीक से निपटने में विफल रहा है था:

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

अब हम अपने कैशिंग तंत्र में बदलाव को लागू करने की सोच रहे हैं जो डेटा के किसी आइटम को "अस्थिर" माना जाता है जब लेखन डेटाबेस से पढ़ता है।

उत्तर

2

नहीं। यह बेहद असंभव है कि आप उप-1s विलंबता समय को SQL सर्वर लेनदेन प्रतिकृति के साथ तेज हार्डवेयर के साथ भी प्राप्त कर सकते हैं।

यदि आप 1-5 सेकंड विलंबता प्राप्त कर सकते हैं तो आप अच्छी तरह से कर रहे हैं।

here से:

व्यवहार प्रतिकृति का उपयोग करना, यह संभव है एक सब्सक्राइबर प्रकाशक के पीछे कुछ सेकंड होने के लिए। केवल कुछ सेकंड की विलंबता के साथ, सब्सक्राइबर आसानी से रिपोर्टिंग सर्वर के रूप में उपयोग किया जा सकता है, महंगा उपयोगकर्ता क्वेरी और सब्सक्राइबर के प्रकाशक से रिपोर्टिंग ऑफलोडिंग।

इस परिदृश्य पर सब्सक्राइबर प्रकाशक के पीछे केवल चार सेकंड था ( उपभोक्ता ने इस अनुभाग में बाद में पता चला तालिका का उपयोग कर) में

। यहां तक ​​कि अधिक प्रभावशाली, का 60 प्रतिशत समय में दो सेकंड या उससे कम की विलंबता थी। से जब रिकॉर्ड रिकॉर्ड किया गया था या प्रकाशक पर अपडेट किया गया था तब तक वास्तव में डेटाबेस सदस्यता लेने के लिए लिखा गया था।

+0

हाँ, मैं भी उस लेख को पढ़ूंगा :( –

1

मैं कहूंगा कि यह निश्चित रूप से संभव है।

मैं कम से दिखेगा:

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

अनिवार्य रूप से आपके पास एक जटिल प्रणाली है जिसमें आपको कोई समस्या है, आपको यह निर्धारित करने की आवश्यकता है कि कौन सा घटक समस्या है और इसे ठीक करें।

ट्रांज़ेक्शनल प्रतिकृति शायद सबसे अच्छा है यदि रिपोर्ट/चयन को चलाने की आवश्यकता है, तो अद्यतित होने की आवश्यकता है। यदि वे लॉग शिपिंग को नहीं देख पा रहे हैं, हालांकि यह प्रत्येक आयात के साथ कुछ समय कम करेगा।

डेटा/लॉग फ़ाइलों के लिए, सुनिश्चित करें कि वे अलग ड्राइव पर हैं ताकि प्रदर्शन अधिकतम हो।

+0

सलाह के लिए धन्यवाद, हालांकि पिंग्स ठीक हैं (<1ms), नेटवर्क यातायात बहुत कम है, और मैं अपने परीक्षण में एक तालिका में एक बहुत ही सरल अपडेट करने की कोशिश कर रहा हूं। –

+0

ठीक है, तो शायद नेटवर्क नहीं। क्या आप अपना अपडेट करते समय चयन कर रहे हैं? यह एक लॉकिंग मुद्दा होने की अधिक संभावना है। – Bravax

+0

@ अनुत्तरित 3 अप्रैल 8:38 ब्रेवैक्स: क्या आप एक ऐसे लेख को उद्धृत कर सकते हैं जो लेन-देन प्रतिकृति के लिए उप-1 दूसरी विलंबता का descibes? –

1

लेनदेन प्रतिकृति के बारे में कुछ याद रखना यह है कि एक ही अपडेट के लिए अब उस बदलाव के लिए कई परिचालनों की आवश्यकता होती है।

सबसे पहले आप स्रोत तालिका को अपडेट करते हैं। अगला लॉग पाठक परिवर्तन को देखता है और वितरण डेटाबेस में परिवर्तन लिखता है। अगला वितरण एजेंट वितरण डेटाबेस में नई प्रविष्टि को देखता है और उस परिवर्तन को पढ़ता है, फिर पंक्ति को अद्यतन करने के लिए ग्राहक पर सही संग्रहीत प्रक्रिया चलाता है।

यदि आप दो सर्वरों पर चलने वाले वक्तव्य की निगरानी करते हैं तो आप शायद देखेंगे कि वे केवल कुछ मिलीसेकंड में चल रहे हैं। हालांकि लॉग रीडर और वितरण एजेंट की प्रतीक्षा करते समय यह अंतराल का समय है कि उन्हें यह देखने की ज़रूरत है कि उन्हें कुछ ऐसा करने की ज़रूरत है जो आपको मारने जा रहा है।

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

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

  • कोई संबंधित समस्या नहीं^_^