Um dos serviços que estão disponíveis desde as primeiras versões do Microsoft Azure (anteriormente Windows Azure) é o de criação de bancos de dados relacionais sobre SQL Server. O serviço ao qual me refiro (hoje chamado Azure SQL Database) possibilita a criação de bancos de dados SQL Server como serviço (PaaS). Escrevi um post há algum tempo sobre este recurso. Muito embora algumas coisas tenham mudado desde o lançamento, o post dá uma ideia geral do funcionamento do mesmo. Você pode ler o post na íntegra aqui.
Os novos níveis de serviço
A partir de Setembro de 2015 as antigas camadas/níveis de serviços para as bases de dados SQL no Azure (Web e Business) foram descontinuadas e deram lugar a 3 novas: Basic, Standard e Premium. Isso foi feito porque os níveis anteriores não representavam de forma efetiva as necessidades dos negócios e, além disso, os recursos disponíveis eram mais generalistas. Como resultado desta característica, clientes acabavam “pagando” por recursos que não utilizavam ou, em cenários adversos, acabavam ficando sem recursos necessários.
Com um melhor delineamento das funcionalidades (recursos disponíveis para o trabalho com os bancos), as bases de dados SQL como serviço agora permitem aos clientes fazer um melhor direcionamento equacionando necessidades da aplicação x arquitetura x custo.
Aspectos comuns entre as camadas/níveis
Antes de falarmos com maiores detalhes sobre cada um dos níveis, você deve ter claro o seguinte: os modelos operacionais internos de cada cada banco de dados mudam radicalmente de acordo com o nível. Aspectos como performance, número de queries concorrentes e o volumes de dados retornados, são diretamente impactados por conta desta escolha.
Além disso, é preciso considerar que, atualmente, as Azure SQL Databases são criadas sobre a release 12 da engine de SQL PaaS (você pode saber um pouco mais sobre isso aqui). Bases de dados criadas em versões anteriores muito embora funcionem e possuam suporte, não possuem a mesma performance e alguns recursos exclusivos da última release. Migrações para versões posteriores são sempre uma opção :-).
Cada camada/nível das Azure SQL Databases possui indicadores comuns. Estes indicadores são importantes pois permitem medir se os bancos de dados estão entregando o que prometem e ainda, para que seja possível realizar a distinção de forma clara entre dos diferentes planos. São eles:
- Tamanho máximo do banco de dados (Max DB Size)
- Unidade de Transação de Banco de Dados (DTU)
- Pontos de restauração (Point-in-time Restore)
- Restauração em caso de desastres (Disaster recovery)
- Transações por segundo (Transactions per second)
- Número máximo de requisições concorrentes (Max concurrent requests)
- Número máximo de logins concorrentes (Max concurrent logins)
- Número máximo de sessões (Max sessions)
Como você pode perceber, os nomes dos indicadores já dão uma noção das capacidades que cada banco irá possuir de acordo com o nível de serviço escolhido e por isso dispensam maiores comentários.
Deixamos em negrito o indicador DTU. Isso porque, na grande maioria dos casos, é o indicador que mais gera dúvida em usuários no momento em que uma nova base de dados está sendo criada. Aliás, a explicação deste indicador inspirou a escrita deste post. Falarei de forma detalhada sobre os DTUs mais adiante.
Sim, será possível mudar o nível de serviço de um banco de dados a qualquer momento sem perda de informações e sem interromper o funcionamento da aplicação desde que esta mudança não quebre as exigências estruturais das camadas. Estas exigências são claramente apresentadas aqui.
Outra característica comum entre as camadas/níveis de serviços é que existem variações dentro de cada uma delas. Basicamente, essas variações dizem respeito a melhorias de performance, frequência de backups, etc. Falaremos mais sobre isso mais adiante neste artigo.
Vamos então ao detalhamento de cada um dos níveis para que possamos entender com minúcias as tão enigmáticas (zueira, nem são tão enigmáticas assim) DTUs.
Basic
O nível mais baixo dentro da estrutura de camadas/níveis de serviços do Azure SQL Database é o “Basic”. A recomendação é que este tipo de banco de dados seja criado apenas para ambientes internos de desenvolvimento, testes e homologação e para aplicações pouco utilizadas.
Apenas uma operação é permitida em um dado momento, o banco de dados nesta configuração possuirá no máximo 2 GB de tamanho e é o tipo de banco PaaS mais barato do Microsoft Azure. Não possui variações internas de capacidades.
Standard
É o nível intermediário das camadas/níveis de serviços do Azure SQL Database. Recomendado para a maioria das aplicações uma vez que suporta múltiplas operações simultâneas. Seu preço muda de acordo com a variação interna de capacidades da camada de serviço (S0, S1, S2 e S3).
É importante observar também que não é apenas o valor das instâncias SQL que se modificam. Todos os indicadores dos quais falamos anteriormente também se alteram. A Figura 1 apresenta uma tabela que resume as camadas, variações internas e valores.
Premium
É o nível mais avançado das Azure SQL Databases. Recomendado para aplicações que transacionam altos volumes de dados, como aplicações de missão crítica. Também possui variações internas de capacidades (P1, P2, P4, P6/P3 e P11) que, a modelo que do temos no modelo Standard, varia todos os indicadores já mencionados, incluindo valores.
Figura 1. Tabela que resume as camadas/níveis e variações internas de capacidades
Fonte: Azure.com
DTUs
DTU é o acrônimo para Database Transaction Unit (em pt-br, Unidade de Transações do Bancos de Dados). A ideia é que este indicador nos mostre a capacidade de processamento do banco de dados em um modelo real de medida: transações.
O que a Microsoft fez foi desenvolver um benchmark que coloca as Azure SQL Databases para processar um set de operações de tempo real (OLTP – saiba um pouco mais sobre isso) e que mede o desempenho apresentado por elas enquanto o processo corre. O resultado é expresso então em DTUs.
Desta forma, o número de DTUs apresentado por uma Azure SQL Database é na verdade, o número de transações impostas pelo benchmark processadas por segundo.
Em termos práticos, enquanto uma base de dados Basic consegue processar 5 operações por segundo, uma base de dados P11 consegue processar 1.750 operações por segundo. Cool, não?!
Mais DTUs será sempre a melhor escolha?
Não. Como já mencionamos anteriormente, existem vários critérios (indicadores) que devem ser levados em consideração por você no momento de criar sua Azure SQL Database. DTU é apenas um deles (sim, talvez seja o mais importante porque impacta diretamente na performance e todos buscamos isso incessantemente).
Muito embora performance seja algo importante, em muitos (muitos mesmo) casos, ela não é um fator crítico. O tamanho do banco de dados (por exemplo) pode ser mais relevante. Neste caso, uma base de dados Standard com 50 DTUs pode ser suficiente em termos de performance e te possibilitará ter um banco de até 250 GB.
Enfim, tudo depende do que a aplicação/cenário exige. O que é possível afirmar é que hoje, as Azure SQL Databases estão mais robustas, performáticas e com mais opções de direcionamento de direcionamento nas soluções e é isso que precisamos, de OPÇÕES.
Por hoje é só. Espero que isso te ajude de alguma forma quando for criar seu novo banco de dados SQL como serviço.
Até a próxima!
Facebook
Twitter
Instagram
LinkedIn
RSS