Movimentação de dados entre bases de dados na cloud em escala reduzida

Aplica-se a:Banco de Dados SQL do Azure

Se é programador de Software como Serviço e, de repente, a sua aplicação sofre uma enorme procura, precisa de acomodar esse crescimento. Por isso, adicionas mais bases de dados (fragmentos). Como é que redistribui os dados para as novas bases de dados sem perturbar a integridade dos dados? Use a ferramenta split-merge para transferir dados de bases de dados restritas para as novas bases de dados.

A ferramenta split-merge corre como um serviço web da Azure. Um administrador ou desenvolvedor usa a ferramenta para mover shardlets (dados de um shard) entre diferentes shards (bases de dados). A ferramenta utiliza gestão de mapas de fragmentos para manter a base de dados de metadados do serviço e garantir mapeamentos consistentes.

Baixar

Microsoft.Azure.SqlDatabase.ElasticScale.Service.SplitMerge

Documentation

1. Implementar um serviço de split-merge para mover dados entre bases de dados fragmentadas
2. Configuração de segurança de divisão-fusão
3. Escalar bases de dados com o gestor de mapas de fragmentos
4. Migrar bases de dados existentes para expandir horizontalmente
5. Escalar com o Azure SQL Database
6. Glossário de ferramentas da Elastic Database

Por que usar a ferramenta split-merge

• Flexibilidade

  As aplicações precisam de se expandir de forma flexível para além dos limites de uma única base de dados no Azure SQL Database. Use a ferramenta para transferir dados conforme necessário para novas bases de dados, mantendo a integridade.

• Dividir para crescer

  Para aumentar a capacidade global de lidar com um crescimento explosivo, criar capacidade adicional através do fragmento dos dados e da sua distribuição por mais bases de dados incrementais até que as necessidades de capacidade sejam satisfeitas. Este é um exemplo perfeito da funcionalidade de divisão .

• Fusão para encolher

  As necessidades de capacidade diminuem devido à natureza sazonal de um negócio. A ferramenta permite-lhe reduzir para menos unidades de capacidade em períodos de abrandamento. A funcionalidade de fusão no Elastic Scale Split-Merge Service cobre este requisito.

• Gerir hotspots movendo fragmentos

  Com múltiplos locatários por base de dados, a atribuição de fragmentos aos shards pode levar a gargalos de capacidade em alguns fragmentos. Isto requer realocar fragmentos ou mover fragmentos ocupados para fragmentos novos ou menos utilizados.

Conceitos e características-chave

• Serviços alojados pelo cliente

  O serviço de "split-merge" é fornecido como um serviço hospedado pelo cliente. Deve implementar e alojar o serviço na sua subscrição Microsoft Azure. O pacote que descarrega do NuGet contém um modelo de configuração para completar com a informação para a sua implementação específica. Consulte o tutorial de split-merge para mais detalhes. Como o serviço corre na sua subscrição Azure, pode controlar e configurar a maioria dos aspetos de segurança do serviço. O modelo padrão inclui opções para configurar TLS, autenticação de cliente baseada em certificados, encriptação para credenciais armazenadas, proteção de negação de serviço (DoS) e restrições de IP. Pode encontrar mais informações sobre os aspetos de segurança no seguinte documento de configuração de segurança de divisão-fusão.

  O serviço implementado por padrão corre com uma instância de trabalho e uma função web. Cada uma utiliza o tamanho da VM A1 no Azure Cloud Services. Embora não possas modificar estas definições ao implementar o pacote, podes alterá-las após uma implementação bem-sucedida no serviço cloud em execução através do portal Azure. O papel de trabalhador não deve ser configurado para mais do que uma única instância.

• Integração de mapas de fragmentos

  O serviço de divisão e fusão interage com o mapa de fragmentos do aplicativo. Ao usar o serviço split-merge para dividir ou mesclar intervalos ou para mover fragmentos entre shards, o serviço mantém automaticamente o mapa do fragmento atualizado. Para tal, o serviço liga-se à base de dados do gestor de mapas de fragmentos da aplicação e mantém intervalos e mapeamentos à medida que os pedidos de divisão/fusão/mudança avançam. Isto garante que o mapa do fragmento apresenta sempre uma vista atualizada quando estão a decorrer operações de divisão-fusão. As operações de divisão, fusão e movimento de fragmentos são implementadas movendo um lote de fragmentos do fragmento de origem para o fragmento alvo. Durante a operação de movimentação dos shardlets, os shardlets sujeitos ao lote atual são identificados como offline no mapa do shard e não estão disponíveis para conexões de roteamento dependentes de dados usando a API OpenConnectionForKey.

