Recomendações para particionamento de dados

Artigo
07/03/2024

Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:

RE:06	Implemente uma estratégia de dimensionamento oportuna e confiável nos níveis de aplicativo, dados e infraestrutura.

Guia relacionado: Dimensionamento

Este guia descreve as recomendações para projetar uma estratégia de particionamento de dados para o banco de dados e a tecnologia de armazenamento de dados que você implanta. Esta estratégia ajuda-o a melhorar a fiabilidade do seu património de dados.

Principais estratégias de design

Em muitas soluções de grande escala, as partições são usadas para dividir dados para que possam ser gerenciados e acessados separadamente. O particionamento de dados melhora a escalabilidade, reduz a contenção e otimiza o desempenho. Implemente o particionamento de dados para dividir os dados por padrão de uso. Por exemplo, você pode arquivar dados mais antigos em armazenamento de dados barato. Escolha cuidadosamente a sua estratégia de particionamento para maximizar os benefícios e minimizar os efeitos adversos.

Nota

Neste artigo, o termo criação de partições significa o processo de dividir fisicamente os dados em arquivos de dados separados. Ele difere do particionamento de tabela do SQL Server.

Você pode particionar dados para:

Melhorar a escalabilidade. Quando você dimensiona um único sistema de banco de dados, o banco de dados eventualmente atinge um limite de hardware físico. Se você dividir os dados em várias partições, com cada partição hospedada em um servidor separado, poderá expandir o sistema quase indefinidamente.
Melhorar o desempenho. Em cada partição, as operações de acesso a dados são executadas em um volume menor de dados em comparação com os dados que não são particionados. Particione dados para tornar o seu sistema mais eficiente. As operações que afetam mais do que uma partição podem ser executadas em paralelo.
Melhorar a segurança. Em alguns casos, você pode separar dados confidenciais e não confidenciais em partições diferentes e aplicar controles de segurança diferentes aos dados confidenciais.
Fornecer flexibilidade operacional. Você pode particionar dados para ajustar operações, maximizar a eficiência administrativa e minimizar custos. Por exemplo, você pode definir estratégias para gerenciamento, monitoramento, backup e restauração e outras tarefas administrativas com base na importância dos dados em cada partição.
Corresponder o arquivo de dados ao padrão de utilização. Você pode implantar cada partição em um tipo diferente de armazenamento de dados com base no custo e nos recursos internos que o armazenamento de dados oferece. Por exemplo, você pode armazenar grandes dados binários no armazenamento de blob e armazenar dados estruturados em um banco de dados de documentos. Para obter mais informações, consulte Compreender modelos de armazenamento de dados.
Melhorar a disponibilidade. Para evitar um único ponto de falha, você pode separar dados em vários servidores. Se uma instância falhar, apenas os dados nessa partição não estarão disponíveis. As operações continuam em outras partições. Essa consideração é menos relevante para armazenamentos de dados de plataforma gerenciada como serviço (PaaS) porque eles têm redundância interna.

Selecione a estratégia de particionamento correta

Existem três estratégias típicas para particionar dados:

Criação de partições horizontais (frequentemente denominado fragmentação). Nessa estratégia, cada partição é um armazenamento de dados separado, mas todas as partições têm o mesmo esquema. Cada partição é conhecida como fragmento e contém um subconjunto dos dados, como um conjunto de pedidos de clientes.
Criação de partições verticais. Nesta estratégia, cada partição contém um subconjunto dos campos para os itens no arquivo de dados. Os campos são divididos de acordo com o respetivo padrão de utilização. Por exemplo, os campos acedidos frequentemente podem ser colocados numa partição vertical e os campos acedidos com menos frequência podem ser colocados noutra.
Criação de partições funcionais. Nessa estratégia, os dados são agregados de acordo com a forma como cada contexto delimitado no sistema usa os dados. Por exemplo, um sistema de comércio eletrônico pode armazenar dados de fatura em uma partição e dados de inventário de produtos em outra.

Considere combinar essas estratégias ao projetar um esquema de particionamento. Por exemplo, pode dividir os dados em partições horizontais e, em seguida, utilizar a criação de partições verticais para subdividir os dados de cada partição horizontal.

