"प्रति नोड 20,000 20,000 अच्छे प्रदर्शन के साथ 5 एमएस विलंबता है।" OLTP के लिए - नहीं

इस लेख को लिखने का कारण यह था कि हमने VMware vSAN ... CROC का परीक्षण कैसे किया । समीक्षा योग्य है, लेकिन इसमें एक मुहावरा है कि मैं एक दशक से अधिक समय से संघर्ष कर रहा हूं। भंडारण प्रशासक, वर्चुअलाइज़र और इंटीग्रेटर बार-बार दोहराते हैं: "5 एमएस के विलंब एक उत्कृष्ट संकेतक हैं।" यहां तक ​​कि दस साल के लिए 5 एमएस का आंकड़ा भी नहीं बदलता है। मैंने इस सम्मान को एक दर्जन से कम समय में बहुत सम्मानित प्रशंसा से लाइव सुना। कम सम्मानित से - दर्जनों, और कितनी बार मैंने इंटरनेट पर पढ़ा ... नहीं, नहीं, नहीं। 5 एमएस के ओएलटीपी भार के लिए, विशेष रूप से जब वे आमतौर पर मापा जाता है, तो ये महाकाव्य विफल होते हैं। मुझे कई बार इसके कारणों की व्याख्या करनी पड़ी, इस बार मैंने अपने विचारों को पुन: प्रयोज्य रूप में एकत्र करने का निर्णय लिया।

मुझे तुरंत कहना होगा कि उपरोक्त लेख में ऐसी कोई त्रुटियां नहीं हैं, बल्कि वाक्यांश ने ट्रिगर के रूप में काम किया है।

विशिष्ट शुरुआत

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

प्रदर्शन DBMS आमतौर पर हर किसी से नाखुश है। यदि एक बड़ी प्रणाली में एक DBMS है - और यह अचानक लगभग हमेशा होता है - तो यह DBMS एक अड़चन है। ठीक है, या यह तुरंत एक अड़चन बन जाएगा यदि आप बाकी सब कुछ का अनुकूलन शुरू करते हैं। और इसलिए, ग्राहक आता है और एक मानवीय आवाज़ में कहता है: "हेल्प! सेव! उन्होंने सर्वर और स्टोरेज के लिए $ NNNNNNNN का भुगतान किया, लेकिन गति में वृद्धि नहीं हुई! ओह, और प्रशासक ने सेट अप किया और विक्रेता ने सलाह दी, लेकिन फिर भी नहीं हिला।" यदि सिस्टम के डेवलपर्स लावरोव की परिभाषा फिट करते हैं (हम एक सटीक उद्धरण के बिना कर सकते हैं), और ऑपरेशन और रखरखाव विशेषज्ञ "सर्वर को रिबूट करके घटनाओं के साथ संघर्ष", तो समस्या अक्सर सरल और स्पष्ट है: कोई अनुक्रमित, कुटिल प्रश्न, घातक कॉन्फ़िगरेशन त्रुटियां नहीं हैं (जिसके बारे में दस्तावेज बोल्ड है यह कहता है "आप ऐसा नहीं कर सकते !!!" ), अत्यधिक ताले, गतिरोध और अन्य सरल और स्पष्ट बकवास। ऐसे कई मामले हैं, अधिकांश, लेकिन सभी नहीं। यदि प्रणाली, जटिलता या भार में, कुछ अदृश्य सीमा पार कर गई है, तो यह या तो इन समस्याओं से मर जाएगी या अगले स्तर तक जाएगी।

इस स्तर पर, सर्वर अब निदेशक की तालिका के अंतर्गत नहीं है, डिस्क अब सर्वर के अंदर नहीं हैं, लेकिन भंडारण प्रणाली में, डेवलपर्स इंडेक्स के बारे में जानते हैं, और व्यवस्थापक पहले से ही PowerShell को जानते हैं, और आईटी प्रबंधक SLA और RPO / RTO जैसे स्मार्ट शब्द कहना शुरू करते हैं। इस स्तर पर एक दिलचस्प स्थिति उत्पन्न होती है:

• DBMS एक अड़चन है।
• सर्वर सभी मामलों में पर्याप्त लगता है।
• DBMS को प्रोग्रामेटिक रूप से और बेहतर बनाया जा सकता है, लेकिन यह मुश्किल है (या तो अधिक महंगे लाइसेंस पर स्विच करें या ऑप्टिमाइज़ेशन के लिए "शिपिलेव वक्र के रेड ज़ोन" पर स्विच करें)
• डिस्क सिस्टम महंगा खरीदा गया है और, ऐसा लगता है, यहां तक ​​कि किसी भी तरह कॉन्फ़िगर किया गया है।

