Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Azure DocumentDB oferece a capacidade de dimensionar clusters vertical e horizontalmente. Embora a camada de cluster de computação e o disco de armazenamento dependam funcionalmente uns dos outros, a escalabilidade e o custo da computação e do armazenamento são dissociados.
Dimensionamento vertical
O dimensionamento vertical oferece os seguintes benefícios:
- As equipes de aplicativos podem nem sempre ter um caminho claro para fragmentar logicamente seus dados. Além disso, a fragmentação lógica é definida por coleção. Em um conjunto de dados com várias coleções não fragmentadas, a modelagem de dados para particionar o conjunto pode se tornar entediante rapidamente. Simplesmente escalonar o cluster verticalmente pode driblar a necessidade de fragmentação lógica e, ao mesmo tempo, atender às necessidades crescentes de armazenamento e computação do aplicativo.
- O dimensionamento vertical não requer rebalanceamento de dados. O número de fragmentos físicos permanece o mesmo e apenas a capacidade do cluster é aumentada sem impacto para o aplicativo.
- As operações de aumento e redução de escala são realizadas sem tempo de inatividade, sem interrupções no serviço. Nenhuma alteração de aplicativo é necessária e as operações de estado estável podem continuar sem perturbação.
- Os recursos de computação também podem ser reduzidos durante períodos conhecidos de baixa atividade. Mais uma vez, reduzir verticalmente evita a necessidade de rebalancear dados em um menor número de fragmentos físicos e é uma operação com zero tempo de inatividade e nenhuma interrupção do serviço. Aqui também, nenhuma alteração de aplicativo é necessária depois de reduzir o cluster.
- O mais importante é que a computação e o armazenamento podem ser dimensionados de forma independente. Se mais núcleos e memória forem necessários, o tamanho do disco poderá ser deixado como está e a camada de cluster poderá ser ampliada. Da mesma forma, se mais armazenamento e IOPS forem necessários, a camada de cluster poderá ser deixada como está e o tamanho do armazenamento poderá ser dimensionado de forma independente. Se necessário, a computação e o armazenamento podem ser dimensionados de forma independente para otimizar individualmente os requisitos de cada componente, sem que os requisitos de elasticidade de qualquer componente afetem o outro.
Dimensionamento em escala horizontal
Eventualmente, o aplicativo aumenta a um ponto em que o dimensionamento vertical não é suficiente. Os requisitos de carga de trabalho podem aumentar além da capacidade da maior camada de cluster e, eventualmente, mais fragmentos são necessários. O dimensionamento horizontal no Azure DocumentDB oferece os seguintes benefícios:
- Conjuntos de dados fragmentados logicamente não exigem intervenção do usuário para equilibrar os dados entre os fragmentos físicos subjacentes. O serviço mapeia automaticamente fragmentos lógicos para fragmentos físicos. Quando nós são adicionados ou removidos, os dados são rebalanceados no banco de dados automaticamente sem que você perceba.
- As solicitações são roteadas automaticamente para o fragmento físico relevante que possui o intervalo de hash para os dados que estão sendo consultados.
- Os clusters distribuídos geograficamente têm uma configuração homogênea de vários nós. Assim, os mapeamentos de fragmentos lógicos para físicos são consistentes nas regiões primária e de réplica de um cluster.
Dimensionamento de computação e armazenamento
Os recursos de computação e memória influenciam as operações de leitura no Azure DocumentDB mais do que a IOPS de disco.
- As operações de leitura primeiro consultam o cache na camada de computação e retornam para o disco quando os dados não puderam ser recuperados do cache. Para cargas de trabalho com uma taxa mais alta de operações de leitura por segundo, escalar verticalmente a camada de cluster para obter mais recursos de CPU e memória leva a uma taxa de transferência maior.
- Além da taxa de transferência de leitura, cargas de trabalho com um alto volume de dados por operação de leitura também se beneficiam do dimensionamento dos recursos de computação do cluster. Por exemplo, camadas de cluster com mais memória facilitam tamanhos de conteúdo maiores por documento e um número maior de documentos menores por resposta.
O IOPS de disco influencia as operações de gravação no Azure DocumentDB mais do que as capacidades de CPU e memória dos recursos de computação.
- As operações de gravação sempre persistem dados em disco (além de persistir dados na memória para otimizar leituras). Discos maiores com mais IOPS fornecem maior taxa de transferência de gravação, especialmente quando operados em larga escala.
- O serviço dá suporte a discos de até 32 TB por fragmento, com mais IOPS por fragmento para beneficiar cargas de trabalho com uso intensivo de gravação, especialmente quando executadas em grande escala.
Cargas de trabalho intensivas de armazenamento e discos grandes
Nenhum requisito mínimo de armazenamento por camada de cluster
Conforme mencionado anteriormente, os recursos de armazenamento e computação são dissociados para cobrança e provisionamento. Embora funcionem como uma unidade coesa, elas podem ser dimensionadas de forma independente. A camada de cluster M30 pode ter discos de 32 TB provisionados. Da mesma forma, a camada de cluster M200 pode ter discos de 32 GB provisionados para otimizar os custos de armazenamento e de computação.
TCO inferior com discos grandes (32 TB e além)
Normalmente, os bancos de dados NoSQL limitam o armazenamento por fragmento físico a 4 TB. O Azure DocumentDB fornece até 8x essa capacidade com discos de 32 TB. Para cargas de trabalho pesadas de armazenamento, uma capacidade de armazenamento de 4 TB por fragmento físico requer uma enorme frota de recursos de computação apenas para manter os requisitos de armazenamento da carga de trabalho. A computação é mais cara do que o armazenamento, e o provisionamento excessivo de recursos computacionais devido a limites de capacidade de um serviço pode aumentar os custos rapidamente.
Vamos considerar uma carga de trabalho pesada de armazenamento com 200 TB de dados.
| Tamanho do armazenamento por fragmento | Fragmentos mínimos necessários para sustentar 200 TB |
|---|---|
| 4 TiB | 50 |
| 32 TiB | 7 |
A necessidade de computação diminui significativamente com discos maiores. Embora um número de fragmentos físicos superior ao mínimo possa ser necessário para sustentar os requisitos de taxa de transferência da carga de trabalho, dobrar ou triplicar o número de fragmentos continua sendo mais econômico do que um cluster de 50 fragmentos com discos menores.
Ignorar o armazenamento em níveis no caso de discos grandes
Uma resposta imediata aos custos de computação em cenários pesados de armazenamento é "colocar em camada" os dados. Os dados no banco de dados transacional são limitados aos dados "quentes" acessados com mais frequência, enquanto o volume maior de dados "frios" é armazenado em um repositório frio. Isso causa complexidade operacional. O desempenho também é imprevisível e depende da camada de dados acessada. Além disso, a disponibilidade de todo o sistema depende da resiliência dos armazenamentos de dados quentes e frios combinados. Com discos grandes no serviço, não há necessidade de armazenamento em camadas, pois o custo das cargas de trabalho intensivas em armazenamento é minimizado.