Database
 sql >> база данни >  >> RDS >> Database

Нови стандартни размери на базата данни на Azure SQL

Azure SQL база данни в момента има три нива на услуги, от които да избирате за вашето работно натоварване. Тези нива се състоят от Basic, Standard и Premium. Basic поддържа само един размер от 5 DTU. Премиумът започва от 125 DTU и стига до 4000 DTU. Премиум ниво е най-горното ниво, което е изградено за по-високи I/O работни натоварвания и осигурява по-ниска латентност на I/O и порядък повече IOPS на DTU, отколкото в стандартното ниво.

Преди август 2017 г. стандартното ниво поддържаше само размери на DTU между 15 и 100 DTU. Понастоящем налични в предварителен преглед са нови нива на производителност и добавки за съхранение, които предлагат предимства за оптимизиране на цените за натоварвания с интензивни CPU. С тях стандартното ниво вече поддържа до 3000 DTU.

В този момент може би се питате какво точно е DTU? DTU е единица за транзакции на база данни и е смесица от процесор, памет и вход/изход на данни и регистър на транзакциите. (Анди Малън, @AMtwo, наскоро се обърна към това в „Какво, по дяволите, е DTU?“) Можете да достигнете лимита на DTU, като увеличите максимално CPU, памет или I/O.

Преди това стандартното ниво предлагаше само 4 нива:15, 30, 50 и 100 DTU, с ограничение на размера на базата данни от 250 GB, със стандартен диск. Ако имате база данни, която е по-голяма от 250 GB, но не се нуждаете от повече от 100 DTU за CPU, памет или I/O, вие сте останали да плащате Premium цена само за размера на базата данни. С новите промени вече можете да имате до 1TB база данни в стандартното ниво; просто трябва да платите допълнителното съхранение. В момента хранилището се таксува на $0,085/GB по време на визуализацията. Увеличаването от включения размер от 250GB на 1TB се увеличава със 774GB на цена от $65,79 на месец.

Новите стандартни размери на DTU за предварителен преглед поддържат опции за 200, 400, 800, 1600 и 3000 DTU. Ако имате работно натоварване на базата данни на SQL Server, което е по-обвързано с процесора, отколкото I/O, тези опции за стандартно ниво имат потенциала да ви спестят много пари; обаче, ако работното ви натоварване е свързано с I/O, нивото Premium ще превъзхожда стандартното ниво.

Реших да опитам две различни работни натоварвания, за да видя колко различни нивата Standard и Premium са в сравнение един с друг. Исках да създам прост и възпроизводим тест, така че другите да могат да се опитат да потвърдят сами. За първия си тест исках да генерирам здравословна комбинация от CPU и I/O. Надявах се, че ще използвам повече CPU, отколкото I/O, и ще мога да покажа, че разширеното стандартно ниво ще надмине ниво Premium със същия размер на 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();

Докато преминах през поредицата от тестове, производителността постоянно се подобряваше в стандартното ниво, докато стигнах до опцията S12, където, странно, процесорът и изминалото време се увеличиха. Проведох теста няколко пъти и S12 беше постоянно 54 секунди. С първия ми тест е доста ясно, че нивото Premium превъзхожда стандартното ниво. Например, S9 и P2 са най-близки във времето, но размерът на DTU за Standard е 1600 в сравнение с 250 за P2. Този тест е повече за I/O възможностите. Диаграмата по-долу показва размера, нивото на DTU, цената, времето на процесора, изминалото време и времето в секунди за всеки тест:

Докато тестовете се изпълняваха, забелязах в таблото за управление на монитора, че процентът на входно-изходни данни и входно-изходни данни в журнала са движещата сила зад процента на 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;

Това, което забелязах в таблото на монитора при тази серия от тестове, е, че процентът на процесора е единственият драйвер за процента на DTU. Докато преминах през поредицата от тестове в стандартното ниво, тестът изглеждаше на плато за около 27 секунди и започна при размер S4. Това, което ми направи странно, е, че S4 при 200 DTU отне 27 секунди, за да завърши, а съответният P2 при 250 DTU отне 38 секунди; P4 при 500 DTU беше по-сравним. Ако погледнем разликата в цената за тази демонстрация, S4 по време на визуализация струва само $150,01, докато P4 струва $1860; S4 осигурява спестяване на разходи от малко над $1700. Нека си представим, че P2 при 250 DTU се представи, както очаквахме; P2 струва $930 и все пак ще струва $780 повече от S4.