• Ligações consistentes de shardlets

  Quando o movimento de dados começa para um novo lote de shardlets, qualquer ligação de roteamento dependente de dados fornecida pelo shard map para o shard que armazena o shardlet é eliminada, e as ligações subsequentes das APIs do shard map para os shardlets são bloqueadas durante o movimento de dados, para evitar inconsistências. As ligações a outros subfragmentos no mesmo fragmento também serão eliminadas, mas terão sucesso imediatamente quando tentarem novamente. Depois de o lote ser movido, os fragmentos são novamente marcados online para o fragmento alvo e os dados de origem são removidos do fragmento de origem. O serviço segue estes passos para cada lote até que todos os "shardlets" (ou fragmentos) tenham sido transferidos. Isto levará a várias operações de encerramento de ligação durante a operação de divisão/fusão/transferência.

• Gerir a disponibilidade de shardlets

  Limitar a perda de ligação ao lote atual de fragmentos, como discutido acima, restringe o alcance da indisponibilidade a um lote de fragmentos de cada vez. Isto é preferido a uma abordagem em que o fragmento completo permaneceria offline para todas as suas subpartições durante o decorrer de uma operação de divisão ou fusão. O tamanho de um lote, definido como o número de fragmentos distintos a mover ao mesmo tempo, é um parâmetro de configuração. Pode ser definido para cada operação de divisão e fusão dependendo da disponibilidade e das necessidades de desempenho da aplicação. O intervalo que está bloqueado no mapa de fragmentos pode ser maior do que o tamanho do lote especificado. Isto porque o serviço escolhe o tamanho do intervalo de modo que o número real de valores-chave de fragmentação nos dados corresponda aproximadamente ao tamanho do lote. Isto é importante lembrar especialmente para chaves de partição pouco utilizadas.

• Armazenamento de metadados

  O serviço de fusão dividida utiliza uma base de dados para manter o seu estado e para guardar registos durante o processamento dos pedidos. O utilizador cria esta base de dados na sua subscrição e fornece a cadeia de ligação no ficheiro de configuração para a implementação do serviço. Os administradores da organização do utilizador também podem aceder a esta base de dados para rever o progresso dos pedidos e investigar informações detalhadas sobre potenciais falhas.

• Consciência de fragmentação

  O serviço split-merge diferencia entre (1) tabelas fragmentadas, (2) tabelas de referência e (3) tabelas normais. A semântica de uma operação de divisão/fusão/movimento depende do tipo da tabela utilizada e é definida da seguinte forma:

  • Mesas fragmentadas

    Operações de dividir, fundir e mover deslocam shardlets do fragmento de origem para o fragmento de destino. Após a conclusão bem-sucedida da solicitação global, esses fragmentos deixam de estar presentes na origem. As tabelas alvo devem existir no fragmento alvo e não devem conter dados dentro do intervalo alvo antes do processamento da operação.

  • Tabelas de referência

    Para tabelas de referência, as operações de divisão, fusão e movimento copiam os dados da fonte para o fragmento de destino. Note-se, no entanto, que não ocorrem alterações no fragmento alvo para uma dada tabela se alguma linha já estiver presente nessa tabela no alvo. A tabela tem de estar vazia para que qualquer operação de cópia da tabela de referência seja processada.

  • Outras tabelas

    Outras tabelas podem estar presentes tanto na origem como no destino de uma operação de divisão e fusão. O serviço de divisão-fusão ignora estas tabelas durante quaisquer transferências de dados ou operações de cópia. Note-se, no entanto, que podem interferir com estas operações em caso de restrições.

    A informação sobre tabelas de referência vs. tabelas fragmentadas é fornecida pelas SchemaInfo APIs no mapa de fragmentos. O exemplo seguinte ilustra a utilização destas APIs num dado objeto gestor de mapas de shard:

    // Create the schema annotations
    SchemaInfo schemaInfo = new SchemaInfo();
    
    // reference tables
    schemaInfo.Add(new ReferenceTableInfo("dbo", "region"));
    schemaInfo.Add(new ReferenceTableInfo("dbo", "nation"));
    
    // sharded tables
    schemaInfo.Add(new ShardedTableInfo("dbo", "customer", "C_CUSTKEY"));
    schemaInfo.Add(new ShardedTableInfo("dbo", "orders", "O_CUSTKEY"));
    
    // publish
    smm.GetSchemaInfoCollection().Add(Configuration.ShardMapName, schemaInfo);
    

    As tabelas region e nation são definidas como tabelas de referência e serão copiadas com operações de divisão/fusão/movimentação. customer e orders , por sua vez, são definidas como tabelas fragmentadas. C_CUSTKEY e O_CUSTKEY serve como chave de fragmentação.

