Particionamento de banco de dados

Conforme declarado na página Como os dados são armazenados página, bancos de dados particionados permitem que seu aplicativo co-localize documentos no mesmo shard usando a chave de partição do documento. Esta página o ajuda a descobrir se o seu modelo de dados é adequado para uso com bancos de dados particionados.

OIBM® Cloudant® for IBM Cloud®suporta dois tipos de bancos de dados:

Não particionado: o tipo padrão. Os documentos são atribuídos aos shards automaticamente pelo banco de dados para equilibrar a carga de trabalho.
Particionado: os IDs de documento contêm uma chave de partição especificada pelo aplicativo que afeta a forma como os dados são alocados aos fragmentos.

IBM Cloudant recomenda que você utilize um banco de dados particionado somente nos casos em que o modelo de dados permita o particionamento lógico de documentos em várias (mais de 500) partições. Consulte Determinação da adequação do banco de dados particionado para obter ajuda para entender se o seu aplicativo pode usar bancos de dados particionados.

Do ponto de vista do aplicativo, a principal diferença entre um banco de dados não particionado e um banco de dados particionado é como você pode consultar seus dados:

Um banco de dados não particionado permite que apenas os índices secundários globais sejam criados e consultados.
Um banco de dados particionado permite a criação e a consulta de índices secundários globais e particionados.

Este documento contém mais detalhes sobre os casos de uso de cada tipo de índice.

Limites para bancos de dados particionados

Os bancos de dados particionados têm limites para o número de índices e o tamanho total de todos os documentos com a mesma chave de partição.

As consultas com escopo de partição têm um tempo limite imposto pelo serviço mais curto do que as globais e um limite menor no total de documentos que podem ser recuperados em uma HTTP solicitação.

Consulte IBM Cloudant Limits para obter detalhes sobre essas restrições.

Razões para usar um banco de dados particionado

Os bancos de dados particionados são ideais quando seu aplicativo se beneficia do agrupamento de documentos relacionados e precisa de um desempenho de consulta previsível e escalável.

Um banco de dados particionado permite consultas tanto no âmbito da partição quanto globais. A consulta com escopo de partição aproveita a co-localização de documentos com uma determinada chave de partição, permitindo um desempenho de consulta mais eficiente e dimensionável. Para cargas de trabalho que podem ser expressas em termos de uma chave de partição, isso pode reduzir significativamente a latência da consulta e diminuir os custos.

O particionamento é especialmente valioso quando seu aplicativo precisa de desempenho previsível previsível em escala. As consultas com escopo de partição que fazem uso eficaz de índices permanecem rápidas, mesmo com o crescimento do conjunto de dados, e podem ser dimensionadas com eficiência em até 64 shards. Isso torna os bancos de dados particionados adequados para cargas de trabalho de alta taxa de transferência e baixa latência.

Normalmente, quando o conjunto de dados requer muitos shards de banco de dados, os aplicativos usam consultas com escopo de partição para operações sensíveis à latência, enquanto as consultas globais são reservadas para tarefas menos críticas em termos de tempo, como o processamento em lote.

Motivos pelos quais os bancos de dados particionados podem não ser adequados

Os bancos de dados particionados exigem uma modelagem cuidadosa dos dados e podem exigir a duplicação de índices. Para muitos casos de uso, esse esforço extra não compensa.

Embora os bancos de dados particionados ofereçam benefícios de desempenho quando usados adequadamente, eles introduzem restrições que podem não se alinhar a todas as cargas de trabalho. Você deve definir uma chave de partição significativa para seus aplicativos que agrupe documentos documentos relacionados e que ofereça suporte a consultas eficientes. Se cada documento tiver uma chave exclusiva, ou se houver muito poucas chaves de partição, é provável que os bancos de dados particionados tenham um desempenho pior do que os bancos de dados não particionados.

As consultas com escopo de partição exigem que você crie índices particionados. Isso pode pode exigir a manutenção de índices globais e particionados, dependendo dos padrões de acesso do seu aplicativo.

Determinação da adequação do banco de dados particionado

Agora você entende as vantagens e desvantagens dos bancos de dados particionados, a próxima etapa é entender se o seu modelo de dados funcionará bem com um banco de dados particionado.

Avalie seu modelo de dados e as necessidades do aplicativo em relação a estes critérios para determinar a adequação do banco de dados particionado:

Uma alta cardinalidade das chaves de partição é essencial: o número de chaves de partição distintas deve ser muito maior do que o número de fragmentos.
A carga da consulta deve ser distribuída uniformemente: se a maioria das consultas tiver como alvo uma única chave de partição, isso poderá criar pontos de acesso e prejudicar o desempenho.
As chaves de partição devem agrupar documentos relacionados: se cada chave mapear apenas um documento, o particionamento oferece poucos benefícios.

