Fragmentação para escalabilidade horizontal no Azure DocumentDB

O Azure DocumentDB dá suporte à fragmentação para distribuir horizontalmente dados e tráfego. Os documentos dentro de uma coleção são divididos em partes chamadas fragmentos lógicos.

A fragmentação é definida individualmente para cada coleção usando uma chave de fragmentação designada da estrutura de documentos da coleção. Em seguida, os dados são colocados em partes com cada parte correspondente a uma partição lógica. Documentos para cada valor exclusivo da propriedade de chave de fragmentação residem na mesma fragmentação lógica.

Para cada documento inserido em uma coleção fragmentada, o valor da propriedade de chave de fragmento é hashed para calcular o fragmento lógico designado. O ônus de colocar o fragmento lógico e distribuir todos os fragmentos lógicos dentro do cluster são abstraídos do usuário e totalmente gerenciados pelo serviço.

Fragmentos lógicos

Todos os documentos que contêm o mesmo valor para a chave de fragmento pertencem ao mesmo fragmento lógico.

Por exemplo, vamos considerar uma coleção chamada Employees com a estrutura do documento abaixo.

Esta tabela mostra um mapeamento de valores de chave de fragmentação para partições lógicas.

• Não há limites para o número de fragmentos lógicos de uma coleção. Uma coleção pode ter tantos fragmentos lógicos quanto documentos com um valor exclusivo para a propriedade de chave de fragmento em cada documento.

• Também não há limites para o tamanho de um único fragmento lógico.

• Além disso, o serviço não limita as transações ao escopo de um fragmento lógico. O Azure DocumentDB dá suporte a transações de leitura e gravação aplicáveis em vários fragmentos lógicos e em vários fragmentos físicos no cluster.

Fragmentos físicos

Os fragmentos físicos são os computadores e discos subjacentes responsáveis por persistir os dados e cumprir transações de banco de dados. Diferentemente dos shards lógicos, os shards físicos são gerenciados pelo serviço de forma transparente.

O número de fragmentos físicos é definido quando um cluster é criado e pode ser aumentado se o tamanho do banco de dados aumentar ao longo do tempo. Clusters de fragmento único têm um fragmento físico (nó) que é inteiramente responsável pelo armazenamento e pelas transações de banco de dados do cluster. Clusters multishard distribuem os dados e o volume de transações entre os fragmentos físicos no cluster.

Mapeamento de fragmentos lógicos para fragmentos físicos

Quando novos fragmentos lógicos são adicionados, o cluster atualiza de forma integrada o mapeamento de fragmentos lógicos para físicos. Da mesma forma, a atribuição do espaço de endereço para cada fragmento físico é alterada à medida que novos fragmentos físicos são adicionados ao cluster após o qual os fragmentos lógicos são rebalanceados no cluster.

O intervalo de hash usado para mapear fragmentos lógicos e físicos é distribuído uniformemente entre os fragmentos físicos no cluster. Cada fragmentação física possui um bucket de tamanho igual do intervalo de hash. Para cada documento escrito, o valor da propriedade da chave de fragmento é hash e o valor de hash determina o mapeamento do documento para o fragmento físico subjacente. Internamente, vários fragmentos lógicos são mapeados para um único fragmento físico. Além disso, os fragmentos lógicos nunca são divididos entre fragmentos físicos e todos os documentos de um fragmento lógico são mapeados apenas para um fragmento físico.

Com base no exemplo anterior usando um cluster com dois fragmentos físicos, esta tabela mostra um mapeamento de exemplo de documentos para fragmentos físicos.

Capacidade de fragmentos físicos

A camada de cluster selecionada quando o cluster é provisionado determina a capacidade de CPU e memória de um fragmento físico. Da mesma forma, o SKU de armazenamento determina a capacidade de armazenamento e IOPS de um fragmento físico. Camadas de cluster maiores fornecem mais potência de computação e memória maior, enquanto discos de armazenamento maiores fornecem mais armazenamento e IOPS. As cargas de trabalho pesadas de leitura se beneficiam de uma camada de cluster maior enquanto as cargas de trabalho pesadas de gravação se beneficiam de um SKU de armazenamento maior. A camada de cluster pode ser escalada para cima ou para baixo depois de criado o cluster, baseadas nas mudanças nas necessidades do aplicativo.

