Microsoft Azure предоставя платформа за база данни като услуга (PaaS) чрез платформата на Azure SQL база данни, така че да можем да използваме тази база данни за базираните в облак приложения. Основното предимство на базата данни Azure SQL е позволява лесното мащабиране с нулев престой и не изисква надграждане на версията или процес на корекция. Освен това не е нужно да се тревожим за хардуерни проблеми.

Въпреки това, важното съображение за базата данни Azure SQL е да отговори на изискването за производителност на внедрената база данни срещу минималните разходи. Без съмнение никой не иска да плаща пари за излишните ресурси или функции, които не използва или планира да използва.

На този етап Microsoft Azure предлага два различни модела за закупуване, за да осигури разходна ефективност:

• Модел за закупуване, базиран на единица за транзакции на база данни (DTU).
• Модел на закупуване, базиран на виртуално ядро ​​(vCore)

Решението за модел на покупка пряко влияе върху производителността на базата данни и общата сума на сметките. Според мен, ако внедрената база данни няма да изразходва твърде много ресурси, базираният на DTU модел на покупка ще бъде по-подходящ.

Сега ще обсъдим подробностите за тези два модела за закупуване в следващите раздели.

Модел на покупка, базиран на единица за транзакции на база данни (DTU)

За да разберем по-ясно модела на покупка, базиран на DTU, трябва да изясним какво има смисъл DTU в Azure SQL база данни. DTU е съкращение за „Единица за транзакции на база данни“ и описва показател за единица производителност за базата данни на Azure SQL. Можем просто да харесаме DTU на конските сили в колата, защото пряко влияе върху производителността на базата данни. DTU представлява смес от следните показатели за производителност като единична единица за производителност за Azure SQL база данни:

• ЦП
• Памет
• Вход/изход на данни и вход/изход на журнал

Основната идея на концепцията DTU е да предложи предварително конфигурирана конфигурация на ресурса на клиентите, така че да опростява мащабирането на производителността в рамките на един показател. Например, ако имаме нужда от повече производителност, можем да плъзгаме лентата и да увеличим броя на DTU в Azure SQL база данни.

Моделът за закупуване, базиран на DTU, съдържа три различни нива на услуги и тези нива на услуги предлагат различни DTU и опции за функции. Следващата таблица илюстрира нивата на услуги, които са участвали в базирания на DTU модел на покупка.

Както виждаме, максималните DTU и функции варират в зависимост от тяхното ниво на обслужване. Също така моделът на ценообразуване ще бъде променен във връзка с нивото на услугата. Например, следната конфигурация за единична база данни в модела за покупка, базиран на DTU, ще бъде $584,00 на месец.

Еластичен пул

Накратко, Elastic Pool ни помага автоматично да управляваме и мащабираме множеството бази данни, които имат непредсказуеми и различни нужди от ресурси в споделен пул от ресурси. Чрез Elastic Pool не е необходимо непрекъснато да мащабираме базите данни срещу колебанията в търсенето на ресурси. Базите данни, които участват в пула, консумират ресурсите на Elastic Pool, когато са необходими, но те не могат да надвишават ограниченията на ресурсите Elastic Pool, така че да предоставят рентабилно решение.

Правилно оценяване на DTU за Azure SQL база данни

След като решим да използваме базиран на DTU модел на покупка, трябва да открием следния въпрос-отговор с логически причини:

• Кое ниво на услугата и колко DTU са необходими за работното ми натоварване при мигриране към Azure SQL?

DTU калкулаторът ще бъде основното решение за оценка на изискването за DTU, когато мигрираме локални бази данни към Azure SQL база данни. Основната идея на този инструмент е улавянето на различните използвани метрики от съществуващия SQL Server, които засягат DTU и след това се опитва да оцени приблизително DTU и ниво на услугата в светлината на събраното използване на производителността. DTU калкулаторът събира следните показатели чрез помощната програма на командния ред или PowerShell скрипта и записва тези показатели в CSV файл.