लेकिन नहीं। मगरमच्छ पकड़ा नहीं जाता है, नारियल नहीं बढ़ता है, और सिस्टम का प्रदर्शन पुराने सर्वर पर समान या कम है। मैं PAGEIOLATCH_EX में PAGEIOLATCH_EX PAGEIOLATCH_SH और शीर्ष में WRITELOG , PAGEIOLATCH_SH और PAGEIOLATCH_EX देखता WRITELOG , औसत प्रतीक्षा समय 5+ एमएस है। ठीक है, ठेठ, चुनें: "अरे, प्रवेश और डीबीए, यहां आपके पास एक डिस्क सिस्टम - अड़चन है" और यहां 5 एमएस के बारे में एक पुराना गीत शुरू होता है:

• हम SLA के लिए 5 एमएस है
• हां, हमारे पास 20,000 IOPS की रेजिमेंट है
• विक्रेता ने हमें बताया कि सभी डेटाबेस फाइलें एक विभाजन पर हो सकती हैं
• हमारे पास वर्चुअलाइजेशन और हाइपरकंवरेज है और हम डेटाबेस के तहत अलग-अलग डिस्क आवंटित नहीं कर सकते
• हमारे डेटा के अनुसार, सर्वर का उपयोग 5%
• सब कुछ सिफारिशों के अनुसार कॉन्फ़िगर किया गया है
• आपके डेटाबेस को अधिक प्रदर्शन की आवश्यकता नहीं है, यह 300 से अधिक IOPS नहीं करता है (और हमारे पास 20,000 IOPS के लिए एक शेल्फ है)

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

तो यहाँ है। "5 एमएस" के बारे में यह पूरा गीत बकवास और बकवास है। यदि आप स्वयं यह कहते हैं, तो इस लेख को पढ़ें। और अगर वे आपसे ऐसा कहते हैं, तो तर्क तैयार करें। इससे पहले, जब मैंने ये शब्द सुने, तो मैं क्रोधित था, लेकिन मैं अब क्रोधित नहीं हूं। मैं, हिचहाइकर गाइड से गैलेक्सी के लिए एक पेटुनीया के साथ उस पॉट को पसंद करता हूं, केवल एक ही विचार है: "ठीक है, फिर से ..."।

किसे दोष देना है?

डेटाबेस इतना धीमा क्यों है? ठीक है, ऐसा लगता है कि 2-3 गीगाहर्ट्ज की आवृत्ति पर 20-64 कोर के साथ एक विशिष्ट सर्वर 50-150 बिलियन सरल ऑपरेशन करने में सक्षम है, और अधिकतम (सिंथेटिक) डेटाबेस परीक्षण ऐसी मशीनों पर प्रति सेकंड 10,000-50000 लेनदेन दिखाते हैं। अरे! खैर यह एक लाख से एक दर्जन संभावित लाखों प्रति लेनदेन है। यह केवल बहुत कुछ नहीं है, यह बहुत मायने रखता है।
इस तरह के एक ओवरहेड लागत लेनदेन के लिए ACID- आवश्यकताओं।

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

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

वाल क्या है?