Пълните резултати от всички тестове във втората демонстрация са включени в следната диаграма:

За разлика от първата демонстрация, тази беше 100% задвижвана от процесора. Бях се опитал да включа едно допълнително кръстосано присъединяване, но демонстрацията отне часове на сесия вместо минути. За бъдещ тест ще се опитам да измисля няколко допълнителни сценария, които налагат по-реалистично натоварване на OLTP; един, който е по-висок CPU, и този, който е по-обвързан за вход/изход, и след това прилична комбинация от двете.

Можете да видите от графиката по-долу, че при това изпълнение срещу база данни S4, процесорът нарасна с почти 50%, докато процентът на DTU съвпада точно:

От двете различни натоварвания, които тествах, е много очевидно, че ако имате значително I/O работно натоварване, ще ви е необходимо ниво Premium, но ако работното ви натоварване е предимно свързано с процесора без значителни нужди за I/O, толкова по-високо е Стандартните нива могат да ви осигурят значителни спестявания в сравнение с Premium ниво.

Ако обмисляте миграция към Azure SQL база данни, DTU калкулаторът е чудесно място да започнете, за да получите представа за отправна точка за оразмеряване; обаче, към момента на писане, DTU калкулаторът не взема предвид разширения стандартен слой. Това, което е страхотно за DTU калкулатора е, че той ще извади CPU, IOPs и използване на регистрационни файлове, за да ви уведоми какъв е движещият фактор за препоръката за ниво на DTU. Например, пуснах последната демонстрация на 4 vCPU, 4GB виртуална машина и DTU калкулаторът препоръча P2. Когато избрах да „прегледам повече подробности“, получих следните съобщения.

Сервизно ниво/ниво на производителност за процесора – Въз основа единствено на използването на процесора, препоръчваме ви да мигрирате работното си натоварване на SQL Server към Premium – P2. Това ниво на обслужване/ниво на производителност трябва да покрива приблизително 100,00 % от използването на вашия процесор.

Ниво на обслужване/ниво на производителност за Iops – Въз основа единствено на използването на Iops, препоръчваме да мигрирате вашето работно натоварване на SQL Server към Basic. Това ниво на обслужване/ниво на производителност трябва да покрива приблизително 89,92 % от използването на Iops.

ЗАБЕЛЕЖКА:Има приблизително 10,08 % от вашето работно натоварване, което попада в по-високо ниво на обслужване/ниво на производителност. След като мигрирате базата си данни към Azure, трябва да оцените производителността на базата данни, като използвате указанията, споменати в информационния раздел по-горе.

Сервизно ниво/ниво на производителност за журнал – Въз основа единствено на използването на регистрационни файлове, препоръчваме ви да мигрирате вашето работно натоварване на SQL Server към Basic. Това ниво на услуга/ниво на производителност трябва да покрива приблизително 100,00 % от използването на вашия дневник.

Тъй като знам, че това работно натоварване е силно обвързано с процесора, ако не мога да настроя натоварването, за да намаля изискването за процесор, имам до 3000 DTU налични в стандартно ниво. Вместо да харчите $930 на месец за P2 с 250 DTU, S4 с 200 DTU за $150 на месец (или S6 с 400 DTU при $300,02 на месец) би бил много по-икономичен вариант.

В заключение, има налични инструменти, които да ви помогнат да определите добра отправна точка за размера на миграциите на вашата Azure SQL база данни, но абсолютно най-добрият метод е да тествате работното си натоварване. Мигрирането на копие на вашата производствена база данни, улавянето на производствено работно натоварване и повторното възпроизвеждане на това работно натоварване срещу Azure SQL база данни ще ви даде много по-добро разбиране за това какъв размер на DTU наистина се нуждаете.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Основи на паралелното програмиране с рамката Fork/Join в Java

  2. IDEF1X Нотация

  3. Ограничаване на свързан сървър до единично локално влизане (пример за T-SQL)

  4. ScaleGrid повишава капитала на растежа от партньорите на Spotlight Equity, за да ускори разширяването и да инвестира допълнително в продуктовата пътна карта

  5. Филтрирани индекси и ВКЛЮЧЕНИ колони