Criação de partições horizontais (fragmentação)

A imagem a seguir mostra um exemplo de particionamento horizontal ou fragmentação. Este exemplo divide os dados de inventário de produtos em fragmentos baseados na chave do produto. Cada partição horizontal contém os dados para um intervalo contínuo de chaves de partição horizontal (A-G e H-Z), organizadas por ordem alfabética. Quando você executa a fragmentação, ela distribui a carga por mais computadores, o que reduz a contenção e melhora o desempenho.

O fator mais importante é a chave de fragmentação que você escolher. Pode ser difícil alterar a chave depois de o sistema estar em funcionamento. A chave deve garantir que os dados sejam particionados para distribuir a carga de trabalho da forma mais uniforme possível pelos fragmentos.

Os estilhaços não precisam ter o mesmo tamanho. É mais importante equilibrar o número de solicitações. Alguns fragmentos podem ser grandes, mas cada item no fragmento tem um número baixo de operações de acesso. Outros fragmentos podem ser menores, mas cada item no fragmento é acessado com mais frequência. Também é importante garantir que um único fragmento não exceda os limites de escala, em termos de capacidade e recursos de processamento, do armazenamento de dados.

Evite criar partições quentes que podem afetar o desempenho e a disponibilidade. Por exemplo, se você usar a primeira letra do nome de um cliente, isso pode criar uma distribuição desequilibrada porque algumas letras são mais comuns do que outras. Em vez disso, use um hash de identificador de cliente para distribuir dados uniformemente entre partições.

Escolha uma chave de fragmentação que minimize a necessidade futura de dividir fragmentos grandes, combinar fragmentos pequenos em partições maiores ou alterar o esquema. Essas operações são demoradas e podem exigir que você coloque um ou mais fragmentos offline.

Se os fragmentos forem replicados, você poderá manter algumas das réplicas online enquanto outras serão divididas, mescladas ou reconfiguradas. No entanto, o sistema pode limitar as operações que podem ser executadas durante a reconfiguração. Por exemplo, os dados nas réplicas podem ser marcados como somente leitura para evitar inconsistências de dados.

Para obter mais informações, veja Sharding pattern (Padrão de fragmentação).

Criação de partições verticais

O uso mais comum para particionamento vertical é reduzir os custos de E/S e desempenho associados à busca de itens acessados com frequência. A imagem a seguir mostra um exemplo de particionamento vertical. Neste exemplo, diferentes propriedades de um item são armazenadas em partições diferentes. Uma partição contém dados que são acessados com mais frequência, incluindo nome do produto, descrição e preço. Outra partição contém dados de inventário, incluindo a contagem de estoque e a data do último pedido.

Neste exemplo, o aplicativo consulta regularmente o nome, a descrição e o preço do produto quando exibe os detalhes do produto aos clientes. A contagem de estoque e a data do último pedido estão em uma partição separada porque esses dois itens são comumente usados juntos.

Veja as seguintes vantagens do particionamento vertical:

Você pode separar dados relativamente lentos (nome do produto, descrição e preço) de dados mais dinâmicos (nível de estoque e data do último pedido). Dados em movimento lento são um bom candidato para um aplicativo armazenar em cache na memória.
Você pode armazenar dados confidenciais em uma partição separada com controles de segurança adicionados.
O particionamento vertical pode reduzir a quantidade de acesso simultâneo necessária.

A criação de partições verticais funciona ao nível da entidade dentro de um arquivo de dados, normalizando parcialmente uma entidade para a dividir, de um item amplo para um conjunto de itens estreitos. É ideal para armazenamentos de dados orientados a colunas, como HBase e Cassandra. Se for improvável que os dados em uma coleção de colunas sejam alterados, considere o uso de repositórios de colunas no SQL Server.

Criação de partições funcionais

Quando um contexto delimitado pode ser identificado para cada área de negócios distinta em um aplicativo, o particionamento funcional pode melhorar o isolamento e o desempenho do acesso a dados. Outro uso comum para particionamento funcional é separar dados de leitura-gravação de dados somente leitura. A imagem a seguir mostra uma visão geral do particionamento funcional com dados de inventário separados dos dados do cliente.