• Процесор – % процесорно време
• Логически диск – четене на диск/сек
• Логически диск – запис на диск/сек
• База данни – регистрационни байтове, изчистени/сек.

В тази статия ще научим как се използва помощната програма за командния ред, тъй като това е проект с отворен код и кодовете се хостват в GitHub. По този начин можем лесно да правим промени, ако имаме нужда. След изтегляне и разархивиране на помощната програма за командния ред, два файла ще дойдат пред нас.

SqlDtuPerfmon.exe.config ни помага да определим някои параметри на помощната програма за командния ред:

CsvPath указва пътя на CSV файла, където ще се съхраняват събраните показатели.

SampleInterval указва колко секунди интервали ще бъдат събрани пробите

MaxSamples определя максималния брой проби, които ще бъдат събрани.

На този етап трябва да вземем предвид някои съображения относно калкулатора на DTU. DTU Calculator събира общото използване на показателите на компютъра. Поради тази причина другите процеси, които засягат консумацията на процесора, паметта и диска, трябва да бъдат спрени, в противен случай ще бъде трудно да се направи точна оценка на DTU. Друг проблем е, доколкото е възможно, трябва да съберем използването на показателите, които покриват интервалите от време на пиково натоварване. По този начин DTU калкулаторът предлага най-добрите препоръки и ние откриваме максималното изискване за DTU с по-приблизителна оценка. Сега ще стартираме SqlDtuPerfmon.exe и той директно ще започне да събира използването на ресурси и да запазва посочения CSV файл.

След приключване на събирането на използването на ресурса, ще въведем броя на ядрата и ще качим CSV файла на уеб сайта на DTU Calculator.

Когато щракнем върху бутона Изчисляване, първо, кръговата диаграма за ниво на обслужване/ниво на производителност се появява на екрана и показва разделените предложения за прогнозно ниво на услугата на части с подробности за процентите. Според калкулатора на DTU, ниво Standard - S6 ще осигури задоволителна производителност за това работно натоварване.

Точно под тази диаграма е показана диаграма DTUs през времето и тази диаграма представлява DTU, променящи се спрямо периода от време. Преди да оценим тази диаграма, можем да добавим някои допълнителни части от информацията, за да я интерпретираме по-лесно.

Както можете да видите, линейната диаграма представлява нестабилно работно натоварване, но имаше повече смисъл, когато добавихме информационни бележки. Според мен тази диаграма е много полезна за разбиране на взаимодействието между промените в работното натоварване и DTU. По този начин можем да направим по-правилна оценка на необходимите DTU. Както споменахме в началото на статията, нашата основна цел трябва да бъде да намерим рентабилно решение за работното натоварване.

Тези предложения обаче не изразяват точните изисквания на DTU в Azure SQL. Поради тази причина може да се наложи да променим нивото на услугата или модела за покупка след внедряването на базата данни в Azure SQL.

Когато щракнем върху Преглед на повече подробности, ще се покажат някои допълнителни отчети и тези отчети представляват индивидуалните препоръки за използване на ресурсите на процесора, IOPS и журнала. Те ще бъдат много полезни, за да разберете особено тези приложения.

Модел за закупуване, базиран на виртуално ядро ​​(vCore)

Тази концепция е подобна на традиционния подход, защото ние сме в състояние да решим всеки ресурс на базата данни. Можем да подредим опциите за VCores и максимален размер на данните ръчно в този модел. Не можем обаче да определим ресурса на паметта. Всяко VCore идва със специална памет и специалната стойност на паметта зависи от генерирането на VCore.

И накрая, в този модел можем да изберем следните нива на обслужване:

• Общо предназначение.
• Критичен за бизнеса.
• Хипермащаб

Заключение

В тази статия проучихме моделите за закупуване на базата данни Azure SQL и разкриваме инструкциите за използване на калкулатора на DTU, за да изчислим необходимия DTU в Azure SQL за локални бази данни.