Recomendações para particionamento de dados

Artigo
07/03/2024

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

RE:06	Implemente uma estratégia de colocação em escala oportuna e confiável nos níveis do 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. Essa estratégia ajuda a melhorar a confiabilidade 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 os 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 sua estratégia de particionamento com cuidado para maximizar os benefícios e minimizar os efeitos adversos.

Observação

Neste artigo, o termo particionamento significa o processo de dividir fisicamente os dados em armazenamentos de dados separados. Ele difere do particionamento de tabela do SQL Server.

Você pode particionar dados para:

Melhorar a escalabilidade. Quando você escala verticalmente 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á escalar horizontalmente o sistema quase indefinidamente.
Aumente 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 seu sistema mais eficiente. As operações que afetam mais de uma partição podem ser executadas paralelamente.
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 as operações, maximizar a eficiência administrativa e minimizar os custos. Por exemplo, você pode definir estratégias de gerenciamento, monitoramento, backup e restauração e outras tarefas administrativas com base na importância dos dados em cada partição.
Fazer a correspondência do repositório de dados ao padrão de uso. 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 dados binários grandes no armazenamento de blobs e armazenar dados estruturados em um banco de dados de documentos. Para obter mais informações, consulte Entender os modelos de armazenamento de dados.
Melhorar a disponibilidade. Para evitar um único ponto de falha, você pode separar os dados em vários servidores. Se uma instância falhar, somente os dados nessa partição não estão disponíveis. As operações continuam em outras partições. Essa consideração é menos relevante para armazenamentos de dados de PaaS (plataforma como serviço) gerenciados porque eles têm redundância interna.

Selecione a estratégia de particionamento correta

Há três estratégias típicas para o particionamento dos dados:

Particionamento horizontal (geralmente 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.
Particionamento vertical. Nessa estratégia, cada partição contém um subconjunto dos campos de itens no repositório de dados. Os campos são divididos de acordo com seu padrão de uso. Por exemplo, os campos acessados com frequência podem ser colocados em uma partição vertical e os campos acessados com menos frequência em outra.
Particionamento funcional. Nessa estratégia, os dados são agregados de acordo com a forma como cada contexto limitado no sistema usa os dados. Por exemplo, um sistema de comércio eletrônico pode armazenar os dados da fatura em uma partição e os dados de inventário dos produtos em outra.

Considere combinar essas estratégias ao criar um esquema de particionamento. Por exemplo, você poderia dividir os dados em fragmentos e então usar o particionamento vertical para subdividir ainda mais os dados em cada fragmento.

Particionamento horizontal (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 fragmento contém os dados para um intervalo contíguo de chaves de fragmento (A-G e H-Z), organizadas em 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 que o sistema estiver em operação. A chave deve garantir que os dados sejam particionados para distribuir a carga de trabalho da maneira mais uniforme possível entre os fragmentos.

Os fragmentos não precisam ser do mesmo tamanho. É mais importante equilibrar a quantidade 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 possam afetar o desempenho e a disponibilidade. Por exemplo, se você usar a primeira letra do nome de um cliente, isso poderá 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 os dados uniformemente entre as 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 sã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, consulte Padrão de fragmentação.

Particionamento vertical

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. Nesse exemplo, as diferentes propriedades de um item são armazenadas em diferentes partições. Uma partição contém dados acessados com mais frequência, incluindo nome, descrição e preço do produto. Outra partição contém dados de estoque, incluindo a contagem de estoque e a última data do 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:

É possível 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 lentos 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 adicionais.
O particionamento vertical pode reduzir a quantidade de acesso simultâneo necessária.

O particionamento vertical funciona no nível da entidade em um armazenamento de dados, parcialmente normalizando uma entidade para dividir um item grande em um conjunto de itens pequenos. É 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.

Particionamento funcional

Quando um contexto limitado 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 do particionamento funcional é separar dados de leitura/gravação de dados somente leitura. A imagem a seguir mostra uma visão geral do particionamento funcional que tem dados de inventário separados dos dados do cliente.

Essa estratégia de particionamento pode ajudar a reduzir a contenção do acesso a dados em diferentes partes de um sistema.

Projete 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 repositório 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 entidades principais exigem a maior parte 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 nas partições para atender à meta de escalabilidade. Para particionamento horizontal, escolha a chave de fragmento correta para garantir uma distribuição uniforme. Para obter mais informações, consulte 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 da rede. Se os requisitos provavelmente excederem 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 manipular a carga. O uso real nem sempre corresponde ao que uma análise prevê. Você pode ter que reequilibrar as partições ou reprojetar algumas partes do sistema para produzir o equilíbrio necessário.

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

Por exemplo, se você usar o Armazenamento de Tabelas do Azure, haverá 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 administrar. Talvez seja necessário reparticionar o fragmento para distribuir 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 entre 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. Essa redução no volume pode melhorar o desempenho das consultas. No entanto, o particionamento não é uma alternativa ao design e à configuração apropriados 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 devem sempre ser executadas rapidamente.
- Monitore o sistema para identificar consultas com desempenho lento.
- Determine as consultas que são 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.
- Limitar o tamanho de cada partição para que o tempo de resposta da consulta esteja dentro da meta.
- Se você usar o particionamento horizontal, projete a chave de fragmento para que o aplicativo possa selecionar facilmente a partição apropriada. Essa especificação impede que a consulta verifique todas as partições.
- Considere o local de uma partição. Tente manter os dados em partições geograficamente próximas aos 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 as duas estratégias.
Execute consultas em paralelo entre partições para melhorar o desempenho.

Projete 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ê possa gerenciar independentemente subconjuntos individuais do conjunto de dados.

Leve os fatores a seguir em consideração, os quais 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.
Estabeleça procedimentos separados de gerenciamento e monitoramento para diferentes conjuntos de dados.
Coloque os dados que têm o mesmo nível de criticidade na mesma partição para que seja possível fazer backup na mesma frequência. Por exemplo, talvez seja necessário fazer backup de partições que contêm 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 dar suporte ao gerenciamento e manutenção independentes. Essa prática oferece várias vantagens, por exemplo:

Se uma partição falhar, ela pode ser recuperada independentemente sem aplicativos que acessem dados em outras partições.
O particionamento de dados por área geográfica permite que tarefas de manutenção programadas ocorram fora do horário de pico para cada local. Certifique-se de que as partições não sejam tão grandes que impeçam a conclusão da manutenção planejada 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. A sincronização das alterações com cada réplica é demorada. Durante a sincronização, partições diferentes contêm valores de dados diferentes.

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

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

Tem que modificar a lógica de acesso a dados.
Precisa migrar grandes quantidades de dados existentes para distribuí-los entre partições.
Enfrentam 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 com ele facilmente. 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 poderá ajudar a reduzir a contenção e melhorar a taxa de transferência.

Considere os seguintes pontos ao criar um esquema de particionamento de dados:

Minimize as operações de acesso de 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 em uma única partição. Mas a otimização de partições para um conjunto de consultas pode afetar negativamente outros conjuntos de consultas. Se for preciso fazer consulta entre partições, minimize o tempo de consulta executando consultas paralelas e agregando os resultados no 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.

Replique dados de referência estáticos. Se as consultas usarem dados de referência relativamente estáticos, como tabelas de CEP 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 quente com tráfego intenso de todo o sistema. Há custos extras associados à sincronização de alterações nos dados de referência.

Minimize as junções entre partições. Sempre que possível, minimize os requisitos de integridade referencial entre 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 cancelar a normalização dos dados relevantes. Se as uniões entre partições forem necessárias, execute consultas paralelas nas partições e reúna os dados no aplicativo.

Adote a consistência eventual. Avalie se a consistência forte é um requisito. Uma abordagem comum em sistemas distribuídos é implementar a 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 como as consultas localizam a partição correta. Se uma consulta precisar verificar todas as partições para localizar os dados necessários, ela afetará significativamente o desempenho, mesmo quando várias consultas paralelas forem executadas. Com o 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 usado para pesquisar 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.

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

Replique 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 você atingir os limites físicos de uma estratégia de particionamento, talvez seja necessário estender a escalabilidade para um nível diferente. Por exemplo, se o particionamento estiver no nível do banco de dados, você poderá precisar localizar ou replicar partições em vários bancos 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 acessam os 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 aplicativo, pois a maioria dos sistemas de particionamento não fornece suporte nativo.

Todos os repositórios de dados exigem algumas atividades operacionais de gerenciamento e monitoramento. Essas tarefas incluem carregar dados, fazer backup e restaurar dados, reorganizar dados e garantir que o sistema funcione de maneira correta e eficiente.

Considere os seguintes fatores que afetam o gerenciamento operacional:

Implemente tarefas operacionais e de gerenciamento apropriadas quando os dados forem particionados. Essas tarefas podem incluir backup e restauração, arquivamento de dados, monitoramento do sistema e outras tarefas administrativas. Por exemplo, pode ser desafiador 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 oferecer suporte a operações de dados fragmentados, como carregar dados na partição correta.
Arquive e exclua 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 executar 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.

Rebalancear partições

À medida que um sistema amadurece, talvez seja preciso ajustar o esquema de particionamento. Por exemplo, partições individuais podem começar a receber um volume desproporcional de tráfego e ficar 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 pode automaticamente rebalancear partições. Em outros casos, você pode rebalancear as 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 os dados do antigo esquema de particionamento para o novo conjunto de partições.

Talvez seja necessário tornar as partições indisponíveis enquanto você 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ê os move.
Divida/mescle e mova os dados para as novas partições.
Verify the data.
Deixe as novas partições online.
Remova a partição antiga.

Migração online

A migração online é mais complexa, mas menos perturbadora em comparação com a migração offline. 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 fragmento, 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 as recomendações para particionar dados armazenados nos serviços do Azure.

Partição no Banco de Dados SQL do Azure

Um banco de dados SQL individual tem um limite para volume de dados que ele pode conter. A taxa de transferência é restrita por fatores de arquitetura e pelo número de conexões simultâneas que são permitidas.

Os Pools elásticos dão suporte ao dimensionamento horizontal para um banco de dados SQL. Use pools elásticos para particionar seus dados em fragmentos distribuídos em vários bancos de dados SQL. Você também pode adicionar ou remover fragmentos à medida que o volume de dados aumenta e diminui. Os pools elásticos também podem ajudar a reduzir a contenção pela distribuição da carga nos bancos de dados.

Cada fragmento é implementado como um banco 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 de shardlet. Um banco de dados SQL separado age como um gerenciador global de mapa de fragmentos. Esse banco de dados contém uma lista de todos os fragmentos e shardlets no sistema. O aplicativo conecta-se ao banco de dados do gerenciador de mapa de fragmentos para obter uma cópia do mapa do fragmento. Ele armazena em cache o mapa de fragmentos localmente e usa o mapa para rotear solicitações de dados para o fragmento apropriado. Essa funcionalidade está oculta atrás de uma série de APIs contidas na biblioteca de clientes 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 Escalando horizontalmente com o Banco de Dados SQL.

Para reduzir a latência e melhorar a disponibilidade, você pode replicar o banco de dados do gerenciador do mapa de fragmentos global. Com os tipos de preço 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 do SQL para Banco de Dados SQL ou o Azure Data Factory para replicar o banco de dados do gerenciador de mapas de fragmentos entre regiões. Essa forma de replicação é executada periodicamente e é mais adequada se o mapa de fragmentos for alterado com pouca frequência e não exigir a camada premium.

O Banco de Dados Elástico oferece dois esquemas para mapear dados para shardlets e armazená-los em fragmentos:

Um mapa de fragmentos de lista associa uma única chave a um shardlet. Por exemplo, em um sistema multilocatário, os dados de cada locatário podem ser associados a uma chave exclusiva e armazenados em seu próprio shardlet. Para garantir o isolamento, cada shardlet pode ser mantido em seu próprio fragmento.

Baixe um Arquivo do Visio desse diagrama.
Um mapa de fragmentos de intervalo associa um conjunto de valores de 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 fragmentos de lista porque os locatários compartilham o armazenamento de dados, mas fornece menos isolamento.

Baixe um Arquivo Visio desse diagrama

Um único fragmento pode conter os dados de vários shardlets. Por exemplo, você pode usar os shardlets da lista para armazenar dados de diferentes locatários não contíguos no mesmo fragmento. Você também pode misturar shardlets de intervalo e listar shardlets no mesmo fragmento, mas eles são endereçados por meio de mapas diferentes. O diagrama a seguir mostra essa abordagem:

Baixe um Arquivo do Visio desse diagrama.

Com pools elásticos, você pode adicionar e remover fragmentos à medida que o volume de dados aumenta e diminui. Os aplicativos cliente podem criar e excluir fragmentos de forma dinâmica e atualizar de forma transparente o gerenciador de mapa de fragmentos. No entanto, a remoção de um fragmento é uma operação destrutiva que também requer a exclusão de todos os dados nesse fragmento.

Se um aplicativo precisar dividir um fragmento em dois fragmentos separados ou combinar os fragmentos, use a ferramenta de mesclagem/divisão. 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. Ele também pode afetar a taxa na qual os fragmentos devem ser adicionados ou removidos, ou esses dados devem ser reparticionados entre os fragmentos. Considere os seguintes pontos:

Agrupe os 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 dê 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 fragmentos. Uma consulta de vários fragmentos 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 frequê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 fragmentos. Essas diretrizes não são impostas 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 fragmentos separados para cada esquema. Você pode armazenar dados que pertencem a diferentes shardlets no mesmo fragmento.
Armazene dados no mesmo fragmento ou implemente consistência eventual se sua lógica de negócios precisar executar transações. As operações transacionais só têm suporte 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 os fragmentos próximos aos usuários que acessam os dados nesses fragmentos. Essa 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 entre os fragmentos. Talvez seja necessário fazer o hash das chaves de fragmentação. Se você estiver localizando fragmentos geograficamente, certifique-se de que as chaves com hash sejam mapeadas para shardlets mantidos em fragmentos armazenados perto dos usuários que acessam esses dados.

Partição no Armazenamento de Blobs do Azure

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

Cada blob de blocos ou blob de páginas é 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. Esse agrupamento é lógico em vez de físico. Dentro de um contêiner, cada blob tem um nome exclusivo.

A chave de partição de 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 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 atendido por um único servidor.

Se o esquema de nomenclatura usar carimbos de data/hora ou identificadores numéricos, isso poderá levar a um tráfego excessivo para uma partição. Isso impede que o sistema balanceie a carga com eficiência. 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ção.

As ações de gravar 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, remova 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 rebalancear as partições se os dados crescerem de forma desigual.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade

Compartilhar via

Recomendações para particionamento de dados

Principais estratégias de design