Documentação de orientação sobre a criação de partições de dados

Em muitas soluções de grande escala, os dados são divididos em partições que podem ser geridas e acedidas separadamente. A criação de partições pode melhorar a escalabilidade, reduzir a contenção e otimizar o desempenho. Também pode proporcionar um mecanismo para dividir os dados por padrão de utilização. Por exemplo, pode arquivar dados mais antigos num armazenamento de dados mais barato.

No entanto, a estratégia de criação de partições tem de ser escolhida cuidadosamente para maximizar os benefícios, minimizando simultaneamente os efeitos adversos.

Porquê criar partições de dados?

• Melhorar a escalabilidade. Quando dimensiona um sistema de base de dados individual, este acabará por atingir um limite de hardware físico. Se dividir dados entre várias partições, cada uma alojada num servidor separado, pode aumentar horizontalmente o sistema quase indefinidamente.

• Melhorar o desempenho. As operações de acesso aos dados em cada partição ocorrem através de um volume de dados mais pequeno. Corretamente concluído, a criação de partições pode tornar o seu sistema mais eficiente. As operações que afetam mais do que uma partição podem ser executadas em paralelo.

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

• Fornecer flexibilidade operacional. A criação de partições oferece muitas oportunidades para operações de otimização, maximização da eficiência administrativa e minimização dos custos. Por exemplo, pode definir diferentes estratégias de gestão, monitorização, cópia de segurança e restauro, e outras tarefas administrativas, com base na importância dos dados de cada partição.

• Corresponder o arquivo de dados ao padrão de utilização. A criação de partições permite que cada partição seja implementada num tipo diferente de arquivo de dados, com base no custo e nas funcionalidades incorporadas que o arquivo de dados oferece. Por exemplo, os dados binários grandes podem ser armazenados no armazenamento de blobs, enquanto os dados mais estruturados podem ser mantidos numa base de dados de documentos. Veja Escolher o arquivo de dados correto.

• Melhorar a disponibilidade. Separar os dados por vários servidores evita um ponto único de falha. Se uma instância falhar, apenas os dados nessa partição não estão disponíveis. As operações das outras partições podem continuar. Para arquivos de dados PaaS geridos, esta consideração é menos relevante, uma vez que estes serviços foram concebidos com redundância incorporada.

Estruturar partições

Existem três estratégias típicas para criar partições de dados:

• Criação de partições horizontais (frequentemente denominado fragmentação). Nesta estratégia, cada partição é um arquivo de dados separado, mas todas as partições têm o mesmo esquema. Cada partição é conhecida como partição horizontal e contém um subconjunto específico dos dados, como todas as encomendas de um conjunto específico de clientes.

• Criação de partições verticais. Nesta estratégia, cada partição contém um subconjunto dos campos para os itens no arquivo de dados. Os campos são divididos de acordo com o respetivo padrão de utilização. Por exemplo, os campos acedidos frequentemente podem ser colocados numa partição vertical e os campos acedidos com menos frequência podem ser colocados noutra.

• Criação de partições funcionais. Nesta estratégia, os dados são agregados de acordo com a forma como são utilizados por cada contexto vinculado no sistema. Por exemplo, um sistema de comércio eletrónico pode armazenar dados de fatura numa partição e dados de inventário de produtos noutra.

Estas estratégias podem ser combinadas e recomendamos que as considere todas quando criar um esquema de criação de partições. Por exemplo, pode dividir os dados em partições horizontais e, em seguida, utilizar a criação de partições verticais para subdividir os dados de cada partição horizontal.

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

A Figura 1 mostra partições horizontais ou partições horizontais. Neste exemplo, os dados de inventário dos produtos estão divididos em partições horizontais com base na chave de produto. Cada partição horizontal contém os dados para um intervalo contínuo de chaves de partição horizontal (A-G e H-Z), organizadas por ordem alfabética. A fragmentação espalha a carga por mais computadores, o que reduz a contenção e melhora o desempenho.