Exemplos-chave de partições boas e ruins

Para fundamentar isso, vamos analisar alguns casos de uso e algumas escolhas boas e ruins para uma chave de partição.

Boas e más escolhas para uma chave de partição
Caso de Uso	Chave da partição	Bom ou ruim	Motivo
Sistema de e-commerce - pedidos	`customer_id`	Bom	Alta cardinalidade e as consultas são distribuídas entre muitos clientes.
Sistema de e-commerce - pedidos	`order_id`	Inválido	Um documento por partição; sem agrupamento ou reutilização.
Sistema de e-commerce - pedidos	`status`	Inválido	A baixa cardinalidade dos valores de status (provisório, pago, reembolsado, cancelado) cria muito poucas partições.
Sistema de e-commerce - pedidos	`country_code`	Inválido	Baixa cardinalidade; alguns países dominam o tráfego.
IOT - leituras do sensor	`device_id`	Bom	Muitos dispositivos geram dados, distribuindo a carga uniformemente.
IOT - leituras do sensor	`reading_id`	Inválido	Único por documento; as partições contêm apenas um item.
IOT - leituras do sensor	`date`	Inválido	A maioria das consultas tem como alvo datas recentes, o que causa hot-spots.
IOT - leituras do sensor	`region`	Inválido	Poucas regiões podem dominar o tráfego, levando a um desequilíbrio.

Existem alguns casos de uso em que não há nenhuma opção viável para uma chave de partição. Nessas situações, um banco de dados não particionado é a melhor opção. Por exemplo, um banco de dados de usuários que armazena endereços de e-mail, hashes de senha e datas de último login. Nenhum desses campos é adequado como chave de partição; portanto, deve-se usar, em vez disso, um banco de dados não particionado.

Criação de bancos de dados e índices particionados

Você deve decidir se deseja criar partições no momento da criação do banco de dados. Ao criar um banco de dados, use o parâmetro de sequência de consultas partitioned para configurar se o banco de dados está particionado. O padrão para partitioned é false.

Da mesma forma, um índice é global ou particionado; você define isso ao você define isso ao criar um índice usando o campo partitioned em seu documento de design. Todos os todos os índices no documento de design herdam o campo partitioned do documento de design do documento de design. Ao consultar um índice particionado, você usa consultas com escopo de partição que incluem a chave da partição a ser consultada em sua solicitação.

O tipo de particionamento de um índice ou banco de dados não pode ser alterado após sua criação.

As consultas com escopo de partição só podem ser feitas em índices particionados. Da mesma forma, as consultas globais só podem ser feitas em índices globais.

Consultando

IBM Cloudant suporta consultas globais e com escopo de partição. Para usar os dois tipos de forma eficaz, é necessário criar índices separados ser criados para cada escopo de consulta.

As consultas globais têm bom desempenho em bancos de dados com baixo número de fragmentos (16 ou menos), mas se tornam menos adequadas para operações sensíveis à latência à medida que o número de shards aumenta. Em contrapartida, as consultas com escopo de partição são dimensionadas de forma eficiente com com números maiores de fragmentos e são a opção preferida para aplicativos que exigem desempenho previsível e de baixa latência para grandes conjuntos de dados.

Para se beneficiar da consulta com escopo de partição, a maioria das consultas de aplicativos deve ter como alvo chaves de partição específicas. Isso permite que o banco de dados aproveite a da co-localização de documentos e ofereça desempenho consistente em escala.

Consulte Como o sharding afeta o desempenho do banco de dados para obter detalhes sobre como as consultas globais e com escopo de partição afetam o desempenho das operações do banco de dados.

Consulta global

Você pode fazer consultas globais usando:

A criação de um índice global é o padrão, mas você pode criar explicitamente um índice global usando "options.partitioned": false em seu documento de design:

{
  "options": {
    "partitioned": false
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

Consulta com escopo de partição

Você pode fazer consultas com escopo de partição usando:

Para criar um índice particionado que ofereça suporte a consultas com escopo de partição, especifique "options.partitioned": true em seu documento de design:

{
  "options": {
    "partitioned": true
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

Tutoriais de bancos de dados particionados

Os bancos de dados particionados podem ser difíceis de entender de forma abstrata. Você pode ver os conceitos em ação nestes dois exemplos:

Leia Criando um historiador IoT usando bancos de dados particionados para conhecer a fundo os bancos de dados particionados com exemplos em várias linguagens de programação.
Leia sobre bancos de dados particionados e o Node.js neste artigo do blog, que aborda como criar um banco de dados particionado, realizar pesquisas, usar visualizações e criar um índice global.