चलो आधुनिक एसएसडी के बारे में एक पल के लिए भूल जाते हैं, शांत भंडारण प्रणालियों के बारे में। मान लीजिए हमारे पास एक सर्वर है, इसमें एक या अधिक डिस्क हैं।
किसी भी लेनदेन, यहां तक ​​कि एक रिकॉर्ड का सम्मिलन, कम से कम संभावित है, लेकिन वास्तव में लगभग हमेशा और वास्तविक रूप से एक गैर-परमाणु कार्रवाई। हमें लगभग हमेशा न केवल उस पृष्ठ को बदलने की जरूरत है जहां रिकॉर्ड स्थित है, बल्कि सूचकांक पृष्ठ, संभवतः सेवा पृष्ठ भी हैं। इसके अलावा, एक ही लेनदेन में एक ही पृष्ठ कई बार बदल सकता है। साथ ही, अन्य लेनदेन हमारे साथ समानांतर में किए जा सकते हैं। इसके अलावा - समय में पड़ोसी पड़ोसी लगातार उसी पृष्ठों को "खींच" करते हैं। यदि हम जारी रखने से पहले डिस्क के लिखे जाने के लिए प्रत्येक पृष्ठ की प्रतीक्षा करते हैं, जो अनिवार्य रूप से स्थायित्व की आवश्यकता है, तो हमें कई गुना अधिक लिखना होगा और प्रत्येक रिकॉर्डिंग को गैर-वाष्पशील मीडिया पर पूरा होने की प्रतीक्षा करनी होगी। कोई कैश नहीं, कतार में संचालन की कोई व्यवस्था नहीं, अन्यथा कोई अखंडता नहीं होगी! इसके अलावा, हमें किसी तरह यह नोट करने की जरूरत है कि कौन सा डेटा पहले से तय लेनदेन पर है और जो अभी तक नहीं है (और कौन सा डेटा पहले था)। समझने के लिए - इस मोड में एक विशिष्ट एकल हार्ड डिस्क (HDD) 50-100 IOPS देगा और यह 20 वर्षों से निरंतर है। एक छोटे से लेन-देन के लिए 5-10 लिखने के संचालन की आवश्यकता होगी। आह, हाँ, यह जानने के लिए कि क्या रिकॉर्ड करना है, आपको इसे अवश्य पढ़ना चाहिए। यहां तक ​​कि बहुत, बहुत भारी लिखने योग्य ओएलटीपी सिस्टम लिखने से 3 गुना अधिक पढ़ते हैं। इस प्रकार, हमारे लेनदेन की लागत 20-40 IO है, जिसका अर्थ है प्रति डिस्क 0.2-0.8 सेकंड।
2 लेनदेन प्रति सेकंड। पर्याप्त नहीं है? चलो डिस्क को तितर बितर करने की कोशिश करते हैं? ओह, लेकिन हमें अभी भी पिछले एक रिकॉर्ड होने तक इंतजार करने की जरूरत है और अंत में कोई समानता नहीं है। कैसे हो? और एक लॉग फ़ाइल शुरू करते हैं जिसमें हम क्रमिक रूप से डेटाबेस और लेनदेन के निशान में सभी लिखने के संचालन को रिकॉर्ड करेंगे! पेशेवरों:

• ऑपरेशन के बारे में जानकारी पूरे पृष्ठ को रिकॉर्ड करने की तुलना में बहुत अधिक कॉम्पैक्ट हो सकती है (एक विशिष्ट पृष्ठ का आकार 8 KiB है, लॉग को लिखित जानकारी अक्सर 0.5-1 KiB होती है)।
• लेन-देन रिकॉर्ड किए जाने या सीधे पेज पर नहीं होने के बारे में लिखने के बजाय, लॉग में लेनदेन की शुरुआत और फिक्सिंग के बारे में पर्याप्त लेबल हैं।
• प्रत्येक लेनदेन के बाद पृष्ठ नहीं लिखे जा सकते हैं - कई बार कम। डेटा पढ़ने / लिखने की प्रक्रिया लॉग से पूरी तरह से "अनटाइड" है।
• मुख्य बात है। यदि हम अपनी पत्रिका को एक अलग डिस्क पर रखते हैं और रिकॉर्ड को क्रमिक रूप से लिखते हैं, तो इस तथ्य के कारण कि आपको डिस्क प्रमुखों को लगातार निरस्त करने की आवश्यकता नहीं है, यहां तक ​​कि इस मोड में एक घरेलू एचडीडी 1000 IOPS तक निचोड़ता है, यह देखते हुए कि छोटे लेनदेन की लागत 2-4 जर्नल प्रविष्टियां हैं, तब आप 200-400 TPS निचोड़ सकते हैं
• विफलता की स्थिति में, डेटा फ़ाइल की स्थिति को इस तरह के लॉग से बहाल किया जा सकता है, और यदि लेनदेन को रद्द कर दिया जाता है, तो इसे वापस लाया जा सकता है।

ऐसे लॉग को राइट-फॉरवर्ड लॉग / ट्रांजेक्शन लॉग / REDO लॉग कहा जाता है।

हुर्रे! सुपर! प्रति सेकंड 2 लेनदेन थे, यह 300 हो गया - 150 बार सुधार हुआ। और किस कीमत पर? जैसा कि यह पता चला है, कीमत महत्वपूर्ण है:

• सभी सामान्य DBMS में, लॉगिंग सख्ती से सुसंगत है। लॉग को लिखने के लिए एक धागा जिम्मेदार है। क्या आपके पास 100 प्रोसेसर हैं? कूल। और लॉग अभी भी एक धागा लिखेगा। कतार की गहराई बिल्कुल एक है।
• फिर भी - कोई ओएस कैश नहीं, कोई संचालन क्रमपरिवर्तन नहीं। स्थायित्व की आवश्यकताएं बनी रहीं। राइट-थ्रू ऑपरेशन: जब तक डिस्क ने उत्तर नहीं दिया "मैंने लिखा है, मैंने इसे सतह पर सही लिखा है, कैश के लिए नहीं, निश्चित रूप से" डीबीएमएस काम करना जारी नहीं रखता है।
• यदि आप लॉग फ़ाइल को डेटा डिस्क पर रखते हैं, तो अनुक्रमिक रिकॉर्डिंग के लगभग सभी लाभ खो जाएंगे। इसके अलावा - अच्छे के लिए, यदि सर्वर पर कई डेटाबेस हैं, तो पत्रिकाओं के लिए कई डिस्क हैं।
• लेन-देन रोलबैक (कम से कम एमएस SQL ​​सर्वर में) - लॉग को पढ़ें और राज्य को इससे पुनर्स्थापित करें। यह उतने ही या इससे भी अधिक के संचालन के रूप में है क्योंकि लेनदेन में लेखन संचालन थे। रोलबैक महंगा है!

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

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

वाल और एस एच डी

"जन्म से" भंडारण निर्माता DBMS के साथ सामना कर रहे हैं। यह उन डेटाबेसों के लिए है जो व्यापार इन बेतहाशा महंगे परिसरों को खरीदता है: डेल-ईएमसी, एचपी, हिताची, नेटऐप के स्ट्रीट प्राइस स्टोरेज से, जब एक बजट लगाते हैं, तो आँखें अधिकांश शीर्ष प्रबंधकों के लिए आँसू भरती हैं, जब तक कि निश्चित रूप से, उन्हें इस कीमत का एक प्रतिशत नहीं मिलता है। लेकिन एक इंजीनियरिंग और विपणन संघर्ष है। मैं इसे एक उदाहरण के रूप में डेल-ईएमसी का उपयोग करके समझाता हूं, लेकिन केवल इसलिए कि मुझे याद है कि उनके पास दस्तावेज कहां हैं।

तो:

1. सिंगल थ्रेडेड जर्नल
2. सीपीयू प्रदर्शन की तुलना में राइट-थ्रू लॉग, यानी विलंबता, "शाश्वत" है
3. OLTP लोड अपेक्षाकृत छोटे लेन-देन के बहुत सारे हैं,
4. अधिकांश अन्य DBMS लोड एक तरह से या किसी अन्य के समानांतर होते हैं।

Amdahl का नियम निर्दयता से हमें बताता है कि एकल-थ्रेड वाला कम-प्रदर्शन लोड प्रोसेसर को बेकार बना देगा, और प्रदर्शन लॉग द्वारा निर्धारित किया जाएगा। इसके अलावा, इस समय हम IOPS में भंडारण के प्रदर्शन के बारे में कोई ध्यान नहीं देंगे, और केवल विलंबता महत्वपूर्ण हो जाएगी।
लेकिन अन्य डिस्क संचालन को छूट न दें - डेटा फ़ाइलों और tempdb को पढ़ना और लिखना। पढ़ना भी एक "प्रतीक्षा" ऑपरेशन है। जब तक किसी डेटा पेज को डिस्क से मेमोरी में नहीं पढ़ा जाता है, प्रोसेसर इसे प्रोसेस नहीं कर सकता है। लेकिन इन कार्यों के लिए, इस कतार में बड़ी कतारें और संचालन की अनुमति संभव है: DBMS अक्सर जानता है कि कौन से पृष्ठों को मेमोरी में लोड करना है, कौन से पृष्ठ डंप करना है और एक बार में पढ़ने के लिए बहुत सारी कतारें लगाती हैं। चूंकि इस परिदृश्य में यह महत्वपूर्ण है जब बंडल से अंतिम ऑपरेशन समाप्त होता है, इस लोड में, इसके विपरीत, IOPS हमारे लिए एक एकल ऑपरेशन की विलंबता से अधिक महत्वपूर्ण है। स्कोप को समझने के लिए: ओएलटीपी सिस्टम में रीड ऑपरेशंस 85% -95% हैं। हां, हां, हां, लिखना संचालन कम परिमाण का एक आदेश है।