Esta estratégia de criação de partições pode ajudar a reduzir a contenção do acesso aos dados nas diferentes partes de um sistema.

Projetar partições para escalabilidade

É vital considerar o tamanho e a carga de trabalho de cada partição. Equilibre-os para que os dados sejam distribuídos para alcançar a máxima escalabilidade. No entanto, você também deve particionar os dados para que eles não excedam os limites de dimensionamento de um único armazenamento de partição.

Siga estas etapas ao projetar partições para escalabilidade:

Analise o aplicativo para entender os padrões de acesso a dados, como o tamanho do conjunto de resultados que cada consulta retorna, a frequência de acesso, a latência inerente e os requisitos de processamento de computação do lado do servidor. Em muitos casos, algumas grandes entidades exigem a maioria dos recursos de processamento.
Use essa análise para determinar as metas de escalabilidade atuais e futuras, como o tamanho dos dados e a carga de trabalho. Em seguida, distribua os dados pelas partições para ir de encontro à meta de escalabilidade. Para particionamento horizontal, escolha a chave de estilhaço certa para garantir uma distribuição uniforme. Para obter mais informações, veja Sharding pattern (Padrão de fragmentação).
Certifique-se de que cada partição tenha recursos suficientes para lidar com os requisitos de escalabilidade em termos de tamanho e taxa de transferência de dados. Dependendo do armazenamento de dados, pode haver um limite para cada partição na quantidade de espaço de armazenamento, poder de processamento ou largura de banda de rede. Se for provável que os requisitos excedam esses limites, talvez seja necessário refinar sua estratégia de particionamento ou dividir ainda mais os dados. Pode ser necessário combinar duas ou mais estratégias.
Monitore o sistema para verificar se os dados são distribuídos conforme o esperado e se as partições podem lidar com a carga. O uso real nem sempre corresponde ao que uma análise prevê. Você pode ter que reequilibrar as partições ou redesenhar algumas partes do sistema para produzir o equilíbrio necessário.

Alguns ambientes de nuvem alocam recursos com base nos limites de infraestrutura. Certifique-se de que os limites do limite selecionado forneçam espaço suficiente para o crescimento previsto em volume de dados, armazenamento de dados, poder de processamento e largura de banda.

Por exemplo, se você usar o Armazenamento de Tabela do Azure, há um limite para o volume de solicitações que uma única partição pode manipular em um determinado período de tempo. Para obter mais informações, consulte Metas de escalabilidade e desempenho para contas de armazenamento padrão. Um fragmento ocupado pode exigir mais recursos do que uma única partição pode suportar. Talvez seja necessário reparticionar o fragmento para espalhar a carga. Se o tamanho total ou a taxa de transferência dessas tabelas exceder a capacidade de uma conta de armazenamento, talvez seja necessário criar mais contas de armazenamento e distribuir as tabelas por essas contas.

Projetar partições para desempenho de consulta

Você pode aumentar o desempenho da consulta usando pequenos conjuntos de dados e executando consultas paralelas. Cada partição deve conter uma pequena proporção de todo o conjunto de dados. Esta redução de volume pode melhorar o desempenho das consultas. No entanto, o particionamento não é uma alternativa ao design e à configuração adequados do banco de dados. Certifique-se de implementar os índices necessários.

Siga estas etapas ao criar partições para desempenho de consulta:

Examine os requisitos e o desempenho do aplicativo.
- Use os requisitos de negócios para determinar as consultas críticas que sempre devem ser executadas rapidamente.
- Monitore o sistema para identificar consultas com desempenho lento.
- Determine as consultas executadas com mais frequência. Mesmo que uma única consulta tenha um custo mínimo, o consumo cumulativo de recursos pode ser significativo.
Particione os dados que estão causando desempenho lento.
- Limite o tamanho de cada partição de forma a que o tempo de resposta de consulta esteja dentro da meta.
- Se você usar particionamento horizontal, projete a chave de estilhaço para que o aplicativo possa selecionar facilmente a partição apropriada. Essa especificação impede que a consulta verifique todas as partições.
- Considere a localização de uma partição. Tente manter os dados em partições geograficamente próximas dos aplicativos e usuários que os acessam.
Se uma entidade tiver requisitos de desempenho de taxa de transferência e consulta, use o particionamento funcional baseado nessa entidade. Se essa alocação ainda não atender aos requisitos, você poderá adicionar particionamento horizontal. Uma única estratégia de particionamento geralmente é adequada, mas, em alguns casos, é mais eficiente combinar ambas as estratégias.
Execute consultas em paralelo entre partições para melhorar o desempenho.

Projetar partições para disponibilidade

Particione dados para melhorar a disponibilidade de aplicativos. O particionamento garante que todo o conjunto de dados não tenha um único ponto de falha, e você pode gerenciar de forma independente subconjuntos individuais do conjunto de dados.

Considere os seguintes fatores que afetam a disponibilidade:

Determine a criticidade dos dados. Identifique os dados críticos de negócios, como transações, e os dados operacionais menos críticos, como arquivos de log.

Armazene dados críticos em partições altamente disponíveis e crie um plano de backup apropriado.
Estabelecer procedimentos separados de gestão e monitorização para diferentes conjuntos de dados.
Coloque os dados que têm o mesmo nível de criticidade na mesma partição para que possam ser copiados na mesma frequência. Por exemplo, talvez seja necessário fazer backup de partições que armazenam dados de transação com mais frequência do que partições que contêm informações de log ou rastreamento.

Gerencie partições individuais. Projete partições para suportar a gestão e manutenção independentes. Esta prática proporciona várias vantagens, por exemplo:

Se uma partição falhar, ela pode ser recuperada independentemente sem aplicativos que acessam dados em outras partições.
O particionamento de dados por área geográfica permite que as tarefas de manutenção programadas ocorram fora do horário de pico para cada local. Certifique-se de que as partições não são tão grandes que impeçam a manutenção planejada de terminar durante esse período.

Replique dados críticos entre partições. Essa estratégia melhora a disponibilidade e o desempenho, mas também pode introduzir problemas de consistência. Leva tempo para sincronizar as alterações com cada réplica. Durante a sincronização, partições diferentes contêm valores de dados diferentes.

Otimizar o código do aplicativo para usar partições

O particionamento adiciona complexidade ao design e desenvolvimento do seu sistema. Particione dados como uma parte fundamental do design do seu sistema, mesmo que o sistema inicialmente contenha apenas uma única partição. Se você abordar o particionamento como uma reflexão posterior, é um desafio, porque você já tem um sistema ativo para manter. Você pode:

Tem que modificar a lógica de acesso aos dados.
Tem que migrar grandes quantidades de dados existentes para distribuí-los entre partições.
Enfrente desafios porque os usuários esperam continuar usando o sistema durante a migração.

Em alguns casos, o particionamento não é importante porque o conjunto de dados inicial é pequeno e um único servidor pode lidar facilmente com ele. Algumas cargas de trabalho podem ficar sem partições, mas muitos sistemas comerciais precisam se expandir à medida que o número de usuários aumenta.

Alguns pequenos armazenamentos de dados também se beneficiam do particionamento. Por exemplo, centenas de clientes simultâneos podem acessar um pequeno armazenamento de dados. Se você particionar os dados nessa situação, isso pode ajudar a reduzir a contenção e melhorar a taxa de transferência.

Ao estruturar um esquema de partições de dados, considere os seguintes pontos:

Minimize as operações de acesso a dados entre partições. Tente manter os dados das operações de banco de dados mais comuns juntos em uma partição para minimizar as operações de acesso a dados entre partições. Pode ser mais demorado consultar entre partições em vez de consultar dentro de uma única partição. Mas a otimização de partições para um conjunto de consultas pode afetar negativamente outros conjuntos de consultas. Se você precisar consultar entre partições, minimize o tempo de consulta executando consultas paralelas e agregando os resultados dentro do aplicativo. Em alguns casos, você não pode usar essa abordagem, por exemplo, se o resultado de uma consulta for usado na próxima consulta.

