Recomendações para a criação de partições de dados

Artigo
11/15/2023

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

RE:06	Implemente uma estratégia de dimensionamento atempadamente e fiável ao nível da aplicação, dos dados e da infraestrutura.

Guia relacionado:Dimensionamento

Este guia descreve as recomendações para conceber uma estratégia de criação de partições de dados para a base de dados e a tecnologia de armazenamento de dados que implementar. Esta estratégia ajuda-o a melhorar a fiabilidade do seu património de dados.

Principais estratégias de conceção

Em muitas soluções de grande escala, as partições são utilizadas para dividir dados para que possam ser geridas e acedidas separadamente. A criação de partições de dados melhora a escalabilidade, reduz a contenção e otimiza o desempenho. Implemente a criação de partições de dados para dividir dados por padrão de utilização. Por exemplo, pode arquivar dados mais antigos num armazenamento de dados barato. Escolha cuidadosamente a sua estratégia de criação de partições para maximizar os benefícios e minimizar os efeitos adversos.

Nota

Neste artigo, o termo criação de partições significa o processo de dividir fisicamente os dados em arquivos de dados separados. Difere da criação de partições de tabelas SQL Server.

Porquê criar partições de dados?

Melhorar a escalabilidade. Quando aumenta verticalmente um único sistema de bases de dados, a base de dados atinge eventualmente um limite de hardware físico. Se dividir dados entre várias partições, com cada partição alojada num servidor separado, pode aumentar horizontalmente o sistema quase indefinidamente.
Melhorar o desempenho. Em cada partição, as operações de acesso a dados são executadas num volume de dados mais pequeno em comparação com os dados que não estão particionados. Particione dados para tornar o seu sistema mais eficiente. As operações que afetam mais do que uma partição podem ser executadas em paralelo.
Melhorar a segurança. Em alguns casos, pode separar dados confidenciais e sem sentido em partições diferentes e aplicar controlos de segurança diferentes aos dados confidenciais.
Fornecer flexibilidade operacional. Pode particionar dados para ajustar as operações, maximizar a eficiência administrativa e minimizar os custos. Por exemplo, pode definir estratégias para gestão, monitorização, cópia de segurança e restauro e outras tarefas administrativas com base na importância dos dados em cada partição.
Corresponder o arquivo de dados ao padrão de utilização. Pode implementar cada partição num tipo diferente de arquivo de dados com base no custo e nas funcionalidades incorporadas que o arquivo de dados oferece. Por exemplo, pode armazenar grandes dados binários no armazenamento de blobs e armazenar dados estruturados numa base de dados de documentos. Para obter mais informações, veja Compreender os modelos do arquivo de dados.
Melhorar a disponibilidade. Para evitar um único ponto de falha, pode separar os dados em vários servidores. Se uma instância falhar, apenas os dados nessa partição não estão disponíveis. As operações continuam noutras partições. Esta consideração é menos relevante para arquivos de dados paaS (plataforma como serviço) geridos porque têm redundância incorporada.

Criar partições

Existem três estratégias típicas para a criação de 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 dos dados, como um conjunto de encomendas 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 funcional. Nesta estratégia, os dados são agregados de acordo com a forma como cada contexto vinculado no sistema utiliza os dados. 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.

Considere combinar estas estratégias 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 imagem seguinte mostra um exemplo de criação de partições horizontais ou fragmentação. Este exemplo divide os dados de inventário de produtos em partições horizontais baseadas 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. Quando efetua a fragmentação, esta 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 escolher. 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 grandes, mas cada item na partição horizontal tem um número baixo de operações de acesso. Outras partições horizontais podem ser mais pequenas, mas cada item na partição horizontal é acedido com mais frequência. 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, se utilizar a primeira letra do nome de um cliente, pode criar uma distribuição desequilibrada porque algumas letras são mais comuns do que outras. Em vez disso, utilize 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 partições horizontais grandes, combinar pequenas partições horizontais em partições maiores ou alterar o esquema. Estas operações são morosas e podem exigir que leve uma ou mais partições horizontais offline.

