Olá pessoal, tudo bem? O Stretch Database é um recurso disponível a partir do SQL Server 2016 que apresenta uma solução híbrida (cloud e on-premises) de armazenamento e acesso de dados frios em nuvem. Sendo mais prático, imagina uma tabela de 10 GB onde 9 GB são dados frios, que não são frequentemente acessados. Até que algo seja feito (expurgo, ou migração pra algum lugar), estes dados estão ocupando a mesma área “nobre” de dados quentes (dados frequentemente utilizados). O Stretch faz justamente essa migração de dados frios para a nuvem, porém não só isso, ele garante que os mesmos poderão ser acessados normalmente, como se tivessem presentes no on-premises, de modo transparente.
As perguntas que podem ser feitas para descobrir se o recurso te atende são:
- Eu ou os usuários do sistema às vezes precisamos consultar dados antigos mesmo não sendo tão frequentemente?
- Quero/preciso economizar espaço e dinheiro com storage de produção?
- Minhas tabelas crescem muito e estou começando a perder o controle sobre isso? Estou sempre precisando alocar mais storage e o tamanho está começando a afetar rotinas de manutenção (e dependendo do caso comprometendo o SLA)?
Para informações mais direcionadoras, recomendo documentação oficial, inclusive para saber quais limitações tem o recurso antes e depois de implementar. No final do post, coloco as referências na documentação oficial.
Cenário #1 – Quero migrar dados frios para nuvem
Bem, após análise cautelosa, considerei fazer uso do recurso de “stretch” na tabela de comentários da base do StackOverflow2010 (disponível gratuitamente) para arquivar em nuvem todos os comentários anteriores ao ano de 2010, que considero dados frios, raramente acessados, e não quero manter isto armazenado nos discos locais porque descobri que armazenar e manter isso em nuvem é mais barato que meu servidor local.
Existem dois pré-requisitos para realização dos testes:
- Ter uma instância on-premises instalada: No meu caso é uma instância MSSQL 2019 e claro, um banco de dados, que para meu negócio é o StackOverflow2010.
- Ter uma subscription no Azure para “alugar” o recurso Stretch e armazenar os dados frios em nuvem
Vamos de interface gráfica por motivos de praticidade.
- Selecionar a tabela que quero “alongar” na nuvem: Botão direito, Stretch > Enable para iniciar a configuração:
2. Aqui o SQL te explica no modo “fala aí nobreza” como o recuso funciona:
3. Aqui você escolhe o que você quer levar para a nuvem. Eu quero uma migração parcial dos dados e não a tabela inteira (Entire Table), que seria outro cenário bem comum, então vamos alterar esta opção:
Bom, apenas configurando o filtro, é criada uma função para identificar e migrar os dados considerados frios.
Aqui como ficou após a escolha dos registros:
4. Agora precisamos logar no Azure para configurar o lado da nuvem e aqui entra o requisito de se ter uma subscrição ativa:
Aqui é necessário escolher em qual região vamos configurar o recurso, escolhi Brasil e ele também me pede pra criar um servidor (!) de Stretch.
5. Agora o Azure pede que você crie uma master key para o banco envolvido no Stretch pra reforço de segurança:
6. É necessária a criação de regra no Azure Firewall para permitir que o SQL on-premises acesse os dados frios em nuvem. Como são testes locais, vou deixar padrão:
Pronto, acabou a configuração. Na tela abaixo tem um resumo do que fizemos nos passos acima. Detalhe para a informação “Estimated Pricing”.
Agora é apertar Finish. Aqui temos dois detalhes interessantes:
- O ícone do database mudou, indicando que aquele banco não é mais como os outros;
- A frase “Enjoy your SQL Server Cloud Experience” pra te dar boas vindas mas indiretamente, lembrar também que a Cloud ainda é “infra de alguém”, então atenção aos custos!
Mas voltando ao assunto técnico, vamos monitorar visualmente se configuramos corretamente?
E aqui está informações sobre a execução do processo de Stretch, inteiramente executado através da função que criamos. Para curiosos, temos um Extended Events com os eventos da sincronização/migração dos dados frios, se alguém se interessar (destacado em laranja):
Tudo certo, temos nosso recurso funcionando, e com os dados frios em nuvem, enquanto o restante fica local. Vamos ao…
Teste simples
Na prática, temos uma query que busca todos os comentários de 2008 de uma forma questionável (asterisco kkkkkk) que executava antes mesmo de ativar o Stretch, e vamos rodar de novo on-premises pra validar se ainda funciona, mesmo que todos os dados que ela consulte estejam em nuvem. Postei também o plano de execução para comprovar que os dados estão sendo acessados de forma “remota”:
Aqui vimos na prática como o recurso funciona: É sobre manter dados frios em nuvem com baixo custo (pro meu cenário) e com isso diminuir a quantidade de dados armazenada localmente, nas tabelas envolvidas no Stretch, tudo isso sem alteração de código.
Bem, como são dados frios migrados para a nuvem, temos menos dados alocados na storage on-premises, e isso reflete diretamente em nossas rotinas de manutenção também (checkdb, reindexações, estatísticas, backup, etc).
Agora vale a pena conferir no portal do Azure o que foi criado por debaixo dos panos, já que sabemos que o papel da nuvem é também de abstrair importantes detalhes técnicos que muita gente geralmente não se importa (e talvez devesse).
Enquanto isso no Azure…
Acessando os recursos relacionados ao Stretch (que gerou um ResourceGroup e quando o assunto é Azure SEMPRE verifique quais recursos foram gerados em qualquer coisa que for fazer pra não ter surpresas) temos dois detalhes importantes: um recurso do tipo Stretch Database (o que já era esperado) e outro sendo um servidor SQL Server (que ficou implícito que seria criado conhecendo a arquitetura da solução mas não é tão óbvio assim para primeiros passageiros, o que no final das contas (a grosso modo) faz um linked server on-prem -> nuvem só que bem transparente).
Vamos analisar as telas dos recursos:
- Tela do recurso Stretch
Muito legal essa tela, pois mostra o recurso criado e quanto espaço ele está ocupando no momento. Além disso, ganhamos um gráfico para monitoração e baseline (ponto para o Azure). Obviamente a cobrança aqui como descrita na documentação é GB/hour ou TB/month. Mas não é apenas no armazenamento que haverá cobrança, afinal, de acordo com a documentação oficial, a precificação é baseado em DSU (ou seja recurso computacional para acessar os dados) e não apenas em armazenamento, conforme informação abaixo:
Bem, aqui temos o conceito do que seria “DSU” (Database Stretch Unit):
Em outras palavras, lembra o conceito de DTU porém um pouco mais “customizado” para a lógica do que seria consumir dados via stretch. De modo relativo, quanto maior o tier de DSU, maior o poder de processamento destes dados. Aqui cabe uma análise caso a caso, no meu cenário, não me interessa pagar mais por performance para acessar tais dados, então faz sentido configurar pela menor tier.
2. Tela do servidor
Olha que tela interessante . Ela mostra que foi criado um servidor SQL, para então criar um banco do tipo “stretch“. Claro que a melhor parte foi destacada…A cobrança em tese seria em DSU, porque a Pricing Tier colocou DTU no meio?! A resposta é: existe um servidor SQL implícito associado ao recurso de Stretch.
Bem, se tem servidor no meio para armazenar o banco Stretch, talvez não custa acessá-lo e confirmar se é isso mesmo, né?
Pricing e o “Enjoy your Cloud Experience”
Bem, vamos falar um pouco sobre precificação e aqui fica meus “centavos” de contribuição sobre o assunto. Maiores detalhes nas referências deste post, mas a grosso modo, a Microsoft cobra por dados armazenados (independente se está em uso ou não, eles sofrem backup, snapshot, criptografia, etc) e pela computação sobre estes dados (processamento, no papo reto). Ou seja, mesmo que você desfaça a configuração do Stretch no banco de dados, vai precisar lidar com a remoção (e cobrança) destes recursos em sua subscrição do Azure para não ser cobrado de forma contínua.
[23-09-2020 18:16]EDIT Bônus: Dois dias depois de configurar o recurso e deixar totalmente idle, eis o custo convertido em reais, de acordo com todos os parâmetros já informados no post acima :
Pra mim essa é a cereja do bolo quando vamos falar de Azure e/ou Cloud em geral, tudo tem um custo associado (com razão, é de infra que estamos falando) e não basta apenas resolver um problema real do negócio mas também entender se o valor investido compensa e faz sentido, e isso é o verdadeiro valor da frase “Enjoy your Cloud Experience”!
Conclusão
Bem, o recurso conseguiu atender meu caso de uso fictício e estou contente com o resultado. Se é aplicável ou não em todo cenário, vamos com a resposta mais honesta (e precisa) da TI possível: “Depende”. Existem formas muito mais baratas on-premise de armazenar dados frios, assim como em vários casos eu já vi o mesmo problema ser resolvido (por ser possível naquele cenário específico) criando uma base ABC_Historico, com DataCompression=PAGE, discos lentos e tudo mais…Por mais conveniente que seja o Stretch, ele tem um custo e vale avaliar se vale no final das contas (trocadilho não-intencional).
Mas talvez seja uma solução que possa atender algum cenário seu, independente disso, é bom deixar no radar…
________________________
Bem, espero que tenham curtido a leitura. Pra mim foi divertido fazer esse escrever esse post enquanto eu vou experimentando os recursos. Espero que você esteja bem, e até o próximo post!
Documentação: https://docs.microsoft.com/en-us/sql/sql-server/stretch-database/stretch-database?view=sql-server-ver15
Pricing: https://azure.microsoft.com/en-us/pricing/details/sql-server-stretch-database/
[]’s