Figura 1 – criação horizontal de partições (fragmentação) de dados com base numa chave de partição.

O fator mais importante é a escolha de uma chave de fragmentação. Pode ser difícil alterar a chave depois de o sistema estar em funcionamento. A chave tem de garantir que os dados são particionados para distribuir a carga de trabalho da forma mais uniforme possível pelas partições horizontais.

As partições horizontais não têm de ter o mesmo tamanho. É mais importante equilibrar o número de pedidos. Algumas partições horizontais podem ser muito grandes, mas cada item tem um número reduzido de operações de acesso. Outras partições horizontais poderão ser mais pequenas, mas cada item ser acedido muito mais frequentemente. Também é importante garantir que uma única partição horizontal não exceda os limites de dimensionamento (em termos de capacidade e recursos de processamento) do arquivo de dados.

Evite criar partições "frequentes" que possam afetar o desempenho e a disponibilidade. Por exemplo, a utilização da primeira letra do nome de um cliente causa uma distribuição desequilibrada, uma vez que algumas letras são mais comuns. Em vez disso, utilize um hash de um identificador do cliente para distribuir os dados de forma mais uniforme pelas partições.

Escolha uma chave de fragmentação que minimize quaisquer requisitos futuros para dividir partições horizontais grandes, juntar pequenas partições em partições maiores ou alterar o esquema. Estas operações podem ser muito morosas e podem requerer que coloque uma ou mais partições horizontais offline enquanto estão a ser executadas.

Se as partições horizontais forem replicadas, poderá ser possível manter algumas das réplicas online, enquanto outras são divididas, unidas ou reconfiguradas. No entanto, o sistema poderá ter de limitar as operações que podem ser executadas durante a reconfiguração. Por exemplo, os dados nas réplicas podem ser marcados como só de leitura para evitar inconsistências de dados.

Para obter mais informações sobre a criação de partições horizontais, veja Padrão de fragmentação.

Criação de partições verticais

A utilização mais comum para a criação de partições verticais é reduzir a E/S e os custos de desempenho associados à obtenção de itens que são acedidos com frequência. A Figura 2 mostra um exemplo de criação de partições verticais. Neste exemplo, as diferentes propriedades de um item são armazenadas em partições diferentes. Uma partição contém dados que são acedidos com mais frequência, incluindo o nome do produto, a descrição e o preço. Outra partição contém dados de inventário: a contagem de cotações e a data da última encomenda.

Figura 2 – partição vertical de dados pelo padrão de utilização.

Neste exemplo, a aplicação consulta regularmente o nome, a descrição e o preço do produto ao apresentar os detalhes do produto aos clientes. A contagem de cotações e a data da última encomenda são mantidas numa partição separada porque estes dois itens são normalmente utilizados em conjunto.

Outras vantagens da criação de partições verticais:

• Os dados relativamente lentos (nome do produto, descrição e preço) podem ser separados dos dados mais dinâmicos (nível do stock e data da última encomenda). Os dados de movimentação lenta são um bom candidato para uma aplicação colocar em cache na memória.

• Os dados confidenciais podem ser armazenados numa partição separada com controlos de segurança adicionais.

• A criação de partições verticais pode reduzir a quantidade de acesso simultâneo necessário.

A criação de partições verticais funciona ao nível da entidade dentro de um arquivo de dados, normalizando parcialmente uma entidade para a dividir, de um item amplo para um conjunto de itens estreitos. Idealmente, é adequada aos arquivos de dados orientados para colunas, como o HBase e Cassandra. Se for pouco provável que os dados numa coleção de colunas sejam alterados, pode também considerar a utilização de arquivos de colunas no SQL Server.

Criação de partições funcionais

Quando é possível identificar um contexto vinculado para cada área de negócio distinta numa aplicação, a criação de partições funcionais é uma forma de melhorar o isolamento e o desempenho do acesso a dados. Outra utilização comum para a criação de partições funcionais é separar os dados de leitura-escrita dos dados só de leitura. A Figura 3 mostra uma descrição geral da criação de partições funcionais em que os dados de inventário estão separados dos dados de cliente.

Figura 3 – criação funcional de partições de dados por contexto vinculado ou subdomínio.

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

Estruturar partições para escalabilidade

É essencial considerar o tamanho e a carga de trabalho de cada partição e equilibrá-los de modo a que os dados sejam distribuídos de modo a alcançar a escalabilidade máxima. No entanto, também tem de particionar os dados para que não excedam os limites de dimensionamento de um único arquivo de partições.

Ao estruturar as partições para escalabilidade, siga estes passos:

1. Analise a aplicação para compreender os padrões de acesso aos dados, como o tamanho do conjunto de resultados devolvido 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 irão requerer a maioria dos recursos de processamento.
2. Utilize esta análise para determinar as metas de escalabilidade atuais e futuras, como o tamanho dos dados e a carga de trabalho. Em seguida, distribua os dados pelas partições para ir de encontro à meta de escalabilidade. Para a criação de partições horizontais, é importante escolher a chave de partição horizontal correta para garantir que a distribuição é uniforme. Para obter mais informações, veja o padrão de fragmentação.
3. Confirme que cada partição tem recursos suficientes para processar os requisitos de escalabilidade, em termos de tamanho e débito de dados. Dependendo do arquivo de dados, pode existir um limite na quantidade de espaço de armazenamento, energia de processamento ou largura de banda de rede por partição. Se os requisitos forem susceptíveis de exceder estes limites, poderá ter de refinar a sua estratégia de criação de partições ou dividir ainda mais os dados, possivelmente combinando duas ou mais estratégias.
4. Monitorize o sistema para verificar se os dados estão distribuídos conforme esperado e se as partições conseguem processar a carga. A utilização real nem sempre corresponde ao que uma análise prevê. Se for o caso, poderá ser possível reequilibrar as partições ou redesenhar algumas partes do sistema para obter o equilíbrio necessário.

Alguns ambientes da cloud alocam recursos em termos de limites de infraestrutura. Certifique-se de que os limites do seu limiar selecionado fornecem espaço suficiente para qualquer crescimento previsto do volume de dados, em termos de armazenamento de dados, capacidade de processamento e largura de banda.

Por exemplo, se utilizar o armazenamento de tabelas do Azure, existe um limite para o volume de pedidos que pode ser processado por uma única partição num determinado período de tempo. (Para obter mais informações, veja Metas de desempenho e escalabilidade do armazenamento do Azure.) Uma partição horizontal ocupada pode necessitar de mais recursos do que uma única partição pode processar. Se for o caso, a partição horizontal poderá ter de ser repartida para distribuir a carga. Se o tamanho total ou débito destas tabelas exceder a capacidade de uma conta de armazenamento, poderá ter de criar contas de armazenamento adicionais e distribuir as tabelas por estas contas.

Estruturar partições para desempenho de consultas

Muitas vezes, o desempenho das consultas pode ser aumentado através da utilização de conjuntos de dados mais pequenos e ao executar consultas paralelas. Cada partição deve conter uma pequena proporção do conjunto completo de dados. Esta redução de volume pode melhorar o desempenho das consultas. No entanto, a criação de partições não é uma alternativa para estruturar e configurar uma base de dados adequadamente. Por exemplo, certifique-se de que tem os índices necessários implementados.

Ao estruturar as partições para desempenho de consultas, siga estes passos:

1. Verifique os requisitos e o desempenho da aplicação:

   • Utilize os requisitos empresariais para determinar as consultas críticas que têm de ser sempre executadas rapidamente.
   • Monitorize o sistema para identificar quaisquer consultas com execução lenta.
   • Determinar que consultas 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.

2. Particione os dados que estão a causar o desempenho lento:

   • Limite o tamanho de cada partição de forma a que o tempo de resposta de consulta esteja dentro da meta.
   • Se utilizar a criação de partições horizontais, crie a chave de partição horizontal para que a aplicação possa selecionar facilmente a partição correta. Isto impede que a consulta tenha de analisar cada partição.
   • Considere a localização de uma partição. Se for possível, tente manter os dados nas partições que estão geograficamente próximas das aplicações e dos utilizadores que lhes acedem.

3. Se uma entidade tiver requisitos de débito e de desempenho de consultas, utilize a criação de partições funcionais com base nessa entidade. Se isto não satisfazer os requisitos, aplique também a criação de partições horizontais. Na maioria dos casos, será suficiente uma única estratégia de criação de partições, mas em alguns casos é mais eficiente combinar ambas as estratégias.

4. Considere executar consultas em paralelo entre partições para melhorar o desempenho.

Estruturar partições para disponibilidade

A criação de partições de dados pode melhorar a disponibilidade das aplicações, garantindo que todo o conjunto de dados não constitui um ponto único de falha e que os subconjuntos individuais do conjunto de dados podem ser geridos de forma independente.

Considere os seguintes fatores que afetam a disponibilidade:

O quão críticos os dados são para as operações empresariais. Identifique que dados são informações comerciais críticas, como transações, e que dados são dados operacionais menos críticos, como ficheiros de registo.

• Considere armazenar dados críticos em partições de elevada disponibilidade com um plano de cópia de segurança adequado.

• Estabeleça procedimentos de gestão e monitorização separados para os diferentes conjuntos de dados.

• Coloque os dados com o mesmo nível de criticidade na mesma partição, para que possa ser feita uma cópia de segurança dos mesmos em conjunto, com uma frequência adequada. Por exemplo, as partições que contêm dados de transação podem ter de ser criadas cópias de segurança com mais frequência do que as partições que contêm informações de registo ou rastreio.

Como as partições individuais podem ser geridas. Estruturar partições para suportar a gestão e manutenção independentes proporciona várias vantagens. Por exemplo:

• Se uma partição falhar, pode ser recuperada de forma independente sem aplicações que acedam a dados noutras partições.

• A criação de partições de dados por área geográfica permite que as tarefas de manutenção agendada ocorram fora das horas de ponta para cada localização. Certifique-se de que as partições não são demasiado grandes para impedir que qualquer manutenção planeada seja concluída durante este período.

Se pretende replicar dados críticos em partições. Esta estratégia pode melhorar a disponibilidade e o desempenho, mas também pode introduzir problemas de consistência. Demora algum tempo a sincronizar as alterações com cada réplica. Durante este período, partições diferentes irão conter valores de dados diferentes.

Considerações de design de aplicações

A criação de partições adiciona complexidade à conceção e desenvolvimento do seu sistema. Considere a criação de partições como uma parte fundamental da conceção do sistema, mesmo se o sistema apenas contiver inicialmente uma só partição. Se abordar a criação de partições como uma reflexão posterior, será mais desafiante porque já tem um sistema em direto para manter:

• A lógica de acesso a dados terá de ser modificada.
• Podem ter de ser migradas grandes quantidades de dados existentes para distribuí-los pelas partições.
• Os utilizadores esperam poder continuar a utilizar o sistema durante a migração.

Em alguns casos, a criação de partições não é considerada importante porque o conjunto de dados inicial é pequeno e pode facilmente ser processado por um único servidor. Isto pode ser verdade para algumas cargas de trabalho, mas muitos sistemas comerciais têm de ser expandidos à medida que o número de utilizadores aumenta.

Além disso, não são apenas os grandes arquivos de dados que beneficiam da criação de partições. Por exemplo, um arquivo de dados pequeno poderá ser intensamente acedido por centenas de clientes em simultâneo. A criação de partições de dados nesta situação pode ajudar a reduzir a contenção e melhorar o débito.

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