विक्रेता स्टोरेज इंजीनियर DBMS विक्रेताओं के साथ मिलकर काम कर रहे हैं, और सभी तकनीकी बारीकियों के बारे में अच्छी तरह से जानते हैं कि DBMS डिस्क सबसिस्टम के साथ कैसे काम करता है। DBMS के लिए डिस्क संसाधनों की उचित योजना, विभाजन और आवंटन , भंडारण प्रणाली के प्रशासक की एक जटिल और महत्वपूर्ण क्षमता है । एक ही डेल-ईएमसी में भी एक सौ से अधिक पृष्ठों पर SQL सर्वर के लिए विभाजन की सिफारिशों के लिए बुनियादी श्वेत पत्र H14621 और H12341 है । अरे! यह एक विस्तृत गोदी नहीं है, यह सबसे आम सफेद कागज है! अभी भी विशिष्ट लोगों का एक समूह है ( h15142 , h16389 ... वहां अंधेरा है)। VMware के "सन्निकट" - VMware vSphere पर Microsoft SQL सर्वर आर्किटेक्चर बहुत पीछे नहीं हैं। कृपया ध्यान दें कि ये दस्तावेज केवल डीबीए के लिए नहीं हैं और न ही बुनियादी ढांचे और भंडारण प्रशासकों के लिए।
मैं यह भी ध्यान देता हूं कि इन सभी दस्तावेजों में अलग-अलग LUN को डेटा के लिए, लॉग के लिए और tempdb लिए काटा जाता है। हां, कहीं-कहीं नवीनतम दस्तावेजों में वे बड़े करीने से कहते हैं कि ऑल-फ्लैश समाधान के लिए यह लॉग को शारीरिक रूप से अलग मीडिया में अलग करने का कोई मतलब नहीं है, लेकिन LUN अभी भी उन्हें अलग से काटने की पेशकश करते हैं। यदि आप डेटा को डंप करते हैं और एक LUN में प्रवेश करते हैं, तो OS के दृष्टिकोण से यह एक IO कतार होगी। और एक समस्या होगी। विलंबता संचालन में तुरंत परिमाण का क्रम अधिक होगा। और इस तथ्य के कारण कि गैर-स्थानांतरित करने योग्य लॉग ऑपरेशंस कतार में दिखाई देंगे, IOPS डेटा फ़ाइलों और tempdb पर फिसल जाएगा। यह "शताब्दी की खोज" नहीं है, यह डेटाबेस के साथ काम करने का एक प्राथमिक सत्य है। यह ऑल-फ्लैश के आगमन के साथ पुराना या रद्द नहीं हुआ है। हां, एसएसडी के साथ संचालन में देरी HDDs के साथ संचालन की तुलना में तेजी से परिमाण का एक क्रम है, लेकिन फिर भी स्मृति के साथ संचालन की तुलना में परिमाण के आदेशों के एक जोड़े। IO अभी भी DBMS की अड़चन है।
और तकनीकी दस्तावेज सही ढंग से जोर देते हैं कि लेन-देन लॉग में IOPS की संख्या महत्वपूर्ण नहीं है, लेकिन यह महत्वपूर्ण है कि विलंबता न्यूनतम है (आधुनिक समय में यह लिखा है कि 1 एमएस से कम)।

लेकिन मार्केटर्स को बेचने की जरूरत है। Giperkonvergentnost! वर्चुअलाइजेशन! परिनियोजन लचीलापन! डिडुप्लीकेशन! आसान सेटअप! कई, कई IOPS! सुंदर प्रस्तुतियाँ, आत्मविश्वास भरी आवाज, औपचारिक वेशभूषा। लेकिन डॉलर में 6-7 अंकों के मूल्य टैग के साथ समाधान कैसे बेचना है? इसके लिए, यह किसी तरह से भुला दिया जाता है कि या तो विलंबता या थ्रूपुट को स्टोरेज सिस्टम से प्राप्त किया जा सकता है, लेकिन दोनों एक साथ नहीं, कि लोड बैलेंसर के लिए किसी प्रकार का लाइसेंस दूसरे शेल्फ की तरह है, कि यदि गहन रिकॉर्डिंग एक घंटे से अधिक समय तक रहती है, तो नियंत्रकों की रैम यह पर्याप्त नहीं है और उत्पादकता "के रूप में अगर कोई कैश नहीं है" नीचे चला जाएगा, कि ग्राहक के कर्मचारियों को प्रशिक्षित करने के लिए पहले वर्ष के लिए एक और 100,000 रूबल का खर्च आता है, ठीक है, इस तरह के ट्रिक्स ...