Replicar dados de referência estáticos. Se as consultas usarem dados de referência relativamente estáticos, como tabelas de código postal ou listas de produtos, considere replicar esses dados em todas as partições para reduzir operações de pesquisa separadas em partições diferentes. Essa abordagem também pode reduzir a probabilidade de os dados de referência se tornarem um conjunto de dados ativo com tráfego intenso de todo o sistema. Existem custos adicionais associados à sincronização de alterações aos dados de referência.

Minimize as junções entre partições. Sempre que possível, minimize os requisitos de integridade referencial através de partições verticais e funcionais. Nesses esquemas, o aplicativo é responsável por manter a integridade referencial entre partições. As consultas que unem dados em várias partições são ineficientes porque o aplicativo normalmente executa consultas consecutivas baseadas em uma chave e, em seguida, em uma chave estrangeira. Em vez disso, considere replicar ou anular a normalização dos dados relevantes. Se forem necessárias junções entre partições, execute consultas paralelas nas partições e junte os dados dentro do aplicativo.

Adote a consistência eventual. Avalie se uma forte consistência é um requisito. Uma abordagem comum em sistemas distribuídos é implementar consistência eventual. Os dados em cada partição são atualizados separadamente e a lógica do aplicativo garante que as atualizações sejam concluídas com êxito. A lógica do aplicativo também lida com as inconsistências que surgem da consulta de dados enquanto uma operação eventualmente consistente é executada.

Considere a forma como as consultas localizam a partição correta. Se uma consulta precisar verificar todas as partições para localizar os dados necessários, isso afetará significativamente o desempenho, mesmo quando várias consultas paralelas forem executadas. Com particionamento vertical e funcional, as consultas podem especificar a partição. Por outro lado, o particionamento horizontal pode dificultar a localização de um item porque cada fragmento tem o mesmo esquema. Uma solução típica é manter um mapa que é usado para procurar a localização do fragmento dos itens. Implemente esse mapa na lógica de fragmentação do aplicativo. Ele também pode ser mantido pelo armazenamento de dados se o armazenamento de dados suportar fragmentação transparente.

Reequilibre os fragmentos periodicamente. Com o particionamento horizontal, o rebalanceamento de fragmentos pode ajudar a distribuir uniformemente os dados por tamanho e carga de trabalho. Reequilibre fragmentos para minimizar pontos de acesso, maximizar o desempenho da consulta e contornar limitações de armazenamento físico. Esta tarefa é complexa e muitas vezes requer uma ferramenta ou processo personalizado.

Replicar partições. Replique cada partição para fornecer proteção adicional contra falhas. Se uma única réplica falhar, as consultas serão direcionadas para uma cópia de trabalho.

Estenda a escalabilidade para um nível diferente. Se atingir os limites físicos de uma estratégia de criação de partições, poderá ter de expandir a escalabilidade para um nível diferente. Por exemplo, se estiver a criar partições ao nível de base de dados, poderá ter de localizar ou replicar partições em várias bases de dados. Se o particionamento já estiver no nível do banco de dados e houver limitações físicas, talvez seja necessário localizar ou replicar partições em várias contas de hospedagem.

Evite as transações que acedem a dados em várias partições. Alguns armazenamentos de dados implementam consistência e integridade transacionais para operações que modificam dados, mas somente quando os dados estão localizados em uma única partição. Se você precisar de suporte transacional em várias partições, implemente-o como parte da lógica do seu aplicativo, pois a maioria dos sistemas de particionamento não fornece suporte nativo.

Todos os arquivos de dados requerem alguma gestão operacional e monitorização da atividade. Essas tarefas incluem carregar dados, fazer backup e restaurar dados, reorganizar dados e garantir que o sistema funcione corretamente e com eficiência.

Considere os seguintes fatores que afetam a gestão operacional:

Implementar tarefas operacionais e de gerenciamento apropriadas quando os dados forem particionados. Estas tarefas podem incluir fazer cópia de segurança e restaurar, arquivar dados, monitorizar o sistema e outras tarefas administrativas. Por exemplo, pode ser um desafio manter a consistência lógica durante as operações de backup e restauração.
Carregue dados em várias partições e adicione novos dados provenientes de outras fontes. Algumas ferramentas e utilitários podem não suportar operações de dados fragmentados, como carregar dados na partição correta.
Arquive e apague dados regularmente. Para evitar o crescimento excessivo de partições, arquive e exclua dados todos os meses. Talvez seja necessário transformar os dados para corresponder a um esquema de arquivamento diferente.
Localize problemas de integridade de dados. Considere a execução de um processo periódico para localizar problemas de integridade de dados, como dados em uma partição que fazem referência a informações ausentes em outra. O processo pode tentar corrigir automaticamente esses problemas ou gerar um relatório para revisão manual.

Reequilibrar partições

À medida que um sistema amadurece, você pode ter que ajustar o esquema de particionamento. Por exemplo, partições individuais podem começar a receber um volume desproporcional de tráfego e tornar-se quentes, levando a uma contenção excessiva. Ou você pode ter subestimado o volume de dados em algumas partições, o que faz com que as partições se aproximem dos limites de capacidade.

Alguns armazenamentos de dados, como o Azure Cosmos DB, podem reequilibrar partições automaticamente. Em outros casos, você pode reequilibrar partições em dois estágios:

Determine uma nova estratégia de particionamento.
- Quais partições precisam ser divididas ou combinadas?
- Qual é a nova chave de partição?
Migre dados do esquema de particionamento antigo para o novo conjunto de partições.

Talvez seja necessário tornar as partições indisponíveis enquanto realoca dados, o que é chamado de migração offline. Dependendo do armazenamento de dados, você pode migrar dados entre partições enquanto elas estão em uso. Essa técnica é chamada de migração online.

Migração offline

A migração offline reduz a chance de ocorrência de contenção. Para executar a migração offline:

Marque a partição como offline. Você pode marcar uma partição como somente leitura para que os aplicativos ainda possam ler os dados enquanto você a move.
Divida-mescle e mova os dados para as novas partições.
Verify the data.
Coloque as novas partições online.
Remova a partição antiga.

Migração online

A migração on-line é mais complexa, mas menos perturbadora em comparação com a migração off-line. O processo é semelhante à migração offline, mas você não marca a partição original como offline. Dependendo da granularidade do processo de migração, por exemplo, item por item versus fragmento por estilhaço, o código de acesso a dados nos aplicativos cliente pode ter que ler e gravar dados que estão em dois locais, a partição original e a nova partição.

Facilitação do Azure

As seções a seguir descrevem recomendações para particionar dados armazenados nos serviços do Azure.

Partição no Banco de Dados SQL do Azure

Uma única base de dados SQL tem um limite para o volume de dados que pode conter. O débito é limitado por fatores de arquitetura e pelo número de ligações simultâneas que suporta.

Os pools elásticos oferecem suporte ao dimensionamento horizontal para um banco de dados SQL. Use pools elásticos para particionar seus dados em fragmentos espalhados por vários bancos de dados SQL. Você também pode adicionar ou remover fragmentos à medida que o volume de dados cresce e diminui. Os pools elásticos também podem ajudar a reduzir a contenção distribuindo a carga entre bancos de dados.

Cada partição horizontal é implementada como uma base de dados SQL. Um fragmento pode conter mais de um conjunto de dados. Cada conjunto de dados é chamado de shardlet. Cada banco de dados tem metadados que descrevem os shardlets que ele contém. Um shardlet pode ser um único item de dados ou um grupo de itens que compartilham a mesma chave de shardlet. Por exemplo, em um aplicativo multilocatário, a chave do shardlet pode ser a ID do locatário e todos os dados de um locatário podem estar no mesmo shardlet.

Os aplicativos são responsáveis por associar um conjunto de dados a uma chave shardlet. Uma base de dados SQL separada atua como um gestor global dos mapas das partições horizontais. Esta base de dados tem uma lista de todos os fragmentos e shardlets no sistema. O aplicativo se conecta ao banco de dados do gerenciador de mapas de estilhaços para obter uma cópia do mapa de estilhaços. Ele armazena em cache o mapa de estilhaços localmente e usa o mapa para rotear solicitações de dados para o fragmento apropriado. Essa funcionalidade está oculta por trás de uma série de APIs contidas na biblioteca de cliente do recurso Banco de Dados Elástico do Banco de Dados SQL, que está disponível para Java e .NET.

Para obter mais informações sobre pools elásticos, consulte Dimensionamento com o Banco de dados SQL.

Para reduzir a latência e melhorar a disponibilidade, você pode replicar o banco de dados global do gerenciador de mapas de estilhaços. Com os níveis de preços premium, você pode configurar a replicação geográfica ativa para copiar dados continuamente para bancos de dados em diferentes regiões.

Como alternativa, use a Sincronização de Dados SQL para Banco de Dados SQL ou o Azure Data Factory para replicar o banco de dados do gerenciador de mapas de estilhaços entre regiões. Essa forma de replicação é executada periodicamente e é mais adequada se o mapa de estilhaços mudar com pouca frequência e não exigir a camada premium.

A Base de Dados Elástica fornece dois esquemas de mapeamento de dados para shardlets e o respetivo armazenamento nas partições horizontais:

Um mapa de estilhaços de lista associa uma única chave a um shardlet. Por exemplo, num sistema multi-inquilino, os dados de cada inquilino podem ser associados a uma chave exclusiva e armazenados no seu próprio shardlet. Para garantir o isolamento, cada fragmento pode ser mantido dentro do seu próprio fragmento.

Baixe um arquivo do Visio deste diagrama.
Um mapa de estilhaços de intervalo associa um conjunto de valores-chave contíguos a um shardlet. Por exemplo, você pode agrupar os dados de um conjunto de locatários, cada um com sua própria chave, dentro do mesmo shardlet. Esse esquema é mais barato do que um mapa de estilhaços de lista porque os locatários compartilham armazenamento de dados, mas fornece menos isolamento.

Baixar um arquivo do Visio deste diagrama

Um único fragmento pode conter os dados de vários fragmentos. Por exemplo, pode utilizar shardlets de lista para armazenar dados de diferentes inquilinos não contínuos na mesma partição horizontal. Você também pode misturar shardlets de alcance e listar shardlets no mesmo fragmento, mas então eles são abordados através de mapas diferentes. O diagrama a seguir mostra essa abordagem:

Baixe um arquivo do Visio deste diagrama.

Com pools elásticos, você pode adicionar e remover fragmentos à medida que o volume de dados cresce e diminui. Os aplicativos cliente podem criar e excluir fragmentos de forma dinâmica e transparente atualizar o gerenciador de mapas de estilhaços. No entanto, a remoção de uma partição horizontal é uma operação destrutiva que também requer a eliminação de todos os dados nessa partição horizontal.

Se um aplicativo precisar dividir um fragmento em dois fragmentos separados ou combinar fragmentos, use a ferramenta de mesclagem dividida. Essa ferramenta é executada como um serviço Web do Azure e migra dados com segurança entre fragmentos.

O esquema de particionamento pode afetar significativamente o desempenho do seu sistema. Também pode afetar a taxa na qual os fragmentos devem ser adicionados ou removidos, ou que os dados devem ser reparticionados entre fragmentos. Considere os pontos seguintes:

Agrupe dados usados juntos no mesmo fragmento e evite operações que acessam dados de vários fragmentos. Um fragmento é um banco de dados SQL por si só, e as junções entre bancos de dados devem ser executadas no lado do cliente quando as operações acessam vários fragmentos.