Minimizar as operações de acesso a dados entre partições. Sempre que possível, mantenha juntos os dados das operações de base de dados mais comuns em cada partição para minimizar as operações de acesso aos dados entre partições. A consulta entre partições pode ser mais demorada do que a consulta numa única partição, mas otimizar partições para um conjunto de consultas pode afetar negativamente outros conjuntos de consultas. Se tiver de consultar entre partições, minimize o tempo de consulta ao executar consultas paralelas e agregar os resultados na aplicação. (Esta abordagem pode não ser possível em alguns casos, como quando o resultado de uma consulta é utilizado na consulta seguinte.)

Considere replicar dados de referência estática. Se as consultas utilizarem dados de referência relativamente estáticos, como tabelas de código postal ou listas de produtos, considere replicar estes dados em todas as partições para reduzir operações de pesquisa separadas em partições diferentes. Esta abordagem também pode reduzir a probabilidade de os dados de referência se tornarem um conjunto de dados "frequente", com tráfego intenso de todo o sistema. No entanto, existe um custo adicional associado à sincronização de quaisquer alterações aos dados de referência.

Minimizar associações entre partições. Sempre que possível, minimize os requisitos de integridade referencial através de partições verticais e funcionais. Nestes esquemas, a aplicação é responsável por manter a integridade referencial entre partições. As consultas que associam dados em várias partições são ineficientes porque a aplicação normalmente precisa de executar consultas consecutivas com base numa chave e, em seguida, numa chave externa. Em vez disso, considere replicar ou anular a normalização dos dados relevantes. Se forem necessárias associações entre partições, execute consultas paralelas nas partições e associe os dados na aplicação.

Adote a consistência eventual. Avalie se a consistência forte é, de facto, um requisito. Uma abordagem comum nos sistemas distribuídos consiste em implementar a consistência eventual. Os dados em cada partição são atualizados separadamente e a lógica da aplicação assegura que as atualizações são todas concluídas com êxito. Lida igualmente com as inconsistência que possam surgir de consultar dados enquanto uma operação eventualmente consistente está em execução.

Considere a forma como as consultas localizam a partição correta. Se uma consulta tiver de analisar todas as partições para localizar os dados necessários, há um impacto significativo no desempenho, mesmo quando estão em execução várias consultas paralelas. Com a criação de partições verticais e funcionais, as consultas podem especificar naturalmente a partição. A criação de partições horizontais, por outro lado, pode dificultar a localização de um item, uma vez que cada partição horizontal tem o mesmo esquema. Uma solução típica para manter um mapa que é utilizado para procurar itens específicos na localização da partição horizontal. Este mapa pode ser implementado na lógica de fragmentação da aplicação ou mantido pelo arquivo de dados, se este suportar a fragmentação transparente.

Considere reequilibrar periodicamente as partições horizontais. Com a criação de partições horizontais, o reequilíbrio das partições horizontais pode ajudar a distribuir os dados uniformemente pelo tamanho e pela carga de trabalho para minimizar os hotspots, maximizar o desempenho das consultas e contornar as limitações de armazenamento físico. No entanto, esta é uma tarefa complexa que requer, muitas vezes, a utilização de uma ferramenta ou processo personalizado.

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

Se atingir os limites físicos de uma estratégia de criação de partições, poderá ter de expandir a escalabilidade para um nível diferente. Por exemplo, se estiver a criar partições ao nível de base de dados, poderá ter de localizar ou replicar partições em várias bases de dados. Se a criação de partições já se encontra ao nível de base de dados e as limitações físicas forem um problema, poderá significar que tem de localizar ou replicar partições em várias contas de alojamento.

Evite as transações que acedem a dados em várias partições. Alguns arquivos de dados implementam a consistência transacional e a integridade para operações que modificam dados, mas apenas quando os dados estão localizados numa única partição. Se precisar de suporte transacional entre várias partições, provavelmente terá de implementar isto como parte da sua lógica de aplicação porque a maioria dos sistemas de partição não fornecem suporte nativo.