५ मि

या तो पढ़े लिखे बाज़ारियों से, या आलस से, या किसी तरह के कॉकरोच के कारण बहुत सुना है, लेकिन किसी कारण से अक्सर स्टोरेज एडमिनिस्ट्रेटर ऐसा कुछ करते हैं। हम एक बड़ी शेल्फ लेते हैं, इसे सभी कुछ समतल में जोड़ते हैं, इसे पतले प्रोविज़न वाले LUN में काटते हैं और LUN द्वारा सर्वर में वितरित करते हैं। या दो, क्योंकि "सिस्टम विभाजन अच्छी तरह से काट दिया गया है।" और जब, मैं देखता हूं कि SQL नर्क-नर्क-नरक की तरफ से डिस्क सबसिस्टम के साथ, तो बहुत ही गीत शुरू होता है कि "5 एमएस एक उत्कृष्ट संकेतक है", कि "100000 IOPS", "आपका भंडारण भार 5% से कम है"

सं ।

• 5 एमएस के वाल / लेन-देन लॉग के साथ एक विभाजन पर ओएलटीपी सिस्टम के लिए, यह एक अमान्य संकेतक है। 1000 (शब्दों में: एक हजार) गुना सस्ता होने के लिए लोहे के "लगभग-कमोडिटी" टुकड़े पर, सामान्य संकेतक अब 0.1-0.3 एमएस होगा। और कल - 0.01 एमएस। मॉस्को में अपार्टमेंट के एक पूरे प्रवेश द्वार की कीमत पर, 2008 के एचडीडी की तरह गति की आवश्यकता नहीं है। कोई "सेवाक्षमता" इसके लायक नहीं है।
• क्या विक्रेता लिखते हैं कि लेन-देन लॉग IOPS पर मांग नहीं कर रहे हैं और क्या उन्हें HDD पर रखा जा सकता है? हाँ यह है लेकिन इसके लिए यह आवश्यक है कि इनमें से कोई भी डिस्क न हो संक्रमण लॉग लिखने के अलावा, डीबीएमएस ने कार्य को नहीं छुआ। और इसलिए कि भंडारण प्रणाली उस सर्वर के प्रति प्रतिक्रिया करती है जो डेटा लिखा जाता है, जैसे ही डेटा गैर-वाष्पशील मेमोरी में चला गया (यह उनके लिखे जाने की तुलना में बहुत पहले है)
• असली OLTP डेटाबेस के लिए पतले डिस्क बुराई हैं।
• वाल के लिए, यह पूरी तरह से निर्बाध है कि 10 या 20 की कतार में IOPS को कितनी गहराई से निचोड़ा जा सकता है। वहां कोई गहराई नहीं है।
• वाल के लिए, यह पूरी तरह से एक संकेतक नहीं है कि ओएस में आईओ कतार "केवल लगभग 1" है। वह अब और नहीं होगी।
• नहीं, DBA और DB डेवलपर्स "क्रैंक किए गए कठफोड़वा नहीं हैं, जो ठीक से वाल समानांतर लिखने के लिए कॉन्फ़िगर नहीं कर सकते हैं" (व्यवस्थापक की वास्तविक राय)
• प्रशंसकों के तर्क पर विचार करने के लिए रीसाइक्लिंग "आपके सिस्टम के बाद से हम एक विभाजन में कुटिल रूप से कॉन्फ़िगर किए गए 10,000 IOPS नहीं करते हैं, तो इसे उच्च-अंत सरणी से मध्य-श्रेणी में ले जाना चाहिए" - यह गलत तर्क है।
• यदि 40-कोर सर्वर में 2.5 प्रतिशत का प्रोसेसर लोड होता है, तो इसका मतलब यह नहीं है कि इसका कोई लेना-देना नहीं है, लेकिन, सबसे अधिक संभावना है, इसका मतलब है कि किसी प्रकार का कार्य बाकी सभी को अवरुद्ध करता है।

