Escalabilidade no Azure DocumentDB

O Azure DocumentDB oferece a capacidade de escalar clusters tanto vertical como horizontalmente. Embora o nível do cluster de computação e o disco de armazenamento dependam funcionalmente um do outro, a escalabilidade e o custo de computação e armazenamento estão desacoplados.

Dimensionamento vertical

A escala vertical oferece os seguintes benefícios:

• As equipas de aplicações podem nem sempre ter um caminho claro para fragmentar logicamente os seus dados. Além disso, o sharding lógico é definido para cada coleção. Num conjunto de dados com várias coleções não fragmentadas, a modelação de dados para particionar os dados pode rapidamente tornar-se aborrecida. Simplesmente escalar o cluster pode contornar a necessidade de sharding lógico, ao mesmo tempo que satisfaz as crescentes necessidades de armazenamento e computação da aplicação.
• A escalabilidade vertical não requer reequilíbrio de dados. O número de fragmentos físicos mantém-se igual e apenas a capacidade do cluster é aumentada sem impacto na aplicação.
• A escala para cima e para baixo são operações sem tempo de inatividade, sem interrupções no serviço. Não são necessárias alterações na aplicação e as operações em regime estacionário podem continuar sem perturbações.
• Os recursos de computação também podem ser reduzidos durante janelas de tempo conhecidas de baixa atividade. Mais uma vez, reduzir a escala evita a necessidade de reequilibrar os dados em menos shards físicos e é uma operação sem tempo de inatividade, sem interrupções no serviço. Também aqui, não são necessárias alterações na aplicação após reduzir a escala do cluster.
• Mais importante ainda, computação e armazenamento podem ser escalados de forma independente. Se forem necessários mais núcleos e memória, o tamanho do disco pode ser mantido como está e o nível do cluster pode ser ampliado. Da mesma forma, se for necessário mais armazenamento e IOPS, a camada do cluster pode ser mantida como está e o tamanho do armazenamento pode ser escalado de forma independente. Se necessário, tanto o cálculo como o armazenamento podem ser escalados independentemente para otimizar individualmente os requisitos de cada componente, sem que os requisitos de elasticidade de um dos componentes afetem o outro.

Dimensionamento horizontal

Eventualmente, a aplicação cresce até ao ponto em que escalar verticalmente deixa de ser suficiente. Os requisitos de carga de trabalho podem ultrapassar a capacidade do maior cluster tier e, eventualmente, são necessários mais fragmentos. A escalabilidade horizontal no Azure DocumentDB oferece os seguintes benefícios:

• Conjuntos de dados logicamente fragmentados não requerem intervenção do utilizador para equilibrar os dados entre os fragmentos físicos subjacentes. O serviço mapeia automaticamente fragmentos lógicos para fragmentos físicos. Quando os nós são adicionados ou removidos, os dados são automaticamente reequilibrados na base de dados sob as coberturas.
• Os pedidos são automaticamente encaminhados para o shard físico relevante que detém o intervalo de hash dos dados a consultar.
• Clusters geo-distribuídos têm uma configuração homogénea de múltiplos nós. Assim, os mapeamentos lógicos para fragmentos físicos são consistentes entre as regiões primária e réplica de um cluster.

Computação e escalabilidade de armazenamento

Os recursos de computação e memória influenciam as operações de leitura no Azure DocumentDB mais do que os IOPS de disco.

• As operações de leitura consultam primeiro a cache na camada de computação e depois voltam ao disco quando os dados não podem ser recuperados da cache. Para cargas de trabalho com maior taxa de operações de leitura por segundo, escalar a camada do cluster para obter mais recursos de CPU e memória leva a um maior rendimento.
• Para além da taxa de leitura, cargas de trabalho com um elevado volume de dados por operação de leitura também beneficiam do escalamento dos recursos computacionais do cluster. Por exemplo, os níveis de cluster com mais memória facilitam maiores cargas úteis por documento e um maior número de documentos mais pequenos por resposta.

O IOPS de disco influencia mais as operações de escrita no Azure DocumentDB do que as capacidades de CPU e memória dos recursos de computação.

• As operações de escrita persistem sempre os dados no disco (além dos dados persistentes na memória para otimizar as leituras). Discos maiores com mais IOPS oferecem maior rendimento de escrita, especialmente quando operam em grande escala.
• O serviço suporta até 32 TB de discos por shard, com mais IOPS por shard para beneficiar cargas de trabalho intensas de escrita, especialmente quando em grande escala.

Cargas de trabalho intensivas em armazenamento e discos grandes

Não existem requisitos mínimos de armazenamento por nível de cluster

Como mencionado anteriormente, os recursos de armazenamento e computação são desacoplados para faturação e provisionamento. Embora funcionem como uma unidade coesa, podem ser escaladas de forma independente. A camada de cluster M30 pode ter discos de 32 TB provisionados. De forma semelhante, o nível de cluster M200 pode ter discos de 32 GB provisionados para otimizar tanto os custos de armazenamento como de computação.

Menor TCO com discos grandes (32 TB e mais)

Normalmente, as bases de dados NoSQL limitam o armazenamento por shard físico a 4 TB. O Azure DocumentDB oferece até 8 vezes essa capacidade com discos de 32 TB. Para cargas de trabalho pesadas em armazenamento, uma capacidade de armazenamento de 4 TB por shard físico requer uma frota massiva de recursos computacionais apenas para sustentar os requisitos de armazenamento da carga de trabalho. A computação é mais cara do que o armazenamento e o excesso de provisionamento devido aos limites de capacidade num serviço pode inflacionar rapidamente os custos.

Vamos considerar uma carga de trabalho pesada em armazenamento com 200 TB de dados.

A redução nos requisitos de Computação diminui drasticamente com discos maiores. Embora possa ser necessário mais do que o número mínimo de fragmentos físicos para sustentar os requisitos de throughput da carga de trabalho, até duplicar ou triplicar o número de fragmentos é mais rentável do que um cluster de 50 fragmentos com discos mais pequenos.

Saltar a hierarquização de armazenamento com discos grandes

Uma resposta imediata aos custos de cálculo em cenários pesados de armazenamento é "escalonar" os dados. Os dados na base de dados transacional são limitados aos dados "quentes" mais frequentemente acedidos, enquanto o maior volume de dados "frios" é destacado para um armazenamento a frio. Isto causa complexidade operacional. O desempenho também é imprevisível e depende do nível de dados acedido. Além disso, a disponibilidade de todo o sistema depende da resiliência dos armazenamentos de dados quentes e frios combinados. Com discos grandes integrados no serviço, não há necessidade de armazenamento hierárquico, uma vez que o custo de cargas de trabalho intensivas em armazenamento é minimizado.

Próximos passos

• Aprenda a escalar o cluster Azure DocumentDB
• Consulte as melhores práticas de indexação