Embora o Banco de dados SQL não ofereça suporte a junções entre bancos de dados, você pode usar as ferramentas do Banco de Dados Elástico para executar consultas de vários estilhaços. Uma consulta com vários estilhaços envia consultas individuais para cada banco de dados e mescla os resultados.
Projete um sistema que não tenha dependências entre fragmentos. Restrições de integridade referencial, gatilhos e procedimentos armazenados em um banco de dados não podem fazer referência a objetos em outro.
Considere replicar dados entre fragmentos se você tiver dados de referência usados com freqüência por consultas. Essa abordagem pode eliminar a necessidade de unir dados entre bancos de dados. Idealmente, esses dados devem ser estáticos ou lentos para minimizar o esforço de replicação e reduzir a chance de se tornarem obsoletos.
Use o mesmo esquema para shardlets que pertencem ao mesmo mapa de estilhaços. Essa orientação não é imposta pelo Banco de dados SQL, mas o gerenciamento e a consulta de dados são complexos se cada shardlet tiver um esquema diferente. Em vez disso, crie mapas de estilhaços separados para cada esquema. Você pode armazenar dados que pertencem a diferentes shardlets no mesmo fragmento.
Armazene dados no mesmo fragmento ou implemente eventual consistência se sua lógica de negócios precisar executar transações. As operações transacionais são suportadas apenas para dados que estão em um fragmento, e não entre fragmentos. As transações podem abranger shardlets se fizerem parte do mesmo fragmento.
Coloque fragmentos perto dos usuários que acessam os dados nesses fragmentos. Esta estratégia ajuda a reduzir a latência.
Evite ter uma combinação de fragmentos altamente ativos e relativamente inativos. Tente distribuir a carga uniformemente por partições horizontais. Você pode ter que hash as chaves de fragmentação. Se você estiver localizando geograficamente fragmentos, certifique-se de que as chaves com hash sejam mapeadas para fragmentos mantidos em fragmentos armazenados perto dos usuários que acessam esses dados.

Partição no Armazenamento de Blobs do Azure

Com o Armazenamento de Blob, você pode armazenar grandes objetos binários. Use blobs de bloco em cenários que exigem que você carregue ou baixe rapidamente grandes volumes de dados. Use blobs de página para aplicativos que exigem acesso aleatório, em vez de serial, a partes dos dados.

Cada blob de bloco ou blob de página é mantido em um contêiner em uma conta de armazenamento do Azure. Use contêineres para agrupar blobs relacionados que tenham os mesmos requisitos de segurança. Este agrupamento é lógico, em vez de físico. Dentro de um contentor, cada blob tem um nome exclusivo.

A chave de partição para um blob é o nome da conta, o nome do contêiner e o nome do blob. A chave de partição é usada para particionar dados em intervalos. Esses intervalos são balanceados de carga em todo o sistema. Os blobs podem ser distribuídos em vários servidores para expandir o acesso a eles. Um único blob só pode ser servido por um único servidor.

Se o seu esquema de nomenclatura usa carimbos de data/hora ou identificadores numéricos, isso pode levar a tráfego excessivo para uma partição. Isso impede que o sistema efetivamente balanceamento de carga. Por exemplo, se você tiver operações diárias que usam um objeto blob com um carimbo de data/hora, como aaaa-mm-dd, todo o tráfego dessa operação vai para um único servidor de partição. Em vez disso, prefixe o nome com um hash de três dígitos. Para obter mais informações, consulte Convenção de nomenclatura de partições.

As ações de escrever um único bloco ou página são atômicas, mas as operações que abrangem blocos, páginas ou blobs não são. Se você precisar garantir a consistência quando as operações de gravação forem executadas em blocos, páginas e blobs, retire um bloqueio de gravação usando uma concessão de blob.

Considerações

O particionamento de dados apresenta alguns desafios e complexidades que você precisa considerar.

A sincronização de dados entre as partições pode se tornar um desafio. Certifique-se de que as atualizações ou alterações em uma partição sejam propagadas para as outras partições de maneira oportuna e consistente.
Os processos de failover e recuperação de desastres tornam-se complexos quando você precisa coordenar o backup e a restauração de várias partições. Problemas de integridade de dados podem surgir se algumas partições ou seus backups estiverem corrompidos ou indisponíveis.
O particionamento de dados pode afetar o desempenho e a confiabilidade se você precisar consultar entre partições e quando reequilibrar as partições se os dados crescerem de forma desigual.

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de fiabilidade

Partilhar via

Recomendações para particionamento de dados

Principais estratégias de design