• Integridade referencial

  O serviço split-merge analisa dependências entre tabelas e utiliza relações chave estrangeira-chave primária para organizar as operações de transferência de tabelas de referência e shardlets. Em geral, as tabelas de referência são copiadas primeiro por ordem de dependência, depois os fragmentos são copiados por ordem de dependência dentro de cada lote. Isto é necessário para que as restrições FK-PK no fragmento alvo sejam respeitadas enquanto os novos dados chegam.

• Consistência do mapa de fragmentos e eventual conclusão

  Na presença de falhas, o serviço de divisão-fusão retoma as operações após qualquer interrupção e procura concluir quaisquer pedidos em andamento. No entanto, podem surgir situações irrecuperáveis, por exemplo, quando o fragmento alvo se perde ou fica comprometido para além da reparação. Nessas circunstâncias, alguns fragmentos que deveriam ter sido movidos continuarão a residir no fragmento de origem. O serviço assegura que os mapeamentos dos shardlets só são atualizados depois de os dados necessários terem sido copiados com sucesso para o destino. Os fragmentos de dados só são eliminados no sistema de origem depois de todos os seus dados terem sido copiados para o destino e os mapeamentos terem sido atualizados com sucesso. A operação de eliminação acontece em segundo plano enquanto o campo já está online no fragmento alvo. O serviço de fusão dividida garante sempre a correção dos mapeamentos armazenados no mapa do fragmento.

A interface de utilizador split-merge

O pacote de serviço split-merge inclui uma função de trabalhador e uma função web. A função web é usada para submeter pedidos de divisão/junção de maneira interativa. Os principais componentes da interface de utilizador são os seguintes:

• Tipo de operação

  O tipo de operação é um botão de rádio que controla o tipo de operação realizada pelo serviço para este pedido. Podes escolher entre os cenários de dividir, fundir e mover. Também pode cancelar uma operação previamente submetida. Podes usar pedidos de divisão, fusão e movimento para mapas de fragmentos de distância. Os mapas de fragmentos listados só suportam operações de movimento.

• Mapa de partições

  A secção seguinte dos parâmetros do pedido cobre informações sobre o mapa do fragmento e a base de dados que aloja o seu mapa do fragmento. Em particular, precisa de fornecer o nome do servidor e da base de dados que hospeda o shard map, as credenciais para se ligar à base de dados do shard map, e, finalmente, o nome do shard map. Atualmente, a operação aceita apenas um conjunto de credenciais. Estas credenciais precisam de ter permissões suficientes para realizar alterações ao mapa do shard, bem como aos dados do utilizador nos shards.

• Gama de origem (dividir e juntar)

  Uma operação de divisão e fusão processa um intervalo usando a sua chave inferior e superior. Para especificar uma operação com um valor de high key ilimitado, assinale a caixa "High key is max" e deixe o campo high key vazio. Os valores das chaves de intervalo que especificas não precisam de corresponder precisamente a um mapeamento e aos seus limites no teu mapa de fragmentos. Se não especificar quaisquer limites de alcance, o serviço infere automaticamente o alcance mais próximo para si. Podes usar o script GetMappings.ps1 PowerShell para recuperar os mapeamentos atuais num dado shard map.