Todos os arquivos de dados requerem alguma gestão operacional e monitorização da atividade. As tarefas podem variar entre carregar dados, fazer cópias de segurança e restaurar dados, reorganizar dados e garantir que o sistema está a funcionar correta e eficientemente.

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

• Como implementar tarefas de gestão e operacionais adequadas quando os dados estão particionados. Estas tarefas podem incluir fazer cópia de segurança e restaurar, arquivar dados, monitorizar o sistema e outras tarefas administrativas. Por exemplo, a manutenção da consistência lógica durante as operações de cópia de segurança e restauro pode ser um desafio.

• Como carregar os dados para várias partições e adicionar novos dados provenientes de outras origens. Algumas ferramentas e utilitários podem não suportar as operações de dados em partição horizontal, como carregar dados para a partição correta.

• Como arquivar e eliminar os dados regularmente. Para evitar o crescimento excessivo de partições, tem de arquivar e eliminar dados regularmente (como mensalmente). Poderá ser necessário transformar os dados para que correspondam a um esquema de arquivo diferente.

• Como localizar problemas de integridade de dados. Considere executar um processo periódico para localizar quaisquer problemas de integridade de dados, como dados numa partição que faça referência a informações em falta noutra. O processo pode tentar corrigir estes problemas automaticamente ou gerar um relatório para revisão manual.

Reequilibrar partições

À medida que um sistema amadurece, poderá ter de ajustar o esquema de criação de partições. Por exemplo, as partições individuais podem começar a obter um volume de tráfego desproporcionado e a tornar-se frequentes, o que leva a uma contenção excessiva. Em alternativa, pode ter subestimado o volume de dados em algumas partições, fazendo com que algumas partições se aproximem dos limites de capacidade.

Alguns arquivos de dados, como o Azure Cosmos DB, podem reequilibrar automaticamente as partições. Noutros casos, o reequilíbrio é uma tarefa administrativa que consiste em duas fases:

1. Determine uma nova estratégia de criação de partições.

   • Que partições têm de ser divididas (ou possivelmente combinadas)?
   • Qual é a nova chave de partição?

2. Migrar dados do antigo esquema de criação de partições para o novo conjunto de partições.

Dependendo do arquivo de dados, poderá conseguir migrar dados entre partições enquanto estão a ser utilizadas. Isto chama-se migração online. Se isso não for possível, poderá ter de tornar as partições indisponíveis enquanto os dados são relocalizados (migração offline).

Migração offline

Normalmente, a migração offline é mais simples porque reduz as possibilidades de contenção. Conceptualmente, a migração offline funciona da seguinte forma:

1. Marcar a partição offline.
2. Intercalar 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, pode marcar uma partição como só de leitura no passo 1, para que as aplicações possam continuar a ler os dados enquanto estão a ser movidas.

Migração online

A migração online é mais complexa para realizar, mas menos disruptiva. O processo é semelhante à migração offline, exceto que a partição original não está marcada como offline. Dependendo da granularidade do processo de migração (por exemplo, item por item versus partição horizontal), o código de acesso a dados nas aplicações cliente poderá ter de processar dados de leitura e escrita que são mantidos em duas localizações, a partição original e a nova partição.

Passos seguintes

• Saiba mais sobre estratégias de criação de partições para serviços específicos do Azure. Veja Estratégias de criação de partições de dados.
• Metas de escalabilidade e desempenho do armazenamento do Azure

Recursos relacionados

• Escolher o arquivo de dados certo

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

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

• O padrão da tabela de índice mostra como criar índices secundários através de dados. Uma aplicação pode rapidamente obter dados com esta abordagem, através de consultas que não façam referência à chave primária de uma coleção.

• O padrão de vista materializado descreve como gerar vistas pré-preenchidas que resumem dados para suportar operações de consulta rápidas. Esta abordagem poderá ser útil num arquivo de dados particionado, se as partições que contêm os dados que estão a ser resumidos estiverem distribuídas por vários sites.