Em um cluster multishard, a capacidade de cada shard físico é a mesma. Aumentar a camada de cluster ou o SKU de armazenamento não altera o posicionamento de fragmentos lógicos nos fragmentos físicos. Após uma operação de expansão, o número de fragmentos físicos permanece o mesmo, evitando a necessidade de reequilibrar os dados no cluster.

A capacidade de computação, memória, armazenamento e IOPS do fragmento físico determina os recursos disponíveis para os fragmentos lógicos. Chaves de fragmentação que não têm uma distribuição uniforme dos volumes de armazenamento e solicitações podem causar consumo desigual de armazenamento e taxa de transferência no cluster. Partições frequentes podem fazer com que shards físicos sejam utilizados de forma desigual, levando a uma taxa de transferência e desempenho imprevisíveis. Assim, os clusters fragmentados exigem um planejamento cuidadoso antecipadamente para garantir que o desempenho permaneça consistente à medida que os requisitos do aplicativo mudam ao longo do tempo.

Conjuntos de réplicas

Cada shard físico consiste em um conjunto de réplicas, também chamado de conjunto de réplicas. Cada réplica hospeda uma instância do mecanismo de banco de dados. Um conjunto de réplicas torna o armazenamento de dados no shard físico bem durável, altamente disponível e consistente. Cada réplica que compõe o fragmento físico herda a capacidade de armazenamento e computação do fragmento físico. O Azure DocumentDB gerencia automaticamente os conjuntos de réplicas.

Práticas recomendadas para fragmentação de dados

• A fragmentação no Azure DocumentDB não é necessária, a menos que os volumes de transação e armazenamento da coleção possam exceder a capacidade de um único fragmento físico. Por exemplo, o serviço fornece discos de 32 TB por partição. Se uma coleção exigir mais de 32 TB, ela deverá ser fragmentada.

• Não é necessário fragmentar todas as coleções em um cluster com vários fragmentos físicos. Coleções fragmentadas e não fragmentadas podem coexistir no mesmo cluster. O serviço distribui de forma ideal as coleções dentro do cluster para utilizar uniformemente os recursos de computação e armazenamento do cluster da maneira mais uniforme possível.

• Para aplicações com alta demanda de leitura, a chave de partição deve ser selecionada com base nos padrões de consulta mais frequentes. O filtro de consulta mais usado para uma coleção deve ser escolhido como a chave de fragmento para otimizar a maior porcentagem de transações de banco de dados localizando a pesquisa em um único fragmento físico.

• Para aplicativos com alta carga de gravação que favorecem o desempenho de gravação em detrimento de leituras, uma chave de partição deve ser escolhida para que os dados sejam distribuídos uniformemente entre as partições físicas. Chaves de fragmentação com a maior cardinalidade oferecem a melhor oportunidade de distribuição uniforme.

• Para um desempenho ideal, o tamanho de armazenamento de um fragmento lógico deve ser menor que 4 TB.

• Para um desempenho ideal, os fragmentos lógicos devem ser distribuídos uniformemente no volume de armazenamento e solicitação entre os fragmentos físicos do cluster.

Como fragmentar uma coleção

Considere o documento a seguir dentro do banco de dados 'cosmicworks' e da coleção 'employee'

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

A amostra a seguir fragmenta a coleção de funcionários no banco de dados cosmicworks na propriedade firstName.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

A coleção também pode ser fragmentada usando um comando de administrador:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Embora não seja ideal alterar a chave de fragmentação depois que a coleção crescer significativamente em volume de armazenamento, o comando reshardCollection pode ser usado para alterar a chave de fragmentação.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

A coleção também pode ser redistribuída usando um comando de administrador.

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

Como prática recomendada, um índice deve ser criado na propriedade de chave de fragmento.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Próximas etapas

• Saiba como dimensionar o cluster do Azure DocumentDB
• Confira as melhores práticas de indexação