Recomendações para particionamento de dados

Artigo
11/15/2023

Aplica-se a esta recomendação de lista de verificação de confiabilidade 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 criar 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 você 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 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 dados por padrão de uso. Por exemplo, você pode arquivar dados mais antigos no 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 SQL Server.

Por que particionar os dados?

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 dados entre várias partições, com cada partição hospedada em um servidor separado, poderá escalar horizontalmente 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 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 sem sentido 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 o custo. 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.
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 Noções básicas sobre modelos de armazenamento de dados.
Melhorar a disponibilidade. Para evitar um ponto único de falha, você pode separar 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.

Projetar partições

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 um 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 (Product Key). 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 espalha 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 ativas que possam afetar o desempenho e a disponibilidade. Por exemplo, se você usar a primeira letra do nome de um cliente, ela 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 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ê use 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 do produto, descrição e preço. Outra partição contém dados de inventário, incluindo a contagem de ações e a última data ordenada.

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

Confira 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 da última encomenda). 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 adicionados.
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. Ele é ideal para armazenamentos de dados orientados a colunas, como HBase e Cassandra. Se é improvável que os dados em uma coleção de colunas sejam alterados, considere o uso de repositórios de colunas em 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 de 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.

Projetar partições para escalabilidade

É vital considerar o tamanho e a carga de trabalho para cada partição. Equilibre-os para que os dados sejam distribuídos para alcançar a escalabilidade máxima. 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 criar 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, frequência de acesso, latência inerente e requisitos de processamento de computação do lado do servidor. Em muitos casos, algumas entidades principais 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 nas partições para atender à meta de escalabilidade. Para particionamento horizontal, escolha a chave de fragmento certa para garantir a distribuição uniforme. Para obter mais informações, consulte Padrão de fragmentação.
Verifique se cada partição tem 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, capacidade de processamento ou largura de banda de rede. Se os requisitos provavelmente excederem esses limites, talvez seja necessário refinar sua estratégia de particionamento ou dividir ainda mais os dados. Talvez seja 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ê. Talvez seja necessário reequilibrar as partições ou reprojetar algumas partes do sistema para gerar o equilíbrio necessário.

Alguns ambientes de nuvem alocam recursos com base nos limites de infraestrutura. Verifique se os limites do limite selecionado fornecem espaço suficiente para o crescimento antecipado do volume de dados, do armazenamento de dados, do poder de processamento e da 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, confira 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 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 espalhar as tabelas entre essas contas.

Projetar partições para o desempenho da 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 de banco de dados apropriados. Verifique se você implementa os índices necessários.

Siga estas etapas ao criar partições para o desempenho da 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 que são executadas lentamente.
- 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 um 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 escanee cada partição.
- Considere o local de uma partição. Tente manter dados em partições que estão 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 particionamento funcional baseado nessa entidade. Se essa alocação ainda não atender aos requisitos, você poderá adicionar o 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 independentemente subconjuntos individuais do conjunto de dados.

Leve os fatores a seguir em consideração, os quais afetam a disponibilidade:

Determine a criticalidade dos dados. Identifique os dados comerciais críticos, 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 criticalidade na mesma partição para que possam ser copiados em 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 registro em log ou rastreamento.

Gerenciar partições individuais. Crie partições para dar suporte a 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.
Particionar dados por área geográfica permite que as tarefas de manutenção agendadas ocorram fora do horário de pico para cada local. Verifique se as partições não são tão grandes que impeçam a conclusão da manutenção planejada durante esse período.

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

Considerações sobre o design de aplicativo

O particionamento acrescenta complexidade ao design e desenvolvimento do sistema. Particione dados como uma 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 posterior, será desafiador porque você já tem um sistema ativo para manter. Você pode:

Precisa modificar a lógica de acesso a dados.
Precisa migrar grandes quantidades de dados existentes para distribuí-los entre partições.
Enfrentar 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 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 poderá 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 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 frequente com tráfego pesado 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 examinar 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 o local de fragmento dos itens. Implemente esse mapa na lógica de fragmentação do aplicativo. Ele também poderá ser mantido pelo armazenamento de dados se o armazenamento de dados der suporte à fragmentação transparente.

Reequilibrar fragmentos periodicamente. Com o particionamento horizontal, o rebalanceamento de fragmentos pode ajudar a distribuir uniformemente os dados por tamanho e carga de trabalho. Reequilibrar fragmentos para minimizar pontos de acesso, maximizar o desempenho da consulta e contornar 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 em funcionamento.

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 transacional e integridade 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 porque 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 seja executado de forma 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 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 dar suporte a operações de dados fragmentadas, 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 arquivo morto 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 esses problemas automaticamente ou gerar um relatório para revisão manual.

Reequilibrar 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 contenção excessiva. Ou talvez você tenha 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 automaticamente partições. 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 os dados do antigo esquema de particionamento para o novo conjunto de partições.

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

Migração offline

A migração offline reduz a chance de contenção ocorrer. 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.
Verificar os dados.
Deixe as novas partições online.
Remova a partição antiga.

Migração online

A migração online é mais complexa, mas menos disruptiva 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 que são distribuídos em 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 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 de 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 por trás de uma série de APIs contidas na biblioteca de clientes do recurso banco de dados elástico de Banco de Dados SQL, que está disponível para Java e .NET.

Para obter mais informações sobre pools elásticos, consulte Dimensionamento com 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 continuamente dados para bancos de dados em regiões diferentes.

Como alternativa, use Sincronização de Dados SQL para Banco de Dados SQL ou Azure Data Factory para replicar o banco de dados do gerenciador de mapa 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 deste 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 para 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.

Baixar um arquivo do Visio deste 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 fragmentos 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 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, atualizando 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:

Agrupar dados que são usados juntos no mesmo fragmento e evitar 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 Banco de Dados SQL não dê suporte a junções entre bancos de dados, você pode usar ferramentas de 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.
Crie 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 referenciar 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. O ideal é que esses dados sejam 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 por 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 fragmentos diferentes no mesmo fragmento.
Armazene dados no mesmo fragmento ou implemente a 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 poderão abranger fragmentos 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 hash das chaves de fragmentação. Se você estiver localizando fragmentos geográficos, verifique se as chaves de hash são mapeadas para fragmentos mantidos em fragmentos armazenados próximos aos usuários que acessam esses dados.

Partição em 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 têm balanceamento de carga em todo o sistema. Os blobs podem ser distribuídos entre muitos servidores para expandir o acesso a eles. Um único blob só pode ser servido por um único servidor.

Se o esquema de nomenclatura usar carimbos de data/hora ou identificadores numéricos, ele poderá levar a um tráfego excessivo para uma partição. Ele impede que o sistema balancee efetivamente a carga. Por exemplo, se você tiver operações diárias que usam um objeto blob com um carimbo de data/hora, como yyyy-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 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 entre 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. Verifique se as atualizações ou alterações em uma partição são propagadas para as outras partições em tempo hábil e consistente.
Os processos de failover e recuperação de desastre se tornam 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 poderá afetar o desempenho e a confiabilidade se você precisar consultar entre partições e ao reequilibrar as partições se os dados crescerem de forma irregular.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade

Recomendações para particionamento de dados