Expandir com o Banco de Dados SQL do Azure

Aplica-se a: do Banco de Dados SQL do Azure

Você pode expandir facilmente 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 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 Elastic Database: A biblioteca de cliente é um recurso que permite criar e manter bancos de dados fragmentados. Consulte Introdução ao Elastic Database Tools.
• Mover dados entre bancos de dados em nuvem escalonados: move dados entre bancos de dados particionados. Esta ferramenta é útil para mover dados de um banco de dados multicliente para um banco de dados de cliente único (ou vice-versa). Consulte e implante um serviço de divisão e fusão para mover dados entre bases de dados fragmentadas.
• Trabalhos elásticos no Banco de Dados SQL do Azure: 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, gestão de credenciais, atualizações de dados de referência, coleta de dados de desempenho ou coleta de telemetria de locatário (cliente) usando tarefas.
• Visão geral da consulta elástica do Banco de Dados SQL do Azure (visualização) (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 distribuídas entre bancos de dados na nuvem: 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 o ADO .NET e integram-se à experiência de programação familiar usando as classes System.Transaction.

O gráfico a seguir mostra uma arquitetura que inclui os recursos Elastic Database 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 cliente do Elastic Database é usada para gerir um conjunto de fragmentos.
3. Um subconjunto dos bancos de dados é colocado em um pool elástico .
4. Uma tarefa do Elastic Database executa scripts T-SQL em todos os bancos de dados.
5. A ferramenta de mesclagem dividida é usada para mover dados de um fragmento para outro.
6. O de consulta do Banco de Dados Elástico permite escrever uma consulta que abrange todos os bancos de dados do conjunto de shards.
7. transações elásticas permitem executar transações que abrangem várias bases de dados.

Porquê utilizar as ferramentas?

Alcançar elasticidade e escala para aplicativos em nuvem é 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 com estado em bases de dados relacionais. Desafios surgiram nestes cenários:

• Aumento e diminuição da capacidade para a parte do banco de dados relacional da sua carga de trabalho.
• Gerir pontos críticos que podem surgir e afetar um subconjunto específico de dados - como um cliente final ocupado (inquilino).

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.

Escalonamento 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 horizontal". O sharding, 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.

Partilha

Sharding é uma técnica para distribuir grandes quantidades de dados estruturados de forma idêntica em muitos bancos 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 processamento de transações da carga de trabalho global excede as características 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
• Seções diferentes de um banco de dados podem precisar residir em geografias diferentes por motivos de conformidade, desempenho ou geopolítica.

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 para um único locatário que fornece isolamento, capacidade para backup e restauração, e dimensionamento de recursos na granularidade do locatário. Com a fragmentação para um único inquilino, cada base de dados é associada a um valor de ID de inquilino específico (ou valor de chave do cliente), mas essa chave não precisa estar presente nos dados propriamente ditos. É responsabilidade do aplicativo rotear cada solicitação para o banco de dados apropriado - e a biblioteca do cliente pode simplificar essa tarefa.

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ário - 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 o 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 aplicações multicliente 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 do banco de dados elástico. Para saber mais sobre padrões de projeto para aplicativos SaaS usando pools elásticos, consulte Padrões de utilização de banco de dados para SaaS de multilocação.

Mover dados de bancos de dados múltiplos para um banco 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 criar 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.

Observação

Não é possível restaurar de bases de dados multiclientes para um único cliente.

Exemplos e tutoriais

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 expandir.

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

Conteúdo relacionado

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