Otimizar a alocação de recursos de computação para atingir as metas de desempenho e controlar os custos pode ser um equilíbrio desafiador, especialmente para cargas de trabalho de banco de dados com padrões de uso complexos.
Para ajudar a solucionar esses desafios, hoje trazemos neste artigo a disponibilidade geral do Banco de Dados SQL do Azure sem servidor.
O Banco de Dados SQL sem servidor otimiza o desempenho dos preços e simplifica o gerenciamento de desempenho dos bancos de dados com uso intermitente e imprevisível.
Aplicativos de linha de negócios, bancos de dados de desenvolvimento / teste, gerenciamento de conteúdo e sistemas de comércio eletrônico são apenas alguns exemplos em uma variedade de aplicativos que geralmente se encaixam no padrão de uso ideal para servidores sem banco de dados SQL.
O Banco de Dados SQL sem servidor também é adequado para novos aplicativos com incertezas de dimensionamento de computação ou cargas de trabalho que exigem redimensionamento frequente para reduzir custos.
A camada de computação sem servidor desfruta de todos os benefícios de inteligência integrados e totalmente gerenciados do Banco de Dados SQL e ajuda a acelerar o desenvolvimento de aplicativos, minimizar a complexidade operacional e reduzir os custos totais.
Calculando o dimensionamento automático
O Banco de Dados SQL Serverless(sem servidor) dimensiona automaticamente a computação para bancos de dados únicos com base na demanda de carga de trabalho e nas faturas de computação usadas por segundo.
O Serveless(sem servidor) contrasta com a camada de computação provisionada no banco de dados SQL, que aloca uma quantidade fixa de recursos de computação por um preço fixo e é cobrada por hora.
Em prazos curtos, os bancos de dados de computação provisionados devem provisionar recursos em excesso a um custo, a fim de acomodar o pico de uso ou o fornecimento insuficiente e o risco de desempenho ruim.
Em escalas de tempo mais longas, os bancos de dados de computação provisionados podem ser redimensionados, mas essa solução pode exigir a previsão de padrões de uso ou a criação de lógica personalizada para acionar as operações de redimensionamento com base em um cronograma ou métricas de desempenho.
Isso aumenta a complexidade operacional e de desenvolvimento. No servidor, o dimensionamento da computação dentro dos limites configuráveis é gerenciado pelo serviço para obter continuamente o tamanho correto dos recursos.
O Serverless também fornece uma opção para pausar automaticamente o banco de dados durante períodos de uso inativo e retomar automaticamente quando a atividade retornar.
Pague apenas pela computação usada
No Banco de Dados SQL Serverless, a computação é cobrada apenas com base na quantidade de CPU e memória usada por segundo. Enquanto o banco de dados está em pausa, apenas o armazenamento é cobrado, fornecendo benefícios adicionais de otimização de preço.
Por exemplo, considere um aplicativo de linha de negócios que fica ocioso à noite, mas precisa de espaço livre de múltiplos núcleos ao longo do dia.
Suponha que o aplicativo esteja usando um banco de dados sem servidor configurado para permitir a pausa e o dimensionamento automáticos de até 16 vcores e tenha o seguinte padrão de uso em um período de 24 horas:
Como pode ser visto, o uso do banco de dados corresponde à quantidade de computação faturada que é medida em unidades de vcore segundos e soma em torno de 123k vcore segundos durante o período de 24 horas.
Suponha que o preço unitário de computação para o banco de dados sem servidor seja de aproximadamente US $ 0,000145 / vcore / segundo.
Em seguida, a conta de computação desse período de um dia é de cerca de US $ 18. Isso é calculado multiplicando o preço unitário de computação pelo número total de segundos do vcore acumulado.
Durante esse período, o banco de dados foi pausado automaticamente enquanto ocioso e desfrutou do benefício de estourar episódios de até 100% de 16 vcores sem a intervenção do cliente.
Neste exemplo, a economia de preço sem servidor é significativa em comparação com um banco de dados de computação provisionado configurado com o mesmo limite de 16 vcore.
Neste exemplo, os preços são baseados na região leste dos EUA, desde janeiro de 2020 isso está sujeito a alterações. Para obter os preços mais atualizados, entre em contato com a Seta Telecom.
Compensações de preço-desempenho
Ao usar o Banco de Dados SQL Serverless, há compensações de preço-desempenho a serem consideradas. Essas compensações estão relacionadas ao preço unitário de computação e ao impacto no desempenho do aplicativo devido ao aquecimento da computação após períodos de uso baixo ou ocioso.
Calculando preço unitário
O preço unitário da computação é mais alto para um banco de dados Serverless do que para um banco de dados provisionado, pois o servidor sem é otimizado para cargas de trabalho com padrões de uso intermitentes. Se o uso da CPU ou da memória for alto o suficiente e sustentado por tempo suficiente, a camada de computação provisionada poderá ser menos dispendiosa.
Calculando o aquecimento após pouco uso
Enquanto um banco de dados sem servidor estiver online, a memória será recuperada gradualmente se o uso da CPU ou da memória for baixo o suficiente por tempo suficiente.
Quando a atividade da carga de trabalho retorna, a IO do disco pode ser necessária para reidratar as páginas de dados no buffer pool SQL ou os planos de consulta podem precisar ser recompilados.
Essa política de gerenciamento de memória para recuperar o cache com base no baixo uso é exclusiva do Banco de Dados SQL Serverless e foi feita para controlar os custos do cliente, mas pode afetar o desempenho.
A recuperação de memória baseada no baixo uso não ocorre na camada de computação provisionada para bancos de dados únicos ou conjuntos elásticos em que esse tipo de impacto pode ser evitado.
Calculando o aquecimento após uma pausa
A latência para pausar e retomar um banco de dados Serverless geralmente é de cerca de um minuto ou menos, durante o qual o banco de dados está offline.
Depois que o database é retomado, os caches de memória precisam ser reidratados, o que adiciona latência adicional antes que as condições ideais de desempenho retornem.
O período inativo que deve decorrer antes da pausa automática pode ser configurado para compensar esse impacto no desempenho.
Como alternativa, a pausa automática pode ser desativada para cargas de trabalho sensíveis a esse impacto e ainda se beneficiar do dimensionamento automático.
Os mínimos de computação são cobrados enquanto o banco de dados está online, independentemente do uso, e a desativação da pausa automática pode aumentar os custos.
Gostou do conteúdo? Compartilhe!
Deseja adquirir o SQL Azure Serverless ou outra vertente do serviço? Entre em contato com a Seta Telecom!