Aumentar horizontalmente com a Base de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

Você pode facilmente dimensionar bancos de dados no Banco de Dados SQL do Azure usando as ferramentas do Banco de Dados Elástico. Essas ferramentas e recursos permitem que você use os recursos de banco de dados do Banco de Dados SQL do Azure para criar soluções para cargas de trabalho transacionais e, especialmente, aplicativos SaaS (Software as a Service). Os recursos do Banco de Dados Elástico são compostos por:

• Biblioteca de cliente do Banco de Dados Elástico: A biblioteca de cliente é um recurso que permite criar e manter bancos de dados fragmentados. Consulte Introdução às ferramentas do Elastic Database.
• Ferramenta de mesclagem dividida do Banco de Dados Elástico: move dados entre bancos de dados fragmentados. Essa ferramenta é útil para mover dados de um banco de dados multilocatário para um banco de dados de locatário único (ou vice-versa). Consulte o tutorial da ferramenta Split-Merge do banco de dados elástico.
• Trabalhos do Banco de Dados Elástico (visualização): use trabalhos para gerenciar um grande número de bancos de dados no Banco de Dados SQL do Azure. Execute facilmente operações administrativas, como alterações de esquema, gerenciamento de credenciais, atualizações de dados de referência, coleta de dados de desempenho ou coleta de telemetria de locatário (cliente) usando trabalhos.
• Consulta ao Banco de Dados Elástico (visualização): permite executar uma consulta Transact-SQL que abrange vários bancos de dados. Isso permite a conexão com ferramentas de relatório, como Excel, Power BI, Tableau, etc.
• Transações elásticas: esse recurso permite executar transações que abrangem vários bancos de dados. As transações de banco de dados elástico estão disponíveis para aplicativos .NET usando ADO .NET e integram-se com a experiência de programação familiar usando as classes System.Transaction.

O gráfico a seguir mostra uma arquitetura que inclui os recursos do Banco de Dados Elástico em relação a uma coleção de bancos de dados.

Neste gráfico, as cores do banco de dados representam esquemas. Bancos de dados com a mesma cor compartilham o mesmo esquema.

1. Um conjunto de bancos de dados SQL é hospedado no Azure usando a arquitetura de fragmentação.
2. A biblioteca de cliente do Elastic Database é usada para gerenciar um conjunto de estilhaços.
3. Um subconjunto dos bancos de dados é colocado em um pool elástico. (Ver O que é uma piscina?).
4. Um trabalho do Banco de Dados Elástico executa scripts T-SQL agendados ou ad hoc em todos os bancos de dados.
5. A ferramenta de mesclagem dividida é usada para mover dados de um fragmento para outro.
6. A consulta Banco de Dados Elástico permite que você escreva uma consulta que abrange todos os bancos de dados no conjunto de estilhaços.
7. As transações elásticas permitem executar transações que abrangem vários bancos de dados.

Porquê utilizar as ferramentas?

Alcançar elasticidade e escala para aplicativos em nuvem tem sido simples para VMs e armazenamento de blob - basta adicionar ou subtrair unidades ou aumentar a potência. Mas continua a ser um desafio para o processamento de dados stateful em bases de dados relacionais. Desafios surgiram nestes cenários:

• Capacidade crescente e reduzida para a parte do banco de dados relacional de sua carga de trabalho.
• Gerenciar pontos de acesso que podem surgir afetando um subconjunto específico de dados - como um cliente final ocupado (locatário).

Tradicionalmente, cenários como esses têm sido resolvidos investindo em servidores de maior escala para suportar o aplicativo. No entanto, essa opção é limitada na nuvem, onde todo o processamento acontece em hardware de mercadoria predefinido. Em vez disso, a distribuição de dados e processamento em muitos bancos de dados estruturados de forma idêntica (um padrão de expansão conhecido como "fragmentação") fornece uma alternativa às abordagens tradicionais de expansão, tanto em termos de custo quanto de elasticidade.

Dimensionamento horizontal e vertical

A figura a seguir mostra as dimensões horizontais e verticais do dimensionamento, que são as maneiras básicas pelas quais os bancos de dados elásticos podem ser dimensionados.

O dimensionamento horizontal refere-se à adição ou remoção de bancos de dados para ajustar a capacidade ou o desempenho geral, também chamado de "dimensionamento". O compartilhamento, no qual os dados são particionados em uma coleção de bancos de dados estruturados de forma idêntica, é uma maneira comum de implementar o dimensionamento horizontal.

O dimensionamento vertical refere-se ao aumento ou diminuição do tamanho de computação de um banco de dados individual, também conhecido como "escalonamento".

A maioria dos aplicativos de banco de dados em escala de nuvem usa uma combinação dessas duas estratégias. Por exemplo, um aplicativo de Software como Serviço pode usar o dimensionamento horizontal para provisionar novos clientes finais e o dimensionamento vertical para permitir que o banco de dados de cada cliente final aumente ou diminua os recursos conforme necessário para a carga de trabalho.

• O dimensionamento horizontal é gerenciado usando a biblioteca de cliente do Elastic Database.
• O dimensionamento vertical é realizado usando cmdlets do Azure PowerShell para alterar a camada de serviço ou colocando bancos de dados em um pool elástico.

Fragmentação

A fragmentação é uma técnica para distribuir grandes quantidades de dados estruturados de forma idêntica por inúmeras bases de dados independentes. É especialmente popular entre desenvolvedores de nuvem que criam ofertas de Software como Serviço (SAAS) para clientes finais ou empresas. Estes clientes finais são muitas vezes referidos como "inquilinos". O compartilhamento pode ser necessário por vários motivos:

• A quantidade total de dados é muito grande para caber dentro das restrições de um banco de dados individual
• A taxa de transferência de transação da carga de trabalho geral excede os recursos de um banco de dados individual
• Os locatários podem exigir isolamento físico uns dos outros, portanto, bancos de dados separados são necessários para cada locatário
• Diferentes seções de um banco de dados podem precisar residir em diferentes geografias por motivos de conformidade, desempenho ou geopolíticos.

Em outros cenários, como a ingestão de dados de dispositivos distribuídos, a fragmentação pode ser usada para preencher um conjunto de bancos de dados organizados temporalmente. Por exemplo, um banco de dados separado pode ser dedicado a cada dia ou semana. Nesse caso, a chave de fragmentação pode ser um inteiro que representa a data (presente em todas as linhas das tabelas fragmentadas) e as consultas que recuperam informações para um intervalo de datas devem ser roteadas pelo aplicativo para o subconjunto de bancos de dados que cobrem o intervalo em questão.

O compartilhamento funciona melhor quando cada transação em um aplicativo pode ser restrita a um único valor de uma chave de fragmentação. Isso garante que todas as transações sejam locais para um banco de dados específico.

Multilocatário e inquilino único

Alguns aplicativos usam a abordagem mais simples de criar um banco de dados separado para cada locatário. Essa abordagem é o padrão de fragmentação de locatário único que fornece isolamento, capacidade de backup/restauração e dimensionamento de recursos na granularidade do locatário. Com a fragmentação de locatário único, cada banco de dados é associado a um valor de ID de locatário específico (ou valor de chave do cliente), mas essa chave nem sempre precisa estar presente nos próprios dados. É responsabilidade do aplicativo rotear cada solicitação para o banco de dados apropriado - e a biblioteca do cliente pode simplificar isso.

Outros cenários agrupam vários locatários em bancos de dados, em vez de isolá-los em bancos de dados separados. Esse padrão é um padrão típico de fragmentação multilocatária - e pode ser impulsionado pelo fato de que um aplicativo gerencia um grande número de pequenos locatários. Na fragmentação multilocatário, as linhas nas tabelas do banco de dados são todas projetadas para carregar uma chave que identifica a ID do locatário ou a chave de fragmentação. Novamente, a camada de aplicativo é responsável por rotear a solicitação de um locatário para o banco de dados apropriado, e isso pode ser suportado pela biblioteca cliente de banco de dados elástico. Além disso, a segurança em nível de linha pode ser usada para filtrar quais linhas cada locatário pode acessar - para obter detalhes, consulte Aplicativos multilocatários com ferramentas de banco de dados elástico e segurança em nível de linha. A redistribuição de dados entre bancos de dados pode ser necessária com o padrão de fragmentação multilocatário e é facilitada pela ferramenta de mesclagem dividida e de banco de dados elástico. Para saber mais sobre os padrões de estrutura de aplicações SaaS que utilizam conjuntos elásticos, consulte o artigo Padrões de Estrutura de Aplicações SaaS Multi-inquilino com a Base de Dados SQL do Azure.

Mover dados de vários bancos de dados para bancos de dados de locação única

Ao criar um aplicativo SaaS, é comum oferecer aos clientes em potencial uma versão de avaliação do software. Nesse caso, é econômico usar um banco de dados multilocatário para os dados. No entanto, quando um cliente potencial se torna um cliente, um banco de dados de locatário único é melhor, pois oferece melhor desempenho. Se o cliente tiver criado dados durante o período de avaliação, use a ferramenta de mesclagem dividida para mover os dados do multilocatário para o novo banco de dados de locatário único.

Nota

Não é possível restaurar de bancos de dados multilocatários para um único locatário.

Próximos passos

Para obter um aplicativo de exemplo que demonstra a biblioteca do cliente, consulte Introdução às ferramentas do Banco de Dados Elástico.

Para converter bancos de dados existentes para usar as ferramentas, consulte Migrar bancos de dados existentes para dimensionamento.

Para ver as especificidades do pool elástico, consulte Considerações sobre preço e desempenho para um pool elástico ou crie um novo pool com pools elásticos.

Recursos adicionais

Ainda não está usando ferramentas de banco de dados elástico? Consulte o nosso Guia de Introdução. Para dúvidas, entre em contato conosco na página de perguntas e respostas da Microsoft para o Banco de dados SQL e para solicitações de recursos, adicione novas ideias ou vote em ideias existentes no fórum de comentários do Banco de dados SQL.