जब डेवलपर के लैपटॉप पर कुछ डेटा लोडिंग में 5 मिनट का समय लगता है, और 40 वें न्यूक्लियर सर्वर पर 1 TiB RAM और स्टोरेज के लिए आधा मिलियन डॉलर एक ही कार्य एक घंटे के लिए किया जाता है, यहां तक ​​कि अधिकांश रोगी ग्राहकों की लागतों की व्यवहार्यता के बारे में प्रश्न होंगे।

क्या करें?

व्यवस्थापक युक्तियाँ और DBAs

OLTP के लिए, "रीसाइक्लिंग" और IOPS की गिनती करना बंद करें। अलग से, मैं ध्यान देता हूं - IOPS को बड़ी कतार की गहराई के साथ बिल्कुल न देखें: यहां तक ​​कि डेटा विभाजन पर, बड़ी कतार में आमतौर पर एक छोटी फट या ऐसा कुछ होता है जो OLTP के वास्तविक प्रदर्शन को प्रभावित नहीं करता है।

LUN द्वारा डिस्क स्थान साझा करना एक DBA व्हिम नहीं है। डेटाबेस में कई अलग-अलग डिस्क सबसिस्टम लोड प्रोफाइल हैं। कम से कम, निम्नलिखित को प्रतिष्ठित किया जा सकता है:

• डेटा फ़ाइलों के साथ काम करें। आमतौर पर यह 8/64 KiB के यादृच्छिक ब्लॉक के साथ पढ़ और लिख रहा है। 80-95% रीडिंग। कतारें उत्पन्न होती हैं: सेवा की अवधि के दौरान, थोक लोडिंग की अवधि के दौरान, अक्षम या बड़े पैमाने पर अनुरोधों पर, और चेकपॉइंट के दौरान। पढ़ने के प्रति जवाबदेही से प्रदर्शन प्रभावित होता है। यह महत्वपूर्ण है कि 8/64 KiB ब्लॉक "के माध्यम से" के संरेखण पूरे भंडारण प्रणाली से गुजरता है।
• टेम्पर्डब के साथ काम करना डेटा फ़ाइलों के साथ काम करने के समान है, लेकिन रीडिंग आमतौर पर 40-75% होती है और लेखन जवाबदेही महत्वपूर्ण हो सकती है। आधुनिक MS SQL सिस्टम में, इस डेटाबेस को डेटा डेटाबेस की तुलना में कई गुना मजबूत लोड किया जा सकता है। गैर-संकुल DBMS कॉन्फ़िगरेशन में, इस खंड को किसी भी संग्रहण प्रतिकृति से बाहर रखा जाना चाहिए। सेवा को रिबूट करने के बाद इसकी सामग्री अभी भी नष्ट हो जाएगी।
• संग्रहीत डेटा / DWH के साथ काम करें। रीडिंग 100% के करीब है। एक रीडिंग ब्लॉक का आकार आमतौर पर 64 KiB होता है। अनुरोधों को बहुत अधिक और एक पंक्ति में पढ़ा जाता है, इसलिए कतार 1000 या अधिक तक कूद सकती है।
• लेन-देन लॉग के साथ काम करें। पढ़ना केवल रखरखाव (बैकअप, प्रतिकृति, आदि) के लिए है, आवेदन प्रदर्शन केवल लेखन से प्रभावित होता है। 0.5-64 KiB के ब्लॉक में रिकॉर्डिंग। बिना कतार के, एक धागे में। विलंब अनुप्रयोगों के लिए महत्वपूर्ण है।
• बैकअप और बहाल। डेटाबेस के दृष्टिकोण से बड़े ब्लॉक (अक्सर 1 MiB) में पढ़ रहा है। यह महत्वपूर्ण है कि यह लोड कुछ मामलों में चैनल / बसों (FC और ईथरनेट दोनों) और स्टोरेज प्रोसेसर के प्रदर्शन पर आराम कर सकता है। एक सर्वर का बैकअप लेना उसी SAN / SHD के अन्य सर्वरों के प्रदर्शन को प्रभावित कर सकता है।
• एप्लिकेशन फाइलों के साथ काम करें: ये लॉग्स, डिफॉल्ट ट्रेस, बाइनरी फाइलें आदि हैं। यह लोड शायद ही कभी महत्वपूर्ण है और केवल सिस्टम की शुरुआत में महत्वपूर्ण है।

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

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . यह सही है। . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

वह सब है। . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .