नया Azure SQL डेटाबेस मानक स्तरीय आकार

Azure SQL डेटाबेस में वर्तमान में आपके कार्यभार के लिए चुनने के लिए तीन सेवा स्तर हैं। इन स्तरों में बेसिक, स्टैंडर्ड और प्रीमियम शामिल हैं। बेसिक 5 डीटीयू के केवल एक आकार का समर्थन करता है। प्रीमियम 125 डीटीयू से शुरू होता है और 4,000 डीटीयू तक जाता है। प्रीमियम टियर शीर्ष स्तर है जो उच्च I/O वर्कलोड के लिए बनाया गया है और मानक स्तर की तुलना में प्रति I/O कम विलंबता प्रदान करता है, और परिमाण का एक आदेश प्रति DTU अधिक IOPS प्रदान करता है।

अगस्त 2017 से पहले, मानक स्तर केवल 15 और 100 डीटीयू के बीच डीटीयू आकार का समर्थन करता था। वर्तमान में पूर्वावलोकन में उपलब्ध नए प्रदर्शन स्तर और स्टोरेज ऐड-ऑन हैं जो सीपीयू-गहन कार्यभार के लिए मूल्य अनुकूलन लाभ प्रदान करते हैं। उनके साथ, मानक स्तर अब 3,000 डीटीयू तक का समर्थन करता है।

इस बिंदु पर, आप अपने आप से पूछ रहे होंगे कि वास्तव में डीटीयू क्या है? DTU एक डेटाबेस ट्रांजेक्शन यूनिट है और यह CPU, मेमोरी और डेटा और ट्रांजेक्शन लॉग I/O का मिश्रण है। (एंडी मॉलन, @AMtwo, ने हाल ही में "व्हाट द हेक इज ए डीटीयू?" में इसे संबोधित किया है) आप सीपीयू, मेमोरी, या आई/ओ को अधिकतम करके अपनी डीटीयू सीमा को हिट कर सकते हैं।

पहले, स्टैंडर्ड टियर ने केवल 4 स्तरों की पेशकश की:15, 30, 50, और 100 डीटीयू, मानक डिस्क के साथ 250GB की डेटाबेस आकार सीमा के साथ। यदि आपके पास एक डेटाबेस था जो 250GB से बड़ा था, हालाँकि CPU, मेमोरी, या I/O के लिए 100 से अधिक DTU की आवश्यकता नहीं थी, तो आप केवल डेटाबेस आकार के लिए प्रीमियम मूल्य का भुगतान करने में फंस गए थे। नए परिवर्तनों के साथ, अब आपके पास मानक स्तर में 1TB तक का डेटाबेस हो सकता है; आपको बस अतिरिक्त संग्रहण का भुगतान करना होगा। पूर्वावलोकन के दौरान वर्तमान में भंडारण $0.085/GB पर बिल किया जा रहा है। $65.79 प्रति माह की लागत से शामिल आकार को 250GB से बढ़ाकर 1TB करने पर 774GB की वृद्धि होती है।

नया मानक पूर्वावलोकन DTU आकार 200, 400, 800, 1,600 और 3,000 DTU विकल्पों का समर्थन करता है। यदि आपके पास एक SQL सर्वर डेटाबेस वर्कलोड है जो I/O से अधिक CPU-बाउंड है, तो इन मानक स्तरीय विकल्पों में आपको बहुत सारा पैसा बचाने की क्षमता है; हालांकि, यदि आपका कार्यभार I/O बाध्य है, तो प्रीमियम स्तर मानक स्तर से बेहतर प्रदर्शन करने वाला है।

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

इस डेमो को सेटअप करने के लिए, मैंने तीन GUID कॉलम वाली एक टेबल बनाई, जिसमें 1 मिलियन पंक्तियां डाली गईं, और फिर तीन में से दो कॉलम को नई आईडी के साथ अपडेट किया। नमूना कोड नीचे है:

CREATE TABLE dbo.TestTable
(
  Table_id UNIQUEIDENTIFIER DEFAULT NEWID(),
  Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(),
  Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40))
);
 
SET NOCOUNT ON;
GO
 
INSERT INTO dbo.TestTable DEFAULT VALUES;
GO 1000000
 
CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable]
(
  [Table_id] ASC,
  [Customer_id] ASC
);
 
SET STATISTICS TIME ON;
 
UPDATE TestTable
  SET Table_id = NEWID(), Customer_id = NEWID();

जैसे ही मैं परीक्षणों की श्रृंखला के माध्यम से भाग गया, मानक स्तर में प्रदर्शन में लगातार सुधार हुआ जब तक कि मुझे एस 12 विकल्प नहीं मिला, जहां अजीब तरह से, सीपीयू और बीता हुआ समय बढ़ गया। मैंने कई बार परीक्षण चलाया और S12 लगातार 54 सेकंड का था। मेरे पहले परीक्षण के साथ यह बहुत स्पष्ट है कि प्रीमियम स्तर ने मानक स्तर से बेहतर प्रदर्शन किया। उदाहरण के लिए, S9 और P2 समय के सबसे करीब हैं, हालांकि मानक के लिए DTU का आकार P2 के लिए 250 की तुलना में 1,600 है। यह परीक्षण I/O क्षमताओं के बारे में अधिक है। नीचे दिया गया चार्ट प्रत्येक परीक्षण के लिए आकार, DTU स्तर, लागत, CPU समय, बीता हुआ समय और सेकंड में समय दिखाता है:

चूंकि परीक्षण निष्पादित किए जा रहे थे, मैंने मॉनिटर डैशबोर्ड में देखा कि डेटा I/O और लॉग I/O प्रतिशत DTU प्रतिशत के पीछे प्रेरक शक्ति थे। निम्न चार्ट एक S4 डेटाबेस के विरुद्ध एक रन से था:

फिर मैंने परीक्षणों की एक और श्रृंखला की कोशिश करने का फैसला किया जो अधिक सीपीयू-भारी होगा। उस परीक्षण के लिए मैंने निम्नलिखित स्क्रिप्ट का उपयोग किया:

SET STATISTICS TIME ON;
 
SELECT SUM(CONVERT(BIGINT, t1.object_id) 
         + CONVERT(BIGINT, t2.object_id) 
         + CONVERT(BIGINT, t3.object_id) 
         + CONVERT(BIGINT, t4.object_id))
  FROM sys.objects t1
  CROSS JOIN sys.objects t2
  CROSS JOIN sys.objects t3
  CROSS JOIN sys.objects t4;

मैंने इस श्रृंखला के परीक्षणों पर मॉनिटर डैशबोर्ड में जो देखा वह यह है कि सीपीयू प्रतिशत डीटीयू प्रतिशत का एकमात्र चालक था। जैसा कि मैंने मानक स्तर में परीक्षणों की श्रृंखला के माध्यम से चला गया, परीक्षण लगभग 27 सेकंड में पठार लग रहा था, और एस 4 आकार में शुरू हुआ। मुझे जो अजीब लगा वह यह है कि 200 डीटीयू पर एक एस 4 को पूरा करने में 27 सेकंड लगते हैं और 250 डीटीयू पर संबंधित पी 2 को 38 सेकंड लगते हैं; 500 DTU पर P4 अधिक तुलनीय था। यदि हम इस डेमो के लिए लागत अंतर को देखें, तो पूर्वावलोकन के दौरान एक S4 की कीमत केवल $150.01 है, जबकि एक P4 की कीमत $1,860 है; S4 केवल $1,700 से अधिक की लागत बचत प्रदान करता है। आइए कल्पना करें कि 250 DTU में एक P2 ने जैसा हमने उम्मीद की थी वैसा ही प्रदर्शन किया; एक P2 की कीमत $930 है और फिर भी इसकी कीमत S4 से $780 अधिक होगी।

दूसरे डेमो में सभी परीक्षणों के पूर्ण परिणाम निम्न चार्ट में शामिल हैं:

पहले डेमो के विपरीत, यह 100% CPU-संचालित था। मैंने एक अतिरिक्त क्रॉस जॉइन को शामिल करने का प्रयास किया था, लेकिन डेमो ने मिनटों के बजाय प्रति सत्र घंटों का समय लिया। भविष्य के परीक्षण के लिए मैं कुछ अतिरिक्त परिदृश्यों के साथ आने का प्रयास करूंगा जो अधिक यथार्थवादी OLTP कार्यभार को आगे बढ़ाते हैं; एक जो उच्च CPU है, और एक जो अधिक I/O बाध्य है, और फिर दोनों का एक अच्छा मिश्रण है।

