Diretrizes de particionamento de dados

Em muitas soluções em grande escala, os dados são divididos em partições que podem ser gerenciadas e acessadas separadamente. O particionamento pode aprimorar a escalabilidade, reduzir a contenção e otimizar o desempenho. Ele também pode fornecer um mecanismo para dividir os dados pelo padrão de uso. Por exemplo, você pode arquivar dados antigos em armazenamento de dados mais barato.

No entanto, a estratégia de particionamento deve ser escolhida com cuidado para maximizar os benefícios, minimizando os efeitos adversos.

Por que os dados de partição?

• Melhorar a escalabilidade. Quando você escala verticalmente um único sistema de banco de dados, ele eventualmente atinge um limite de hardware físico. Se você dividir dados entre várias partições, cada uma hospedada em um servidor separado, poderá dimensionar o sistema quase indefinidamente.

• Aumente o desempenho. As operações de acesso a dados em cada partição ocorrem em um volume menor de dados. Feito corretamente, o particionamento pode tornar seu sistema mais eficiente. Operações que afetam mais de uma partição podem ser executadas em paralelo.

• Aprimore a segurança. Em alguns casos, você pode separar dados confidenciais e sem sentido em partições diferentes e aplicar diferentes controles de segurança aos dados confidenciais.

• Forneça flexibilidade operacional. O particionamento oferece muitas oportunidades para operações de ajuste fino, maximizando a eficiência administrativa e minimizando o custo. Por exemplo, você pode definir estratégias diferentes para gerenciamento, monitoramento, backup e restauração e outras tarefas administrativas com base na importância dos dados em cada partição.

• Corresponda o armazenamento de dados ao padrão de uso. O particionamento permite que cada partição seja implantada em um tipo diferente de armazenamento de dados, com base no custo e nos recursos internos que o armazenamento de dados oferece. Por exemplo, dados binários grandes podem ser armazenados no armazenamento de blobs, enquanto dados mais estruturados podem ser mantidos em um banco de dados de documento. Para obter mais informações, consulte Escolher o armazenamento de dados correto.

• Melhorar a disponibilidade. A separação de dados em vários servidores evita um único ponto de falha. Se uma instância falhar, somente os dados dessa partição não ficarão disponíveis. As operações em outras partições podem continuar. Para armazenamentos de dados paaS (plataforma gerenciada como serviço), essa consideração é menos relevante, pois esses serviços são projetados com redundância interna.

Criando partições

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