• Comportamento da fonte dividida (split)

  Para operações de divisão, defina o ponto a dividir o intervalo de origem. Fazes isto fornecendo a chave de fragmentação onde queres que a divisão ocorra. Use o botão de rádio para especificar se quer que a parte inferior do intervalo de dados (excluindo a chave de divisão) se desloque, ou se quer que a parte superior se desloque (incluindo a chave de divisão).

• Fragmento de origem (movimento)

  As operações de movimento são diferentes das operações de divisão ou fusão porque não requerem um intervalo para descrever a origem. Uma fonte para mover é simplesmente identificada pelo valor-chave de fragmentação que planeias mover.

• Fragmento de alvo (dividido)

  Depois de fornecer a informação sobre a origem da sua operação dividida, precisa de definir para onde quer que os dados sejam copiados, fornecendo o nome do servidor e da base de dados para o destino.

• Alcance de alvo (fusão)

  As operações de fusão movem fragmentos para um fragmento existente. Identificas o fragmento existente fornecendo os limites do intervalo que desejas fundir.

• Tamanho do lote

  O tamanho do lote controla o número de fragmentos que ficam offline durante a movimentação dos dados. Este é um valor inteiro onde pode utilizar valores menores quando estiver preocupado com longos períodos de inatividade para shardlets. Valores maiores aumentam o tempo que um determinado fragmento está offline, mas podem melhorar o desempenho.

• ID da Operação (cancel)

  Se tiver uma operação em curso que já não é necessária, pode cancelá-la fornecendo o seu ID de operação neste campo. Pode obter o ID da operação na tabela de estado do pedido (ver Secção 8.1) ou na saída no navegador web onde submeteu o pedido.

Requisitos e limitações

A implementação atual do serviço de fusão dividida está sujeita aos seguintes requisitos e limitações:

• Os fragmentos precisam de existir e estar registados no mapa do fragmento antes de poder ser realizada uma operação de divisão e fusão nestes fragmentos.
• O serviço não cria tabelas nem quaisquer outros objetos de base de dados automaticamente como parte das suas operações. Isto significa que o esquema para todas as tabelas fragmentadas e tabelas de referência precisa de existir no fragmento alvo antes de qualquer operação de divisão/fusão/movimento. As tabelas fragmentadas, em particular, devem estar vazias no intervalo onde novos fragmentos devem ser adicionados através de uma operação de divisão/fusão/movimento. Caso contrário, a operação falhará a verificação inicial de consistência no fragmento alvo. Note-se também que os dados de referência só são copiados se a tabela de referência estiver vazia e que não existem garantias de consistência relativamente a outras operações de escrita concorrentes nas tabelas de referência. Recomendamos isto: ao executar operações de divisão/fusão, nenhuma outra operação de escrita faz alterações nas tabelas de referência.
• O serviço baseia-se numa identidade de linha estabelecida por um índice ou chave única que inclui a chave de fragmentação para melhorar o desempenho e a fiabilidade de shardlets grandes. Isto permite ao serviço mover dados com uma granularidade ainda mais fina do que apenas o valor da chave de fragmentação. Isto ajuda a reduzir a quantidade máxima de espaço de log e bloqueios necessários durante a operação. Considera criar um índice único ou uma chave primária incluindo a chave de fragmentação numa dada tabela se quiseres usar essa tabela com pedidos de divisão/fusão/mudança. Por razões de desempenho, a chave de fragmentação deve ser a coluna inicial da chave ou do índice.
• Durante o processamento de pedidos, alguns dados de shardlets podem estar presentes tanto na shard de origem quanto na shard de destino. Isto é necessário para proteger contra falhas durante o movimento dos shardlets. A integração do split-merge com o mapa de fragmentos garante que as ligações através das APIs de roteamento dependentes de dados, usando o método OpenConnectionForKey no mapa de fragmentos, não encontrem estados intermédios inconsistentes. No entanto, ao ligar-se à origem ou aos shards de destino sem usar o método OpenConnectionForKey , estados intermédios inconsistentes podem ser visíveis quando há pedidos de divisão/fusão/movimento. Essas conexões podem apresentar resultados parciais ou duplicados, dependendo do tempo ou do fragmento subjacente à conexão. Esta limitação inclui atualmente as ligações feitas pelo Elastic Scale Multi-Shard-Queries.
• A base de dados de metadados para o serviço de separação-fusão não deve ser partilhada entre diferentes funções. Por exemplo, uma função do serviço de divisão-fusão a funcionar em ambiente de teste precisa de apontar para uma base de dados de metadados diferente da função de produção.