आप नीचे दिए गए ग्राफ़ से देख सकते हैं कि, S4 डेटाबेस के विरुद्ध इस रन पर, CPU में लगभग 50% की वृद्धि हुई, जबकि DTU प्रतिशत बिल्कुल मेल खाता था:

मेरे द्वारा परीक्षण किए गए दो अलग-अलग कार्यभार से, यह बहुत स्पष्ट है कि यदि आपके पास कोई महत्वपूर्ण I/O कार्यभार है, तो आपको प्रीमियम स्तर की आवश्यकता होगी, लेकिन यदि आपका कार्यभार बिना किसी महत्वपूर्ण I/O आवश्यकताओं के अधिकतर CPU-बाध्य है, तो उच्चतर मानक स्तर आपको प्रीमियम स्तर पर पर्याप्त बचत प्रदान कर सकते हैं।

यदि आप किसी Azure SQL डेटाबेस में माइग्रेशन पर विचार कर रहे हैं, तो DTU कैलकुलेटर आकार देने के लिए एक शुरुआती बिंदु का विचार प्राप्त करने के लिए एक बेहतरीन जगह है; हालांकि, लेखन के समय, डीटीयू कैलकुलेटर विस्तारित मानक स्तर को ध्यान में नहीं रखता है। डीटीयू कैलकुलेटर के बारे में सबसे अच्छी बात यह है कि यह सीपीयू, आईओपी और लॉग उपयोग को तोड़ देगा ताकि आपको पता चल सके कि डीटीयू स्तर की सिफारिश के लिए ड्राइविंग कारक क्या है। उदाहरण के लिए, मैंने 4 वीसीपीयू, 4 जीबी वर्चुअल मशीन पर अंतिम डेमो चलाया, और डीटीयू कैलकुलेटर ने पी 2 की सिफारिश की। जब मैंने 'अधिक विवरण देखना' चुना, तो मुझे निम्नलिखित संदेश मिले।

CPU के लिए सेवा स्तर/प्रदर्शन स्तर - केवल CPU उपयोग के आधार पर, हम अनुशंसा करते हैं कि आप अपने SQL सर्वर वर्कलोड को प्रीमियम - P2 में माइग्रेट करें। इस सेवा स्तर/प्रदर्शन स्तर में आपके CPU उपयोग का लगभग 100.00% शामिल होना चाहिए।

आईओपीएस के लिए सेवा स्तर/प्रदर्शन स्तर - पूरी तरह से Iops के उपयोग के आधार पर, हम अनुशंसा करते हैं कि आप अपने SQL सर्वर वर्कलोड को बेसिक में माइग्रेट करें। इस सेवा स्तर/प्रदर्शन स्तर में आपके Iops उपयोग का लगभग 89.92% शामिल होना चाहिए।

नोट:आपके कार्यभार का लगभग 10.08% है जो उच्च सेवा स्तर/प्रदर्शन स्तर पर आता है। अपने डेटाबेस को Azure में माइग्रेट करने के बाद, आपको उपरोक्त जानकारी अनुभाग में उल्लिखित मार्गदर्शन का उपयोग करके अपने डेटाबेस के प्रदर्शन का मूल्यांकन करना चाहिए।

लॉग के लिए सेवा स्तर/प्रदर्शन स्तर - केवल लॉग उपयोग पर आधारित, हम अनुशंसा करते हैं कि आप अपने SQL सर्वर वर्कलोड को बेसिक में माइग्रेट करें। इस सेवा स्तर/प्रदर्शन स्तर में आपके लॉग उपयोग का लगभग 100.00% शामिल होना चाहिए।

चूंकि मुझे पता है कि यह कार्यभार बहुत अधिक CPU-बाध्य है, यदि मैं CPU आवश्यकता को कम करने के लिए कार्यभार को ट्यून नहीं कर सकता, तो मेरे पास मानक स्तर में 3,000 DTU उपलब्ध हैं। 250 DTU वाले P2 के लिए प्रति माह $930 खर्च करने के बजाय, 200 DTU वाला S4 $150 प्रति माह (या 400 DTU वाला S6 $300.02 प्रति माह) अधिक किफायती विकल्प होगा।

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