Se as partições horizontais forem replicadas, pode manter algumas das réplicas online enquanto outras são divididas, intercaladas 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 só de leitura para impedir inconsistências de dados.

Para obter mais informações, veja Sharding pattern (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 acedidos com frequência. A imagem seguinte 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, incluindo a contagem de stock e a data da última encomenda.

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

Veja as seguintes vantagens da criação de partições verticais:

Pode separar os dados relativamente lentos (nome do produto, descrição e preço) de dados mais dinâmicos (nível de stock e data da última encomenda). Os dados de movimentação lenta são uma boa opção para uma aplicação colocar em cache na memória.
Pode armazenar dados confidenciais numa partição separada com controlos de segurança adicionados.
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. É ideal para arquivos de dados orientados para colunas, como o HBase e o Cassandra. Se for pouco provável que os dados numa coleção de colunas sejam alterados, considere utilizar arquivos de colunas no SQL Server.

Criação de partições funcionais

Quando um contexto vinculado pode ser identificado para cada área de negócio distinta numa aplicação, a criação de partições funcionais pode 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 imagem seguinte mostra uma descrição geral da criação de partições funcionais com dados de inventário separados dos dados do cliente.

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

Criar partições para escalabilidade

É fundamental 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 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.

Siga estes passos quando criar partições para escalabilidade:

Analise a aplicação para compreender os padrões de acesso a 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 exigem a maioria dos recursos de processamento.
Utilize esta análise para determinar os objetivos de escalabilidade atuais e futuros, 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, escolha a chave de partição horizontal correta para garantir a distribuição uniforme. Para obter mais informações, veja Sharding pattern (Padrão de fragmentação).
Certifique-se de que cada partição tem recursos suficientes para lidar com os requisitos de escalabilidade em termos de tamanho e débito de dados. Consoante o arquivo de dados, pode existir um limite para cada partição na quantidade de espaço de armazenamento, energia de processamento ou largura de banda de rede. Se for provável que os requisitos excedam estes limites, poderá ter de refinar a estratégia de criação de partições ou dividir ainda mais os dados. Poderá ter de combinar duas ou mais estratégias.
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ê. Poderá ter de reequilibrar as partições ou redesenhar algumas partes do sistema para obter o saldo necessário.

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

Por exemplo, se utilizar o Armazenamento de Tabelas do Azure, existe um limite para o volume de pedidos que uma única partição pode processar num determinado período de tempo. Para obter mais informações, veja Metas de escalabilidade e desempenho para contas de armazenamento padrão. Uma partição horizontal ocupada pode necessitar de mais recursos do que uma única partição pode processar. Poderá ter de criar novas partições da partição horizontal 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 mais contas de armazenamento e distribuir as tabelas por estas contas.

Criar partições para desempenho de consultas

Pode aumentar o desempenho das consultas ao utilizar pequenos conjuntos de dados e executar consultas paralelas. Cada partição deve conter uma pequena proporção de todo o conjunto de dados. Esta redução de volume pode melhorar o desempenho das consultas. No entanto, a criação de partições não é uma alternativa à estrutura e configuração da base de dados adequadas. Certifique-se de que implementa os índices necessários.

Siga estes passos quando criar partições para desempenho de consultas:

Examine 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 as consultas que funcionam 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 a causar um 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 adequada. Esta especificação impede que a consulta digitalize cada partição.
- Considere a localização de uma partição. Tente manter os dados em partições geograficamente próximas das aplicações e dos utilizadores que acedem aos mesmos.
Se uma entidade tiver requisitos de desempenho de débito e consulta, utilize a criação de partições funcional baseada nessa entidade. Se esta alocação ainda não cumprir os requisitos, pode adicionar a criação de partições horizontais. Normalmente, uma única estratégia de criação de partições é adequada, mas, em alguns casos, é mais eficiente combinar ambas as estratégias.
Execute consultas em paralelo entre partições para melhorar o desempenho.

Criar partições para disponibilidade

Particionar dados para melhorar a disponibilidade das aplicações. A criação de partições garante que todo o conjunto de dados não tem um ponto único de falha e que pode gerir subconjuntos individuais do conjunto de dados de forma independente.

Considere os seguintes fatores que afetam a disponibilidade:

Determine a importância dos dados. Identifique os dados empresariais críticos, como transações e os dados operacionais menos críticos, como ficheiros de registo.

Armazene dados críticos em partições de elevada disponibilidade e crie um plano de cópia de segurança adequado.
Estabeleça procedimentos de gestão e monitorização separados para diferentes conjuntos de dados.
Coloque os dados que têm o mesmo nível de criticidade na mesma partição para que possa ser criada uma cópia de segurança com a mesma frequência. Por exemplo, poderá ter de fazer uma cópia de segurança das partições que contêm dados de transação mais frequentemente do que as partições que contêm informações de registo ou rastreio.

Gerir partições individuais. Crie partições para suportar gestão e manutenção independentes. Esta prática fornece 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 agendadas ocorram fora das horas de ponta para cada localização. Certifique-se de que as partições não são tão grandes que impedem a conclusão da manutenção planeada durante este período.

Replicar dados críticos entre partições. Esta estratégia melhora 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 a sincronização, as diferentes partições contêm 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. Os dados de partição são uma parte fundamental da estrutura do sistema, mesmo que o sistema contenha inicialmente apenas uma única partição. Se abordar a criação de partições como uma reflexão posterior, é um desafio porque já tem um sistema em direto para manter. Poderá:

Tem de modificar a lógica de acesso a dados.
Tem de migrar grandes quantidades de dados existentes para distribuí-los por partições.
Deparar-se com desafios porque os utilizadores esperam continuar a utilizar o sistema durante a migração.

Em alguns casos, a criação de partições não é importante porque o conjunto de dados inicial é pequeno e um único servidor consegue processá-lo facilmente. Algumas cargas de trabalho podem ficar sem partições, mas muitos sistemas comerciais têm de ser expandidos à medida que o número de utilizadores aumenta.

Alguns pequenos arquivos de dados também beneficiam da criação de partições. Por exemplo, centenas de clientes simultâneos podem aceder a um pequeno arquivo de dados. Se particionar os 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. Tente manter os dados das operações de base de dados mais comuns juntas numa 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 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. Em alguns casos, não pode utilizar esta abordagem, por exemplo, se o resultado de uma consulta for utilizado na consulta seguinte.

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. Existem custos adicionais associados à sincronização de 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 executa normalmente consultas consecutivas baseadas 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 é 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 garante que as atualizações são concluídas com êxito. A lógica da aplicação também processa as inconsistências que surgem da consulta de dados enquanto uma operação eventualmente consistente é executada.

Considere a forma como as consultas localizam a partição correta. Se uma consulta tiver de analisar todas as partições para localizar os dados necessários, afeta significativamente o desempenho, mesmo quando são executadas várias consultas paralelas. Com a criação de partições verticais e funcionais, as consultas podem especificar a partição. Por outro lado, a criação de partições horizontais pode dificultar a localização de um item porque cada partição horizontal tem o mesmo esquema. Uma solução típica é manter um mapa que é utilizado para procurar a localização de partições horizontais dos itens. Implemente este mapa na lógica de fragmentação da aplicação. Também pode ser mantido pelo arquivo de dados se o arquivo de dados suportar a fragmentação transparente.

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

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

Expandir a escalabilidade para um nível diferente. Se atingir os limites físicos de uma estratégia de criação de partições, poderá ter de expandir a escalabilidade para um nível diferente. Por exemplo, se estiver a criar partições ao nível de base de dados, poderá ter de localizar ou replicar partições em várias bases de dados. Se a criação de partições já estiver ao nível da base de dados e existirem limitações físicas, poderá ter 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 e integridade transacionais para operações que modificam dados, mas apenas quando os dados estão localizados numa única partição. Se precisar de suporte transacional em várias partições, implemente-o como parte da lógica da sua aplicação, uma vez que a maioria dos sistemas de criação de partições não fornece suporte nativo.

Todos os arquivos de dados requerem alguma gestão operacional e monitorização da atividade. Estas tarefas incluem carregar dados, criar cópias de segurança e restaurar dados, reorganizar dados e garantir que o sistema tem um desempenho correto e eficiente.

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

Implemente tarefas operacionais e de gestão adequadas quando os dados sã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, pode ser difícil manter a consistência lógica durante as operações de cópia de segurança e restauro.
Carregue dados para várias partições e adicione novos dados provenientes de outras origens. Algumas ferramentas e utilitários podem não suportar operações de dados fragmentados, como carregar dados para a partição correta.
Arquivar e eliminar dados regularmente. Para evitar o crescimento excessivo de partições, arquive e elimine dados todos os meses. Poderá ter de transformar os dados para corresponder a um esquema de arquivo diferente.
Localizar problemas de integridade de dados. Considere executar um processo periódico para localizar problemas de integridade de dados, como dados numa partição que faz referência a informações em falta noutra. O processo pode tentar corrigir automaticamente estes problemas 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 receber um volume de tráfego desproporcionado e tornar-se frequentes, o que leva a uma contenção excessiva. Em alternativa, 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 arquivos de dados, como o Azure Cosmos DB, podem reequilibrar automaticamente as partições. Noutros casos, pode reequilibrar as partições em duas fases:

Determine uma nova estratégia de criação de partições.
- Que partições têm de ser divididas ou combinadas?
- Qual é a nova chave de partição?
Migrar dados do esquema de criação de partições antigo para o novo conjunto de partições.

Poderá ter de tornar as partições indisponíveis enquanto deslocaliza os dados, o que é chamado de migração offline. Consoante o arquivo de dados, pode migrar dados entre partições enquanto estão a ser utilizadas. Esta técnica chama-se migração online.

Migração offline

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

Marcar a partição como offline. Pode marcar uma partição como só de leitura para que as aplicações ainda possam ler os dados enquanto os move.
Intercalar e mover os dados para as novas partições.
Verificar os dados.
Coloque 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 não marca a partição original como offline. Consoante a 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 ler e escrever dados em duas localizações, a partição original e a nova partição.

Facilitação do Azure

As secções seguintes descrevem recomendações para a criação de partições de dados armazenados nos serviços do Azure.

Partição na Base de Dados do SQL do Azure

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

Os conjuntos elásticos suportam o dimensionamento horizontal para uma base de dados SQL. Utilize conjuntos elásticos para particionar os seus dados em partições horizontais que estão distribuídas por várias bases de dados SQL. Também pode adicionar ou remover partições horizontais à medida que o volume de dados aumenta e diminui. Os conjuntos elásticos também podem ajudar a reduzir a contenção ao distribuir a carga pelas bases de dados.

Cada partição horizontal é implementada como uma base de dados SQL. Uma partição horizontal pode conter mais do que um conjunto de dados. Cada conjunto de dados é denominado shardlet. Cada base de dados tem metadados que descrevem os shardlets que contém. Um shardlet pode ser um único item de dados ou um grupo de itens que partilham a mesma chave de shardlet. Por exemplo, numa aplicação multi-inquilino, a chave shardlet pode ser o ID de inquilino e todos os dados de um inquilino podem estar no mesmo shardlet.

As aplicações são responsáveis por associar um conjunto de dados a uma chave de shardlet. Uma base de dados SQL separada atua como um gestor global dos mapas das partições horizontais. Esta base de dados tem uma lista de todas as partições horizontais e shardlets no sistema. A aplicação liga-se à base de dados do gestor de mapas de partições horizontais para obter uma cópia do mapa de partições horizontais. Coloca o mapa de partições horizontais em cache localmente e utiliza o mapa para encaminhar pedidos de dados para a partição horizontal adequada. Esta funcionalidade está oculta por trás de uma série de APIs contidas na biblioteca de cliente da funcionalidade Base de Dados Elástica do Base de Dados SQL, que está disponível para Java e .NET.

Para obter mais informações sobre conjuntos elásticos, veja Aumentar horizontalmente com Base de Dados SQL.

Para reduzir a latência e melhorar a disponibilidade, pode replicar a base de dados global do gestor de mapas de partições horizontais. Com os escalões de preço premium, pode configurar a georreplicação ativa para copiar continuamente dados para bases de dados em diferentes regiões.

Em alternativa, utilize Sincronização de Dados SQL para Base de Dados SQL ou Azure Data Factory para replicar a base de dados do gestor de mapas de partições horizontais entre regiões. Esta forma de replicação é executada periodicamente e é mais adequada se o mapa de partições horizontais for alterado com pouca frequência e não exigir o escalão premium.

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

Um mapa de partições horizontais de lista associa uma única chave a um shardlet. Por exemplo, num sistema multi-inquilino, os dados de cada inquilino podem ser associados a uma chave exclusiva e armazenados no seu próprio shardlet. Para garantir o isolamento, cada shardlet pode ser mantido dentro da sua própria partição horizontal.

Transfira um ficheiro do Visio deste diagrama.
Um mapa de partições horizontais de intervalo associa um conjunto de valores de chave contíguos a um shardlet. Por exemplo, pode agrupar os dados de um conjunto de inquilinos, cada um com a sua própria chave, no mesmo shardlet. Este esquema é menos dispendioso do que um mapa de partições horizontais de lista porque os inquilinos partilham o armazenamento de dados, mas proporciona menos isolamento.

Transferir um ficheiro do Visio deste diagrama

Uma única partição horizontal pode conter os dados de vários shardlets. Por exemplo, pode utilizar shardlets de lista para armazenar dados de diferentes inquilinos não contínuos na mesma partição horizontal. Também pode misturar shardlets de intervalo e listar shardlets na mesma partição horizontal, mas depois são abordados através de mapas diferentes. O diagrama seguinte mostra esta abordagem:

Transfira um ficheiro do Visio deste diagrama.

Com os conjuntos elásticos, pode adicionar e remover partições horizontais à medida que o volume de dados cresce e diminui. As aplicações cliente podem criar e eliminar partições horizontais de forma dinâmica e transparente para atualizar o gestor de mapas de partições horizontais. No entanto, a remoção de uma partição horizontal é uma operação destrutiva que também requer a eliminação de todos os dados nessa partição horizontal.

Se uma aplicação precisar de dividir uma partição horizontal em duas partições horizontais separadas ou combinar partições horizontais, utilize a ferramenta de intercalação dividida. Esta ferramenta é executada como um serviço Web do Azure e migra dados de forma segura entre partições horizontais.

O esquema de criação de partições pode afetar significativamente o desempenho do seu sistema. Também pode afetar a taxa a que as partições horizontais têm de ser adicionadas ou removidas, ou que os dados têm de ser reparticionados entre partições horizontais. Considere os pontos seguintes:

Agrupe os dados utilizados em conjunto na mesma partição horizontal e evite operações que acedam a dados de várias partições horizontais. Uma partição horizontal é uma base de dados SQL por si só e as associações entre bases de dados têm de ser efetuadas no lado do cliente quando as operações acedem a várias partições horizontais.

Embora Base de Dados SQL não suporte associações entre bases de dados, pode utilizar as ferramentas da Base de Dados Elástica para executar consultas com várias partições horizontais. Uma consulta com várias partições horizontais envia consultas individuais para cada base de dados e intercala os resultados.
Crie um sistema que não tenha dependências entre partições horizontais. As restrições de integridade referencial, os acionadores e os procedimentos armazenados numa base de dados não podem referenciar objetos noutra.
Considere replicar dados entre partições horizontais se tiver dados de referência que são frequentemente utilizados por consultas. Esta abordagem pode eliminar a necessidade de associar dados entre bases de dados. Idealmente, esses dados devem ser estáticos ou em movimento lento para minimizar o esforço de replicação e reduzir a probabilidade de ficarem obsoletos.
Utilize o mesmo esquema para shardlets que pertencem ao mesmo mapa de partições horizontais. Esta documentação de orientação não é imposta por Base de Dados SQL, mas a gestão de dados e a consulta são complexas se cada shardlet tiver um esquema diferente. Em vez disso, crie mapas de partições horizontais separados para cada esquema. Pode armazenar dados que pertencem a shardlets diferentes na mesma partição horizontal.
Armazene dados na mesma partição horizontal ou implemente a consistência eventual se a lógica de negócio precisar de realizar transações. As operações transacionais só são suportadas para dados numa partição horizontal e não entre partições horizontais. As transações podem abranger shardlets se forem parte da mesma partição horizontal.
Coloque as partições horizontais perto dos utilizadores que acedem aos dados nessas partições horizontais. Esta estratégia ajuda a reduzir a latência.
Evite ter uma combinação de partições horizontais altamente ativas e relativamente inativas. Tente distribuir a carga uniformemente por partições horizontais. Poderá ter de hashar as chaves de fragmentação. Se estiver a geolocalizar partições horizontais, certifique-se de que as chaves de hash mapeiam para shardlets mantidos em partições horizontais armazenadas perto dos utilizadores que acedem a esses dados.

Partição no Armazenamento de Blobs do Azure

Com o Armazenamento de Blobs, pode armazenar objetos binários grandes. Utilize blobs de blocos em cenários que exijam que carregue ou transfira rapidamente grandes volumes de dados. Utilize blobs de páginas para aplicações que necessitem de acesso aleatório, em vez de em série, a partes dos dados.

Cada blob de blocos ou blob de páginas é mantido num contentor numa conta de armazenamento do Azure. Utilize contentores para agrupar blobs relacionados com os mesmos requisitos de segurança. Este agrupamento é lógico, em vez de físico. Dentro de um contentor, cada blob tem um nome exclusivo.

A chave de partição de um blob é o nome da conta, o nome do contentor e o nome do blob. A chave de partição é utilizada para particionar dados em intervalos. Estes intervalos têm balanceamento de carga em todo o sistema. Os blobs podem ser distribuídos por vários servidores para aumentar horizontalmente o acesso aos mesmos. Um único blob só pode ser servido por um único servidor.

Se o seu esquema de nomenclatura utilizar carimbos de data/hora ou identificadores numéricos, pode levar a tráfego excessivo para uma partição. Impede o sistema de balancear a carga de forma eficaz. Por exemplo, se tiver operações diárias que utilizam um objeto de blob com um carimbo de data/hora, como aaaa-mm-dd, todo o tráfego dessa operação será enviado 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, veja Convenção de nomenclatura de partições.

As ações de escrita de 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 precisar de garantir a consistência quando as operações de escrita são executadas em blocos, páginas e blobs, remova um bloqueio de escrita com uma concessão de blobs.

Considerações

A criação de partições de dados apresenta alguns desafios e complexidades que tem de considerar.

A sincronização de dados entre as partições pode tornar-se um desafio. Certifique-se de que as atualizações ou alterações a uma partição são propagadas para as outras partições de forma oportuna e consistente.
Os processos de ativação pós-falha e recuperação após desastre tornam-se complexos quando precisa de coordenar a cópia de segurança e o restauro de várias partições. Podem ocorrer problemas de integridade dos dados se algumas partições ou as respetivas cópias de segurança estiverem danificadas ou indisponíveis.
A criação de partições de dados pode afetar o desempenho e a fiabilidade se precisar de consultar entre partições e quando reequilibrar as partições se os dados crescerem de forma desigual.

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade

Recomendações para a criação de partições de dados