Atualmente, o Banco de Dados SQL do Azure tem três camadas de serviço para escolher para sua carga de trabalho. Essas camadas consistem em Basic, Standard e Premium. Básico suporta apenas um tamanho de 5 DTUs. Premium começa em 125 DTUs e vai até 4.000 DTUs. A camada Premium é a camada superior criada para cargas de trabalho de E/S mais altas e fornece latência mais baixa por E/S e uma ordem de magnitude mais IOPS por DTU do que na camada Standard.
Antes de agosto de 2017, a camada Standard suportava apenas tamanhos de DTU entre 15 e 100 DTUs. Atualmente disponíveis em versão prévia estão novos níveis de desempenho e complementos de armazenamento que oferecem benefícios de otimização de preço para cargas de trabalho com uso intenso de CPU. Com eles, a camada Standard agora suporta até 3.000 DTUs.
Neste ponto, você pode estar se perguntando o que, exatamente, é uma DTU? Uma DTU é uma Unidade de Transação de Banco de Dados e é uma mistura de CPU, memória e E/S de log de dados e transações. (Andy Mallon, @AMtwo, recentemente abordou isso em "O que diabos é uma DTU?") Você pode atingir seu limite de DTU maximizando CPU, memória ou E/S.
Anteriormente, a camada Standard oferecia apenas 4 níveis:15, 30, 50 e 100 DTUs, com um limite de tamanho de banco de dados de 250 GB, com disco padrão. Se você tivesse um banco de dados com mais de 250 GB, mas não precisasse de mais de 100 DTUs para CPU, memória ou E/S, teria que pagar um preço Premium apenas pelo tamanho do banco de dados. Com as novas alterações, agora você pode ter um banco de dados de até 1 TB na camada Standard; você só tem que pagar o armazenamento extra. Atualmente, o armazenamento está sendo cobrado a US$ 0,085/GB durante a visualização. Aumentar do tamanho incluído de 250 GB para 1 TB aumenta em 774 GB a um custo de US$ 65,79 por mês.
Os novos tamanhos de DTU de visualização padrão suportam opções de 200, 400, 800, 1.600 e 3.000 DTU. Se você tiver uma carga de trabalho de banco de dados do SQL Server que seja mais vinculada à CPU do que E/S, essas opções de camada Standard têm o potencial de economizar muito dinheiro; no entanto, se sua carga de trabalho estiver vinculada a E/S, a camada Premium terá um desempenho superior à camada Standard.
Decidi experimentar duas cargas de trabalho diferentes para ver como as camadas Standard e Premium são diferentes entre si. Eu queria criar um teste simples e reprodutível para que outros pudessem tentar validar por si mesmos. Para meu primeiro teste, eu queria gerar uma combinação saudável de CPU e E/S. Eu esperava que estivesse empurrando mais CPU do que E/S e pudesse mostrar que a camada Standard expandida superaria uma camada Premium com o mesmo tamanho de DTU. Não obtive exatamente os resultados que esperava.
Para configurar esta demonstração, criei uma tabela com três colunas GUID, inseri 1 milhão de linhas e atualizei duas das três colunas com novos IDs. O código de exemplo está abaixo:
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();
À medida que eu executava a série de testes, o desempenho melhorava constantemente na camada Standard até chegar à opção S12, onde, estranhamente, a CPU e o tempo decorrido aumentaram. Executei o teste várias vezes e S12 foi consistentemente 54 segundos. Ficou bem claro com meu primeiro teste que o nível Premium superou o nível Standard. Por exemplo, o S9 e o P2 estão mais próximos no tempo, porém o tamanho da DTU para o Padrão é 1.600 comparado a 250 para o P2. Este teste é mais sobre os recursos de E/S. O gráfico abaixo mostra o tamanho, nível de DTU, custo, tempo de CPU, tempo decorrido e tempo em segundos para cada teste:
À medida que os testes estavam sendo executados, observei no painel do monitor que a porcentagem de E/S de dados e de E/S de log eram a força motriz por trás da porcentagem de DTU. O gráfico a seguir foi de uma execução em um banco de dados S4:
Então decidi tentar outra série de testes que seriam mais pesados para a CPU. Para esse teste usei o seguinte script:
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; O que observei no painel do monitor nesta série de testes é que a porcentagem de CPU foi o único driver da porcentagem de DTU. Conforme passei pela série de testes no nível Standard, o teste pareceu se estabilizar em aproximadamente 27 segundos e começou no tamanho S4. O que me pareceu estranho é que um S4 a 200 DTU levou 27 segundos para ser concluído e o P2 correspondente a 250 DTU levou 38 segundos; um P4 a 500 DTU foi mais comparável. Se olharmos para o diferencial de custo para esta demonstração, um S4 durante a pré-visualização custa apenas US$ 150,01, enquanto um P4 custa US$ 1.860; o S4 oferece uma economia de pouco mais de US$ 1.700. Vamos imaginar que um P2 de 250 DTUs tenha o desempenho que esperávamos; um P2 custa US$ 930 e ainda custaria US$ 780 a mais do que um S4.
Os resultados completos de todos os testes na segunda demonstração estão incluídos no gráfico a seguir:
Ao contrário da primeira demonstração, esta foi 100% controlada pela CPU. Eu tentei incluir uma junção cruzada adicional, mas a demonstração levou horas por sessão em vez de minutos. Para um teste futuro, tentarei criar alguns cenários adicionais que impulsionem uma carga de trabalho OLTP mais realista; um que é maior CPU e um que é mais limitado por E/S e, em seguida, uma mistura decente dos dois.
Você pode ver no gráfico abaixo que, nesta execução em um banco de dados S4, a CPU atingiu quase 50%, enquanto a porcentagem de DTU correspondeu exatamente:
Das duas cargas de trabalho diferentes que testei, é muito evidente que, se você tiver alguma carga de trabalho de E/S significativa, precisará da camada Premium, mas se sua carga de trabalho for principalmente vinculada à CPU sem necessidades significativas de E/S, quanto maior As camadas Standard podem oferecer economias substanciais em relação à camada Premium.
Se você está pensando em migrar para um Banco de Dados SQL do Azure, a calculadora de DTU é um ótimo lugar para começar a ter uma ideia de um ponto de partida para dimensionamento; no entanto, no momento da escrita, a calculadora DTU não leva em consideração o nível padrão expandido. O que é ótimo sobre a calculadora de DTU é que ela divide a CPU, IOPs e utilização de log para que você saiba qual é o fator determinante para a recomendação de nível de DTU. Por exemplo, executei a última demonstração em uma máquina virtual de 4 vCPU e 4 GB e a calculadora DTU recomendou um P2. Quando escolhi 'ver mais detalhes', recebi as seguintes mensagens.
Nível de serviço/nível de desempenho para CPU – Com base apenas na utilização da CPU, recomendamos que você migre sua carga de trabalho do SQL Server para Premium – P2. Esse nível de serviço/nível de desempenho deve cobrir aproximadamente 100,00% de sua utilização de CPU.
Nível de nível de serviço/desempenho para Iops – Com base apenas na utilização de Iops, recomendamos que você migre sua carga de trabalho do SQL Server para Basic. Esse nível de serviço/nível de desempenho deve cobrir aproximadamente 89,92% de sua utilização de Iops.
OBSERVAÇÃO:há aproximadamente 10,08% de sua carga de trabalho que se enquadra em um nível de desempenho/nível de serviço mais alto. Depois de migrar seu banco de dados para o Azure, você deve avaliar o desempenho do banco de dados usando as orientações mencionadas na seção de informações acima.
Nível de serviço/nível de desempenho para registro – Com base apenas na utilização do Log, recomendamos que você migre sua carga de trabalho do SQL Server para Basic. Este nível de serviço/nível de desempenho deve cobrir aproximadamente 100,00% de sua utilização de log.
Como sei que essa carga de trabalho está fortemente vinculada à CPU, se não puder ajustar a carga de trabalho para diminuir o requisito de CPU, tenho até 3.000 DTUs disponíveis na camada Standard. Em vez de gastar US$ 930 por mês para um P2 com 250 DTUs, um S4 com 200 DTUs a US$ 150 por mês (ou um S6 com 400 DTUs a US$ 300,02 por mês) seria uma opção muito mais econômica.
Em conclusão, existem ferramentas disponíveis para ajudá-lo a determinar um bom ponto de partida para o tamanho de suas migrações do Banco de Dados SQL do Azure, mas o melhor método absoluto é testar sua carga de trabalho. Migrar uma cópia de seu banco de dados de produção, capturar uma carga de trabalho de produção e reproduzir essa carga de trabalho no Banco de Dados SQL do Azure fornecerá uma compreensão muito melhor de qual tamanho de DTU você realmente precisa.