• Particionamento horizontal (geralmente chamado de 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 específico dos dados, como todos os pedidos de um conjunto específico de clientes.

• Particionamento vertical. Nessa estratégia, cada partição contém um subconjunto dos campos para itens no armazenamento de dados. Os campos são divididos de acordo com seu padrão de uso. Por exemplo, campos acessados com frequência podem ser colocados em uma partição vertical e campos acessados com menos frequência em outro.

• Particionamento funcional. Nessa estratégia, os dados são agregados de acordo com a forma como são usados por cada contexto limitado no sistema. 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.

Essas estratégias podem ser combinadas e recomendamos que você considere todas elas ao criar um esquema de particionamento. Por exemplo, você pode dividir dados em fragmentos e, em seguida, usar o particionamento vertical para subdividir ainda mais os dados em cada fragmento.

Particionamento horizontal (fragmentação)

A Figura 1 mostra o particionamento horizontal ou a fragmentação. Neste exemplo, os dados de inventário do produto são divididos em fragmentos com base na chave do produto. Cada fragmento contém os dados de um intervalo contíguo de chaves de fragmento (A-G e H-Z), organizados em ordem alfabética. A fragmentação espalha a carga em mais computadores, o que reduz a contenção e melhora o desempenho.

Figura 1 – Particionamento horizontal de dados (fragmentação) com base em uma chave de partição.

O fator mais importante é a escolha de uma chave de fragmentação. 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 espalhar a carga de trabalho da forma mais uniforme possível entre os fragmentos.

Os fragmentos não precisam ter o mesmo tamanho. É mais importante equilibrar o número de solicitações. Alguns fragmentos podem ser muito grandes, mas cada item tem um número baixo de operações de acesso. Outros fragmentos podem ser menores, mas cada item é acessado com muito 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, usar a primeira letra do nome de um cliente causa uma distribuição desequilibrada, pois algumas letras são mais comuns. Em vez disso, use um hash de um identificador de cliente para distribuir dados de forma mais uniforme entre partições.

Escolha uma chave de fragmentação que minimize quaisquer requisitos futuros para dividir fragmentos grandes, unir pequenos fragmentos em partições maiores ou alterar o esquema. Essas operações podem ser muito demoradas e podem exigir colocar um ou mais fragmentos offline enquanto são executados.

Se os fragmentos forem replicados, talvez seja possível manter algumas das réplicas online enquanto outras são divididas, mescladas ou reconfiguradas. No entanto, o sistema pode precisar 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 sobre particionamento horizontal, consulte o padrão de fragmentação.

Particionamento vertical

O uso mais comum para particionamento vertical é reduzir a E/S e os custos de desempenho associados à busca de itens que são acessados com frequência. A Figura 2 mostra um exemplo de particionamento vertical. Neste exemplo, propriedades diferentes de um item são armazenadas em partições diferentes. 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: a contagem de ações e a data da última encomenda.

Figura 2 – particionamento vertical de dados por seu padrão de uso.

Neste exemplo, o aplicativo consulta regularmente o nome do produto, a descrição e o preço ao exibir os detalhes do produto aos clientes. A contagem de ações e a data ordenada pela última vez são mantidas em uma partição separada porque esses dois itens geralmente são usados juntos.

Outras vantagens do particionamento vertical:

• Dados relativamente lentos (nome do produto, descrição e preço) podem ser separados dos 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.

• Dados confidenciais podem ser armazenados 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 opera no nível da entidade dentro de um armazenamento de dados, normalizando parcialmente uma entidade para dividi-la de um item largo para um conjunto de itens estreitos . Ele é ideal para armazenamentos de dados orientados a colunas, como HBase e Cassandra. Se os dados em uma coleção de colunas forem improváveis de serem alterados, você também poderá considerar o uso de repositórios de colunas no SQL Server.

Particionamento funcional

Quando é possível identificar um contexto limitado para cada área de negócios distinta em um aplicativo, o particionamento funcional é uma maneira de 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 Figura 3 mostra uma visão geral do particionamento funcional em que os dados de inventário são separados dos dados do cliente.

Figura 3 – Particionamento funcional de dados por contexto limitado ou subdomínio.

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

Projetando partições para escalabilidade

É vital considerar o tamanho e a carga de trabalho para cada partição e balanceá-los 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:

1. Analise o aplicativo para entender os padrões de acesso a dados, como o tamanho do conjunto de resultados retornado por cada consulta, 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 maioria dos recursos de processamento.
2. Use essa análise para determinar os destinos de escalabilidade atuais e futuros, como tamanho de dados e carga de trabalho. Em seguida, distribua os dados entre as partições para atender ao destino de escalabilidade. Para particionamento horizontal, escolher a chave de fragmento certa é importante para garantir que a distribuição esteja uniforme. Para obter mais informações, consulte o padrão de fragmentação.
3. 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 na quantidade de espaço de armazenamento, poder de processamento ou largura de banda de rede por partição. Se os requisitos provavelmente excederem esses limites, talvez seja necessário refinar sua estratégia de particionamento ou dividir os dados ainda mais, possivelmente combinando duas ou mais estratégias.
4. 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ê. Nesse caso, talvez seja possível reequilibrar as partições ou então reprojetar algumas partes do sistema para obter o equilíbrio necessário.

Alguns ambientes de nuvem alocam recursos em termos de limites de infraestrutura. Verifique se os limites do limite selecionado fornecem espaço suficiente para qualquer crescimento previsto no volume de dados, em termos de armazenamento de dados, capacidade 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 podem ser tratadas por uma única partição em um determinado período de tempo. (Para obter mais informações, consulte metas de desempenho e escalabilidade do armazenamento do Azure.) Um fragmento ocupado pode exigir mais recursos do que uma única partição pode manipular. Nesse caso, talvez o fragmento precise ser reparticionado 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 contas de armazenamento adicionais e espalhar as tabelas entre essas contas.

Criando partições para o desempenho da consulta

O desempenho da consulta geralmente pode ser aumentado usando conjuntos de dados menores 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 para criar e configurar um banco de dados adequadamente. Por exemplo, verifique se você tem os índices necessários em vigor.

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

1. 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 as consultas que são executadas lentamente.
   • Localize quais consultas são executadas com mais frequência. Mesmo que uma única consulta tenha um custo mínimo, o consumo cumulativo de recursos poderá ser significativo.

2. Particione os dados que estão causando um desempenho lento:

   • Limite o tamanho de cada partição para que o tempo de resposta da consulta esteja dentro do destino.
   • Se você usar o particionamento horizontal, projete a chave de fragmento para que o aplicativo possa selecionar facilmente a partição certa. Isso impede que a consulta precise examinar cada partição.
   • Considere o local de uma partição. Se possível, tente manter dados em partições que estejam geograficamente próximas aos aplicativos e usuários que os acessam.

3. Se uma entidade tiver requisitos de desempenho de taxa de transferência e consulta, use particionamento funcional com base nessa entidade. Se isso ainda não atender aos requisitos, aplique o particionamento horizontal também. Na maioria dos casos, uma única estratégia de particionamento é suficiente, mas em alguns casos é mais eficiente combinar ambas as estratégias.

4. Considere a execução de consultas em paralelo entre partições para melhorar o desempenho.

Criando partições para disponibilidade

Particionar dados pode melhorar a disponibilidade de aplicativos, garantindo que todo o conjunto de dados não constitua um único ponto de falha e que subconjuntos individuais do conjunto de dados possam ser gerenciados de forma independente.

Considere os seguintes fatores que afetam a disponibilidade:

Quão críticos são os dados para as operações de negócios. Identifique quais dados são informações comerciais críticas, como transações, e quais dados são dados operacionais menos críticos, como arquivos de log.

• Considere armazenar dados críticos em partições altamente disponíveis com um plano de backup apropriado.

• Estabeleça procedimentos de gerenciamento e monitoramento separados para os diferentes conjuntos de dados.

• Coloque os dados que têm o mesmo nível de criticidade na mesma partição para que possam ser armazenados em backup juntos em uma frequência apropriada. Por exemplo, as partições que contêm dados de transação podem precisar fazer backup com mais frequência do que partições que contêm informações de registro em log ou rastreamento.

Como as partições individuais podem ser gerenciadas. A criação de partições para dar suporte a gerenciamento e manutenção independentes oferece várias vantagens. Por exemplo:

• Se uma partição falhar, ela poderá ser recuperada independentemente sem aplicativos que acessam dados em outras partições.

• Particionar dados por área geográfica permite que as tarefas de manutenção agendadas ocorram em horários fora do pico para cada local. Verifique se as partições não são muito grandes para impedir que qualquer manutenção planejada seja concluída durante esse período.

Se os dados críticos devem ser replicados entre partições. Essa estratégia pode melhorar 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 esse período, partições diferentes contêm valores de dados diferentes.

Considerações sobre design de aplicativo

O particionamento adiciona complexidade ao design e ao desenvolvimento do seu sistema. Considere o particionamento 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á mais desafiador porque você já tem um sistema ativo para manter:

• A lógica de acesso a dados precisa ser modificada.
• Grandes quantidades de dados existentes podem precisar ser migradas para distribuí-los entre partições.
• Os usuários esperam poder continuar usando o sistema durante a migração.

Em alguns casos, o particionamento não é considerado importante porque o conjunto de dados inicial é pequeno e facilmente manipulado por um único servidor. Isso pode ser verdadeiro para algumas cargas de trabalho, mas muitos sistemas comerciais precisam se expandir à medida que o número de usuários aumenta.

Além disso, não são apenas grandes armazenamentos de dados que se beneficiam do particionamento. Por exemplo, um pequeno armazenamento de dados pode ser fortemente acessado por centenas de clientes simultâneos. Particionar os dados nessa situação pode 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 a dados entre partições. Sempre que possível, mantenha os dados das operações de banco de dados mais comuns em cada partição para minimizar as operações de acesso a dados entre partições. A consulta entre partições pode ser mais demorada do que a consulta em uma única partição, mas otimizar 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. (Essa abordagem pode não ser possível em alguns casos, como quando o resultado de uma consulta é usado na próxima consulta.)

Considere 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 "quente", com tráfego intenso de todo o sistema. No entanto, há um custo adicional associado à sincronização de quaisquer alterações nos dados de referência.

Minimize as junções entre partições. Sempre que possível, minimize os requisitos de integridade referencial em 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 precisa executar consultas consecutivas com base em uma chave e, em seguida, em uma chave estrangeira. Em vez disso, considere replicar ou des normalizar os dados relevantes. Se as junções entre partições forem necessárias, execute consultas paralelas nas partições e junte os dados no aplicativo.

Abrace a consistência eventual. Avalie se a consistência forte é realmente 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 todas as atualizações sejam concluídas com êxito. Ele também lida com as inconsistências que podem surgir da consulta de dados enquanto uma operação eventualmente consistente está em execução.

Considere como as consultas localizam a partição correta. Se uma consulta precisar examinar todas as partições para localizar os dados necessários, haverá um impacto significativo no desempenho, mesmo quando várias consultas paralelas estão em execução. Com o particionamento vertical e funcional, as consultas podem especificar naturalmente a partição. O particionamento horizontal, por outro lado, pode dificultar a localização de um item, pois cada fragmento tem o mesmo esquema. Uma solução típica para manter um mapa usado para pesquisar o local do fragmento para itens específicos. Esse mapa pode ser implementado na lógica de fragmentação do aplicativo ou mantido pelo armazenamento de dados se ele der suporte à fragmentação transparente.

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

Replicar partições. Se você replicar cada partição, ela fornecerá proteção adicional contra falhas. Se uma única réplica falhar, as consultas poderão ser direcionadas para uma cópia em funcionamento.

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, talvez seja necessário localizar ou replicar partições em vários bancos de dados. Se o particionamento já estiver no nível do banco de dados e as limitações físicas forem um problema, isso poderá significar que você precisa localizar ou replicar partições em várias contas de hospedagem.

Evite transações que acessam 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, provavelmente precisará implementá-lo como parte da lógica do aplicativo, pois a maioria dos sistemas de particionamento não fornece suporte nativo.

Todos os armazenamentos de dados exigem algumas atividades de gerenciamento e monitoramento operacionais. As tarefas podem variar desde carregar dados, fazer backup e restaurar dados, reorganizar dados e garantir que o sistema esteja sendo executado de forma correta e eficiente.

Considere os seguintes fatores que afetam o gerenciamento operacional:

• Como implementar tarefas operacionais e de gerenciamento apropriadas quando os dados são particionados. Essas tarefas podem incluir backup e restauração, arquivamento de dados, monitoramento do sistema e outras tarefas administrativas. Por exemplo, manter a consistência lógica durante operações de backup e restauração pode ser um desafio.

• Como carregar os dados em várias partições e adicionar novos dados que estão chegando 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.

• Como arquivar e excluir os dados regularmente. Para evitar o crescimento excessivo de partições, você precisa arquivar e excluir dados regularmente (como mensalmente). Talvez seja necessário transformar os dados para corresponder a um esquema de arquivo morto diferente.

• Como localizar problemas de integridade de dados. Considere executar um processo periódico para localizar quaisquer problemas de integridade de dados, como dados em uma partição que faça 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.

Rebalanceamento de partições

À medida que um sistema amadurece, talvez seja necessário ajustar o esquema de particionamento. Por exemplo, partições individuais podem começar a receber um volume desproporcional de tráfego e ficar ativas, levando a contenção excessiva. Ou você pode ter subestimado o volume de dados em algumas partições, fazendo com que algumas 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, o rebalanceamento é uma tarefa administrativa que consiste em dois estágios:

1. Determine uma nova estratégia de particionamento.

   • Quais partições precisam ser divididas (ou possivelmente combinadas)?
   • Qual é a nova chave de partição?

2. Migre dados do antigo esquema de particionamento para o novo conjunto de partições.

Dependendo do armazenamento de dados, você poderá migrar dados entre partições enquanto elas estiverem em uso. Isso é chamado de migração online. Se isso não for possível, talvez seja necessário tornar as partições indisponíveis enquanto os dados são realocados (migração offline).

Migração offline

A migração offline normalmente é mais simples porque reduz as chances de contenção. Conceitualmente, a migração offline funciona da seguinte maneira:

1. Marque a partição offline.
2. Divida-mesclar e mover os dados para as novas partições.
3. Verificar os dados.
4. Colocar as novas partições online.
5. Remova a partição antiga.

Opcionalmente, você pode marcar uma partição como somente leitura na etapa 1, para que os aplicativos ainda possam ler os dados enquanto eles estão sendo movidos.

Migração online

A migração online é mais complexa de executar, mas menos disruptiva. O processo é semelhante à migração offline, exceto que a partição original não está marcada 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 lidar com a leitura e gravação de dados mantidos em dois locais, a partição original e a nova partição.

Próximas etapas

• Saiba mais sobre estratégias de particionamento para serviços específicos do Azure. Para obter mais informações, consulte Estratégias de particionamento de dados.
• Metas de desempenho e escalabilidade de armazenamento do Azure

Recursos relacionados

• Escolher o armazenamento de dados correto

Os seguintes padrões de design podem ser relevantes para seu cenário:

• O padrão de fragmentação descreve algumas estratégias comuns para fragmentação de dados.

• O padrão da tabela de índice mostra como criar índices secundários em relação aos dados. Um aplicativo pode recuperar rapidamente dados com essa abordagem usando consultas que não fazem referência à chave primária de uma coleção.

• O padrão de exibição materializado descreve como gerar exibições pré-preenchidas que resumem dados para dar suporte a operações de consulta rápidas. Essa abordagem pode ser útil em um armazenamento de dados particionado se as partições que contêm os dados que estão sendo resumidos forem distribuídas em vários sites.