Billing

O serviço split-merge corre como um serviço cloud na sua subscrição Microsoft Azure. Por isso, as cobranças pelos serviços cloud aplicam-se à sua instância do serviço. A menos que realize frequentemente operações de divisão/mistura/movimentação, recomendamos que elimine o seu serviço de nuvem de split-merge. Isso poupa custos na execução ou implementação de instâncias de serviços cloud. Pode reimplantar e iniciar a sua configuração facilmente executável sempre que precisar de realizar operações de divisão ou fusão.

Monitorização

Tabelas de estado

O Serviço de Divisão-Fusão fornece a tabela RequestStatus na base de dados da loja de metadados para monitorização de pedidos concluídos e em andamento. A tabela lista uma linha para cada pedido de fusão dividida que tenha sido submetida a esta instância do serviço de fusão dividida. Fornece a seguinte informação para cada pedido:

• Marca temporal

  A hora e a data em que o pedido foi iniciado.

• OperationId

  Um GUID que identifica de forma única o pedido. Este pedido também pode ser usado para cancelar a operação enquanto ainda está em curso.

• Situação

  O estado atual do pedido. Para pedidos em curso, também indica a fase atual em que o pedido se encontra.

• CancelRequest

  Uma bandeira que indica se o pedido foi cancelado.

• Progress

  Uma estimativa percentual de conclusão da operação. Um valor de 50 indica que a operação está aproximadamente 50% concluída.

• Detalhes

  Um valor XML que fornece um relatório de progresso mais detalhado. O relatório de progresso é atualizado periodicamente à medida que conjuntos de linhas são copiados da fonte para o destino. Em caso de falhas ou exceções, esta coluna inclui também informações mais detalhadas sobre a falha.

Diagnóstico do Azure

O serviço split-merge utiliza o Azure Diagnostics baseado no Azure SDK 2.5 para monitorização e diagnóstico. Para controlar a configuração do diagnóstico, consulte Ativar Diagnósticos em Azure Cloud Services and Virtual Machines. O pacote de download inclui duas configurações de diagnóstico – uma para a função web e outra para a função de trabalhador. Inclui as definições para registar contadores de desempenho, registos IIS, registos de eventos do Windows e registos de eventos de aplicação split-merge.

Diagnósticos de Implementação

Para permitir a monitorização e o diagnóstico usando a configuração de diagnóstico para os roles web e worker fornecidos pelo pacote NuGet, execute os seguintes comandos utilizando o Azure PowerShell:

$storageName = "<azureStorageAccount>"
$key = "<azureStorageAccountKey"
$storageContext = New-AzStorageContext -StorageAccountName $storageName -StorageAccountKey $key
$configPath = "<filePath>\SplitMergeWebContent.diagnostics.xml"
$serviceName = "<cloudServiceName>"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWeb"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWorker"

Para mais informações sobre como configurar e implementar definições de diagnóstico, consulte Ativar Diagnósticos em Azure Cloud Services and Virtual Machines.

Obter diagnósticos

Pode aceder facilmente aos seus diagnósticos a partir do Visual Studio Server Explorer, na parte Azure da árvore Server Explorer.

1. Abre uma instância do Visual Studio e, na barra de menus, seleciona Visualizar e Explorador de Servidores.
2. Selecione o ícone Azure para se ligar à sua subscrição Azure.
3. Navegar até Azure ->Storage -><your storage account> -> Tabelas ->WADLogsTable.

Para mais informações, consulte Server Explorer.

A WADLogsTable destacada na figura acima contém os eventos detalhados do registo de aplicações do serviço de fusão dividida. A configuração padrão do pacote descarregado está orientada para uma implementação em produção. Portanto, o intervalo em que os registos e contadores são retirados das instâncias de serviço é grande (5 minutos). Para testes e desenvolvimento, reduza o intervalo ajustando as definições de diagnóstico da web ou do papel do trabalhador às suas necessidades. Clique com o botão direito na função no Visual Studio Server Explorer (ver acima) e depois ajuste o Período de Transferência na janela de diálogo para as definições de Diagnóstico:

Performance

Em geral, espera-se melhor desempenho de níveis de serviço superiores e mais performantes. Alocações mais elevadas de IO, CPU e memória nas camadas de serviço mais altas beneficiam as operações de cópia e eliminação em massa utilizadas pelo serviço de divisão e junção. Por essa razão, aumente o nível de serviço apenas para essas bases de dados por um período definido e limitado.

O serviço também realiza consultas de validação como parte das suas operações normais. Estas consultas de validação verificam a presença inesperada de dados no intervalo alvo e garantem que qualquer operação de divisão/fusão/movimentação começa a partir de um estado consistente. Estas consultas trabalham todas sobre intervalos de chaves de fragmentação definidos pelo âmbito da operação e pelo tamanho do lote fornecido como parte da definição do pedido. Estas consultas têm melhor desempenho quando existe um índice que tem a chave de fragmentação como coluna inicial.

Além disso, uma propriedade de unicidade com a chave de fragmentação como coluna inicial permitirá ao serviço usar uma abordagem otimizada que limita o consumo de recursos em termos de espaço logarítmico e memória. Esta propriedade de unicidade é necessária para mover grandes tamanhos de dados (tipicamente acima de 1GB).

Como atualizar

1. Siga os passos em Implementar um serviço de junção dividida para mover dados entre bases de dados fragmentadas.
2. Altere o ficheiro de configuração do seu serviço cloud para a sua implementação de split-merge para refletir os novos parâmetros de configuração. Um novo parâmetro obrigatório é a informação sobre o certificado utilizado para encriptação. Uma forma simples de o fazer é comparar o novo ficheiro modelo de configuração do download com a sua configuração atual. Certifica-te de que adicionas as definições para DataEncryptionPrimaryCertificateThumbprint e DataEncryptionPrimary tanto para a função web como para a função de trabalhador.
3. Antes de implementar a atualização no Azure, certifique-se de que todas as operações de split-merge atualmente em execução terminaram. Pode facilmente fazer isto consultando as tabelas RequestStatus e PendingWorkflows na base de dados de metadados split-merge para pedidos em curso.
4. Atualize a implementação existente do seu serviço de cloud na subscrição do Azure para split-merge, utilizando o novo pacote e o ficheiro de configuração de serviço atualizado.

Não precisas de criar uma nova base de dados de metadados para split-merge para atualizar. A nova versão irá atualizar automaticamente a sua base de dados de metadados existente para a nova versão.

Práticas recomendadas e solução de problemas

• Defina um inquilino de teste e realize as operações de divisão, fusão e transferência mais importantes com o inquilino de teste em vários shards. Garante que todos os metadados estão corretamente definidos no teu shard map e que as operações não violam restrições ou chaves estrangeiras.
• Mantenha o tamanho dos dados do cliente de teste acima do tamanho máximo do seu maior cliente para garantir que não enfrenta problemas relacionados com o tamanho dos dados. Isto ajuda-o a estimar o tempo máximo que demora para mover um único inquilino.
• Certifica-te de que o teu esquema permite eliminações. O serviço split-merge requer a capacidade de remover dados do fragmento de origem depois de os dados terem sido copiados com sucesso para o destino. Por exemplo, os gatilhos de eliminação podem impedir que o serviço apague os dados na origem e podem causar falhas nas operações.
• A chave de fragmentação deve ser a coluna inicial na definição da chave primária ou do índice único. Isto garante o melhor desempenho para as consultas de validação de divisão ou fusão, bem como para as operações reais de movimentação e eliminação de dados que operam sempre sobre intervalos de chaves de fragmentação.
• Coloque o seu serviço de fusão dividida na região e no centro de dados onde se encontram as suas bases de dados.

Conteúdo relacionado

Ainda não usas ferramentas de base de dados elásticas? Consulte o nosso Guia para Começar. Para perguntas, contacte-nos na página de perguntas e respostas da Microsoft para o SQL Database e para pedidos de funcionalidades, adicione novas ideias ou vote em ideias existentes no fórum de feedback do SQL Database.