Fragmentação para escalabilidade horizontal no Azure Cosmos DB for MongoDB vCore
O Azure Cosmos DB for MongoDB vCore 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 fragmento 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. Os documentos para cada valor exclusivo da propriedade de chave de fragmento residem no mesmo fragmento lógico.
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 é abstraído do usuário e totalmente gerenciada 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 Funcionários com a estrutura do documento abaixo.
Esta tabela mostra um mapeamento de valores de chave de fragmento para partições lógicas.
| ID do Documento | Valor de chave de fragmento | Fragmento Lógico |
|---|---|---|
| “12345” | "Steve Smith" | Fragmento 1 |
| "23456" | "Jane Doe" | Fragmento 2 |
| "34567" | "Steve Smith" | Fragmento 1 |
| "45678" | "Michael Smith" | Fragmento 3 |
| "56789" | "Jane Doe" | Fragmento 2 |
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 serviço baseado em vCore do Azure Cosmos DB for MongoDB 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. Ao contrário dos fragmentos lógicos, o serviço gerencia fragmentos físicos sob as coberturas.
O número de fragmentos físicos é definido quando um cluster é criado. Clusters de fragmentos únicos têm um fragmento físico que é inteiramente responsável pelas transações de armazenamento e banco de dados do cluster. Clusters de vários fragmentos 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 perfeita 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 fragmento físico possui um bucket de tamanho uniforme 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.
| ID do Documento | Valor de chave de fragmento | Fragmento Lógico | Fragmento Físico |
|---|---|---|---|
| “12345” | "Steve Smith" | Fragmento 1 | Fragmento Físico 1 |
| "23456" | "Jane Doe" | Fragmento 2 | Fragmento Físico 2 |
| "34567" | "Steve Smith" | Fragmento 1 | Fragmento Físico 1 |
| "45678" | "Michael Smith" | Fragmento 3 | Fragmento Físico 1 |
| "56789" | "Jane Doe" | Fragmento 2 | Fragmento Físico 2 |
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 expandida para cima e para baixo depois que o cluster é criado com base nas necessidades de alteração do aplicativo.
Em um cluster de vários fragmentos, a capacidade de cada fragmento físico é a mesma. Escalar verticalmente 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 fragmento que não têm uma distribuição uniforme de volumes de armazenamento e solicitação podem causar armazenamento irregular e consumo de taxa de transferência dentro do cluster. Partições quentes podem fazer com que os fragmentos 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 fragmento físico consiste em um conjunto de réplicas, também conhecido como um 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 dentro do fragmento físico 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 vCore do Azure Cosmos DB for MongoDB gerencia automaticamente os conjuntos de réplicas.
Melhores práticas para a fragmentação de dados
A fragmentação no vCore do Azure Cosmos DB for MongoDB 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 fragmento. 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 advocadas 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 aplicativos pesados de leitura, a chave de fragmento 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 pesados de gravação que favorecem o desempenho de gravação em vez de leituras, uma chave de fragmento deve ser escolhida para distribuir uniformemente os dados entre os fragmentos físicos. Chaves de fragmento com a maior cardinalidade fornecem a melhor oportunidade para distribuir uniformemente o mais uniformemente possível.
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 seguinte documento dentro do banco de dados “cosmicworks” e da coleção “employee”
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
O exemplo 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 fragmento depois que a coleção tiver crescido significativamente no volume de armazenamento, o comando reshardCollection pode ser usado para alterar a chave de fragmento.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
A coleção também pode ser refragmentada 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
})