Como os dados são armazenados no IBM Cloudant?
Todo banco de dados no IBM® Cloudant® for IBM Cloud® é formado de um ou mais shards distintos, em que o número de shards é referido como Q
. Um shard é um subconjunto distinto de documentos do banco de dados.
Conceitos
Todos os shards Q
juntos contêm os dados dentro de um banco de dados. Cada shard é armazenado em três cópias separadas. Cada cópia de shard é chamada de réplica de shard. Cada réplica de shard é armazenada em um servidor diferente.
Os servidores estão disponíveis dentro de uma única Região. Se a Região suportar Zonas de disponibilidade, as réplicas serão armazenadas em servidores em diferentes Zonas. A coleção de servidores em uma Região é chamada de cluster.
Um documento é designado a um shard específico usando o hashing consistente de seu ID. Essa designação significa que um documento é sempre armazenado em um shard conhecido e um conjunto conhecido de servidores.
Ocasionalmente, os shards são rebalanceados. O rebalanceamento envolve mover réplicas para servidores diferentes. O rebalanceamento ocorre por várias razões, por exemplo, quando o monitoramento do servidor sugere que um servidor é mais ou menos usado do que outros servidores ou quando um servidor deve ser retirado de serviço temporariamente para manutenção. O número de shards e réplicas permanece o mesmo e os documentos permanecem designados ao mesmo shard, mas o local de armazenamento do servidor para uma réplica de shard muda.
O valor padrão para Q
varia para clusters diferentes. O valor pode ser ajustado ao longo do tempo.
O número de réplicas (cópias de um shard) também é configurável. Na prática, a observação e a medição de muitos sistemas sugerem que, na maioria dos casos, três réplicas são um número pragmático para se obter um bom equilíbrio entre o desempenho e a segurança de dados. Seria excepcional e incomum para um sistema IBM Cloudant usar uma contagem de réplica diferente.
Como a fragmentação afeta o desempenho?
O número de shards para um banco de dados é configurável porque afeta o desempenho do banco de dados de várias maneiras.
Quando uma solicitação entra no banco de dados por meio de um aplicativo cliente, um servidor ou 'nó' no cluster é designado como o coordenador da solicitação. Esse coordenador faz solicitações internas para os nós que contêm os dados relevantes para a solicitação, determina a resposta para a solicitação e retorna essa resposta ao cliente.
O número de shards para um banco de dados pode afetar o desempenho de duas maneiras:
-
Cada documento no banco de dados é armazenado em um único shard.
Portanto, ter muitos shards permite maior paralelismo para qualquer solicitação de documento único. O motivo é que o coordenador envia solicitações apenas para os nós que contêm o documento. Portanto, se o banco de dados tiver muitos shards, é provável que haja muitos outros nós que não precisam responder à solicitação. Esses nós podem continuar a funcionar em outras tarefas sem interrupção da solicitação do coordenador.
-
Para responder a uma solicitação de consulta, um banco de dados deve processar os resultados de todos os shards.
Portanto, ter mais shards introduz uma maior demanda de processamento. O motivo é que o coordenador deve fazer uma solicitação por shard e, em seguida, combinar os resultados antes que ele retorne a resposta para o cliente.
Para ajudar a determinar uma contagem adequada de shards para seu banco de dados, comece identificando os tipos mais comuns de solicitações feitas pelos aplicativos. Por exemplo, considere se as solicitações são principalmente para operações de documentos únicos ou as solicitações são na maioria consultas? Alguma das operações é sensível ao tempo?
Para todas as consultas, o coordenador emite solicitações de leitura para todas as réplicas. Essa abordagem é usada porque cada réplica mantém sua própria cópia dos índices que ajudam a responder consultas. Uma consequência importante dessa configuração é que uma quantidade maior de shards permitirá a construção de índices paralelos se as gravações de documentos forem distribuídas uniformemente nos shards no cluster.
Na prática, é difícil predizer o provável carregamento de indexação entre os nós no cluster. Além disso, predizer o carregamento de indexação tende a ser menos útil do que tratar de padrões de solicitação. O motivo é que a indexação poderá ser necessária após a gravação de um documento, mas não após a solicitação de um documento. Portanto, considerar a indexação sozinha não fornece informações suficientes para estimar uma contagem de shard apropriada.
Ao considerar o tamanho dos dados, uma consideração importante é o número de documentos por shard. Cada fragmento mantém seus documentos em uma grande Árvore B no disco. Os índices são armazenados da mesma maneira. Conforme mais documentos são incluídos em um shard, o número de etapas usadas para atravessar a árvore B durante uma consulta típica de documento ou uma consulta aumenta. Esse 'aumento de profundidade' tende a desacelerar as solicitações, porque mais dados devem ser lidos de caches ou do disco.
Em geral, evite ter mais de 10 milhões de documentos por shard. Em termos de tamanho geral do shard, manter os shards abaixo de 10 GB é útil por motivos operacionais. Por exemplo, shards menores são mais fáceis de mover pela rede durante o rebalanceamento.
Dados os requisitos conflitantes para evitar ter muitos documentos e manter o tamanho do shard baixo, um único valor Q
não pode funcionar de forma ideal para todos os casos. O IBM Cloudant ajusta os padrões para clusters ao longo
do tempo conforme os padrões de uso mudam.
Não obstante, para um banco de dados específico, geralmente é viável considerar o dimensionamento e os padrões de solicitação observados. É possível usar essas informações para orientar a seleção futura de um número apropriado de shards. Testar
com dados representativos e padrões de solicitação é essencial para uma melhor estimativa de bons valores Q
. Esteja preparado para uma experiência de produção para alterar essas expectativas.
As diretrizes simples a seguir podem ser úteis durante os estágios de planejamento iniciais. Lembre-se de validar sua configuração proposta testando com dados representativos, especificamente para bancos de dados maiores:
- Se o tamanho de seus dados for trivial, como algumas dezenas ou centenas de MB, ou milhares de documentos, então há pouca necessidade de mais de um único shard.
- Para bancos de dados com alguns GB ou alguns milhões de documentos, é provável que uma contagem de shards de único dígito, como 8, seja aceitável.
- Para bancos de dados maiores de dezenas a centenas de milhões de documentos ou dezenas de GB, considere configurar seu banco de dados para usar 16 shards.
- Para bancos de dados ainda maiores, considere fragmentar manualmente seus dados em vários bancos de dados. Para bancos de dados tão grandes, acesse o Portal de suporte do IBM Cloud para avisos.
Os números destas orientações derivam da observação e da experiência, e não de cálculos exactos.
Trabalhando com shards
Configurando a contagem de shards
O número de shards,
Q
, for a database is set when the database is created. O valor Q
não poderá ser mudado posteriormente.
Para especificar o Q
ao criar um banco de dados, use o parâmetro de sequência de consultas q
.
É possível configurar Q
. No entanto, você deseja proibir grandes valores de Q
já que eles têm um efeito deletério no serviço sem ganho de desempenho para o usuário.
Se você tentar definir o Q
valor onde ele não está disponível, o resultado será uma 403
resposta com um corpo JSON semelhante ao
exemplo a seguir:
{
"error": "forbidden",
"reason": "q is not configurable"
}
É possível modificar a configuração de uma topologia de sharding para um banco de dados em clusters de banco de dados dedicado. Essa modificação pode ser feita quando o banco de dados é criado. No entanto, más escolhas para parâmetros de configuração podem afetar negativamente o desempenho do banco de dados. Para obter mais informações sobre como modificar a configuração do banco de dados em um ambiente de banco de dados dedicado, entre em contato com o suporte do IBM Cloudant.
Configurando a contagem de réplicas
A partir da versão 2 do CouchDB, você tem permissão para especificar a contagem de réplicas ao criar um banco de dados. No entanto, não tem permissão para mudar o valor da contagem de réplicas do padrão de 3. Especificamente, não é possível especificar um valor de contagem de réplicas diferente ao criar um banco de dados. Para obter mais ajuda, acesse o IBM Cloud Portal de suporte.
Quais são os argumentos R
e W
?
Algumas solicitações podem ter argumentos que afetam o comportamento do coordenador quando ele responde à solicitação. Esses argumentos são conhecidos como R
e W
após seus nomes na sequência de consultas da solicitação.
Eles podem ser usados somente para operações de documento único. Eles não têm efeito nas solicitações gerais de 'estilo de consulta'.
Na prática, raramente é útil especificar os valores R
e W
. Por exemplo, especificar R
ou W
não altera a consistência para a leitura ou gravação.
O que é R
?
O argumento R
pode ser especificado somente em solicitações de documento único.
R
afeta a quantia de respostas que devem ser recebidas pelo coordenador antes de ele responder ao cliente. As respostas devem vir dos nós que hospedam as réplicas do shard que contém o documento.
A configuração de R
como 1 pode melhorar o tempo de resposta geral porque o coordenador pode retornar uma resposta mais rapidamente. O motivo é que o coordenador deve aguardar apenas uma única resposta de qualquer uma das réplicas
que hospedam o shard apropriado.
Quando o valor R
é reduzido, isso aumenta a probabilidade de a resposta retornada não ser baseada nos dados mais atualizados. Este estado ocorre devido ao modelo de consistência eventual usado por IBM Cloudant. Usar o valor R
padrão ajuda a minimizar esse efeito.
O valor padrão para R
é 2. Esse valor corresponde à maioria das réplicas para um banco de dados típico que usa três réplicas de shard. Se o banco de dados tiver diversas réplicas que sejam maiores ou menores que 3, o valor padrão
para R
mudará de forma correspondente.
O que é W?
W
pode ser especificado somente em solicitações de gravação de documento único.
W
é semelhante a R
porque afeta quantas respostas devem ser recebidas pelo coordenador antes que ele responda ao cliente.
O W
não afeta o comportamento de gravação real de nenhuma maneira.
O valor de W
não afeta se o documento é gravado no banco de dados ou não. Ao especificar um valor W
, o cliente pode inspecionar o código de status de HTTP na resposta para determinar se réplicas de W
responderam ao coordenador. O coordenador espera um tempo limite pré-determinado para as respostas W
dos nós que hospedam cópias do documento antes de retornar a resposta para o cliente.