Compartilhar via

Particionamento e escala horizontal no Azure Cosmos DB

O Azure Cosmos DB usa o particionamento para dimensionar contêineres em um banco de dados para atender às necessidades de desempenho do aplicativo. Os itens em um contêiner são divididos em subconjuntos distintos, chamados de partições lógicas. Formulário de partições lógicas com base no valor de uma chave de partição associada a cada item em um contêiner. Todos os itens em uma partição lógica têm o mesmo valor de chave de partição.

Por exemplo, um contêiner contém itens. Cada item tem um valor exclusivo para a propriedade UserID. Se UserID for a chave de partição dos itens no contêiner e houver 1.000 valores UserID exclusivos, 1.000 partições lógicas serão criadas para o contêiner.

Cada item em um contêiner tem uma chave de partição que determina sua partição lógica e uma ID de item exclusiva dentro dessa partição. A combinação da chave de partição com a ID do item cria o índice do item, que o identifica exclusivamente. A escolha de uma chave de partição é uma decisão importante que afetará o desempenho do aplicativo.

Este artigo explica a relação entre partições lógicas e físicas, discute as práticas recomendadas para particionamento e fornece uma visão detalhada de como o dimensionamento horizontal funciona no Azure Cosmos DB. Você não precisa entender esses detalhes internos para selecionar sua chave de partição, mas este artigo os aborda para esclarecer como o Azure Cosmos DB funciona.

Partições lógicas

Uma partição lógica é um conjunto de itens que compartilham a mesma chave de partição. Por exemplo, em um contêiner que contém dados sobre nutrição alimentar, todos os itens contêm uma propriedade foodGroup. Use foodGroup como a chave de partição para o contêiner. Grupos de itens que têm valores específicos para foodGroup, como Beef Products, Baked Products e Sausages and Luncheon Meats, formam partições lógicas distintas.

Uma partição lógica também define o escopo das transações de banco de dados. Você pode atualizar itens dentro de uma partição lógica usando uma transação com isolamento de instantâneo. Quando novos itens são adicionados a um contêiner, o sistema cria novas partições lógicas de forma transparente. Você não precisa se preocupar em excluir uma partição lógica quando os dados subjacentes são excluídos.

Não há limite para o número de partições lógicas em um contêiner. Cada partição lógica pode armazenar até 20 GB de dados. Chaves de partição efetivas têm uma ampla gama de valores possíveis. Por exemplo, em um contêiner em que todos os itens contêm uma propriedade foodGroup, os dados dentro da partição lógica Beef Products podem crescer até 20 GB. A seleção de uma chave de partição com uma grande variedade de valores possíveis garante que o contêiner consiga dimensionar.

Use alertas do Azure Monitor para monitorar se o tamanho de uma partição lógica está se aproximando de 20 GB.

Partições físicas

Um contêiner é dimensionado distribuindo dados e taxa de transferência entre partições físicas. Internamente, uma ou mais partições lógicas são mapeadas para uma única partição física. Normalmente, contêineres menores têm muitas partições lógicas, mas exigem apenas uma única partição física. Ao contrário das partições lógicas, as partições físicas são uma implementação interna do sistema e o Azure Cosmos DB as gerencia totalmente.

O número de partições físicas em um contêiner depende dessas características:

  • A quantidade de taxa de transferência provisionada (cada partição física individual pode fornecer uma taxa de transferência de até dez mil unidades de solicitação por segundo). O limite de 10.000 RU/s para partições físicas implica que as partições lógicas também têm um limite de 10.000 RU/s, pois cada partição lógica é mapeada apenas para uma partição física.

  • O armazenamento total de dados (cada partição física individual pode armazenar até 50 gigabytes de dados).

Observação

As partições físicas são uma implementação interna do sistema, totalmente gerenciada pelo Azure Cosmos DB. Ao desenvolver as soluções, não se concentre em partições físicas porque não é possível controlá-las. Em vez disso, concentre-se nas chaves de partição. Escolher uma chave de partição que distribua uniformemente o consumo de taxa de transferência entre partições lógicas garante um consumo de taxa de transferência equilibrado entre partições físicas.

Não há limite para o número total de partições físicas em um contêiner. À medida que a taxa de transferência ou o tamanho dos dados cresce, o Azure Cosmos DB cria automaticamente novas partições físicas ao dividir as existentes. As divisões de partição física não afetam a disponibilidade do aplicativo. Após essa divisão, todos os dados em uma única partição lógica ainda serão armazenados na mesma partição física. Uma divisão de partição física cria um novo mapeamento de partições lógicas para partições físicas.

A taxa de transferência provisionada para um contêiner é dividida uniformemente entre partições físicas. Um design de chave de partição que não distribui solicitações uniformemente pode resultar em muitas solicitações direcionadas a um pequeno subconjunto de partições que se tornam "quentes". Partições frequentes causam o uso ineficiente da taxa de transferência provisionada, o que pode resultar em limitação de taxa e custos mais altos.

Por exemplo, considere um contêiner com o caminho /foodGroup especificado como a chave de partição. O contêiner pode ter qualquer número de partições físicas, mas neste exemplo assumimos que ele tem três. Uma única partição física pode conter várias chaves de partição. Por exemplo, a maior partição física pode conter as três principais partições lógicas de tamanho mais significativo: Beef Products, Vegetable and Vegetable Products e Soups, Sauces, and Gravies.

Se você atribuir uma taxa de transferência de 18.000 unidades de solicitação por segundo (RU/s), cada uma das três partições físicas usará um terço da taxa de transferência total provisionada. Na partição física selecionada, as chaves de partição lógica Beef Products, Vegetable and Vegetable Products e Soups, Sauces, and Gravies podem, coletivamente, utilizar as 6.000 RU/s provisionadas da partição física. Como a taxa de transferência provisionada é dividida uniformemente entre as partições físicas do contêiner, é importante escolher uma chave de partição que distribua uniformemente o consumo da taxa de transferência. Para obter mais informações, consulte Escolhendo a chave de partição lógica correta.

Gerenciamento de partições lógicas

O Azure Cosmos DB gerencia automaticamente o posicionamento de partições lógicas em partições físicas para atender às necessidades de escalabilidade e desempenho do contêiner. Quando os requisitos de taxa de transferência e armazenamento de um aplicativo aumentam, o Azure Cosmos DB move partições lógicas para espalhar a carga entre mais partições físicas. Saiba mais sobre partições físicas.

O Azure Cosmos DB usa o particionamento baseado em hash para distribuir partições lógicas entre partições físicas. O Azure Cosmos DB corta o valor de chave de partição de um item. O resultado obtido por hash determina a partição física. Depois, o Azure Cosmos DB aloca o espaço de chave dos hashes de chave de partição uniformemente entre as partições físicas.

Transações em procedimentos armazenados ou gatilhos são permitidas somente para itens em uma única partição lógica.

Conjuntos de réplicas

Cada partição física consiste em um conjunto de réplicas, também chamado de 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 da partição física durável, altamente disponível e consistente. Cada réplica na partição física herda a cota de armazenamento da partição. Todas as réplicas de uma partição física dão suporte coletivamente à taxa de transferência alocada a essa partição física. O Azure Cosmos DB gerencia automaticamente os conjuntos de réplicas.

Contêineres menores geralmente exigem uma única partição física, mas ainda têm pelo menos quatro réplicas.

Esta imagem mostra como as partições lógicas são mapeadas para partições físicas distribuídas globalmente. O conjunto de partições da imagem refere-se a um grupo de partições físicas que gerenciam as mesmas chaves de partição lógicas em várias regiões:

Diagrama que mostra o particionamento do Azure Cosmos DB.

Escolher uma chave de partição

Uma chave de partição tem dois componentes: caminho da chave de partição e o valor da chave de partição. Por exemplo, considere os itens { "userId" : "Andrew", "worksFor": "Microsoft" }, se você escolher "userId" como a chave de partição, os dois componentes de chave de partição serão os seguintes:

  • O caminho da chave de partição (por exemplo: "/userId"). O caminho da chave de partição aceita caracteres alfanuméricos e sublinhados (_). Você também pode usar objetos aninhados usando a notação de caminho padrão (/).

  • O valor da chave de partição (por exemplo, "Andrew"). O valor da chave de partição pode ser de tipos de cadeia de caracteres ou numéricos.

Saiba mais sobre os limites de taxa de transferência, armazenamento e comprimento da chave de partição no artigo de cotas de serviço do Azure Cosmos DB .

A seleção da chave de partição é uma escolha de design simples e importante no Azure Cosmos DB. Depois de selecionar a chave de partição, você não poderá alterá-la no local. Se você precisar alterar a chave de partição, mova seus dados para um novo contêiner com a chave de partição desejada. (Os trabalhos de cópia do contêiner ajudam nesse processo.)

Para todos os contêineres, a chave de partição deve:

  • Ser uma propriedade com um valor que não é alterado. Se uma propriedade for a chave de partição, você não poderá atualizar o valor dessa propriedade.

  • Contêm apenas String valores ou convertem números em um String se eles podem exceder os limites de números de precisão dupla de acordo com o Instituto de Engenheiros Elétricos e Eletrônicos (IEEE) 754 binary64. A especificação Json explica por que usar números fora desse limite é uma má prática devido a problemas de interoperabilidade. Essas preocupações são especialmente relevantes para a coluna de chave de partição porque ela é imutável e requer que a migração de dados seja alterada posteriormente.

  • Tenha uma alta cardinalidade. Em outras palavras, a propriedade deve ter uma grande variedade de valores possíveis.

  • Distribua armazenamento de dados e consumo de RU (unidade de solicitação) uniformemente em todas as partições lógicas. Esse espalhamento garante o consumo de RU e a distribuição de armazenamento uniformes nas partições físicas.

  • Tem valores que normalmente não são maiores que 2048 bytes ou 101 bytes se chaves de partição grandes não estiverem habilitadas. Para obter mais informações, consulte chaves de partição grandes

Se você precisar de transações ACID com vários itens no Azure Cosmos DB, será necessário usar procedimentos armazenados ou gatilhos. Todos os procedimentos armazenados e gatilhos baseados em JavaScript têm como escopo uma única partição lógica.

Observação

Se você tiver apenas uma partição física, o valor da chave de partição poderá não ser relevante porque todas as consultas têm como destino a mesma partição física.

Tipos de chaves de partição

Estratégia de particionamento Quando usar Prós Contras
Chave de partição regular (por exemplo, CustomerId, OrderId) Use quando a chave de partição tiver alta cardinalidade e se alinhar com padrões de consulta (por exemplo, filtragem por CustomerId). Adequado para cargas de trabalho em que as consultas direcionam principalmente os dados de um único cliente (por exemplo, recuperando todos os pedidos de um cliente). Simples de gerenciar. Consultas eficientes quando o padrão de acesso corresponde à chave de partição (por exemplo, consultando todos os pedidos por CustomerId). Impede consultas entre partições se os padrões de acesso forem consistentes. Risco de partições ativas se alguns valores (por exemplo, alguns clientes de alto tráfego) gerarem mais dados do que outros. Pode atingir o limite de 20 GB por partição lógica se o volume de dados de uma chave específica aumentar rapidamente.
Chave de partição sintética (por exemplo, CustomerId + OrderDate) Use quando nenhum campo único tiver cardinalidade alta e corresponder aos padrões de consulta. Bom para cargas de trabalho pesadas de gravação em que os dados precisam ser distribuídos uniformemente entre partições físicas (por exemplo, muitos pedidos feitos na mesma data). Ajuda a distribuir dados uniformemente entre partições, reduzindo partições ativas (por exemplo, distribuindo pedidos por CustomerId e OrderDate). Espalha gravações em várias partições e melhora a taxa de transferência. Consultas que filtram apenas por um campo (por exemplo, somente CustomerId) podem resultar em consultas de partição cruzada. Consultas de partição cruzada podem levar a um maior consumo de RU (taxa extra de 2 a 3 RU/s para cada partição física existente) e latência adicional.
Chave de partição hierárquica (HPK) (por exemplo, CustomerId/OrderId, StoreId/ProductId) Use quando precisar de particionamento de vários níveis para dar suporte a conjuntos de dados em grande escala. Ideal quando as consultas filtram no primeiro e no segundo níveis da hierarquia. Ajuda a evitar o limite de 20 GB criando vários níveis de particionamento. Consulta eficiente em ambos os níveis hierárquicos (por exemplo, filtrando primeiro por CustomerID e, em seguida, por OrderID). Minimiza as consultas de partição cruzada para consultas direcionadas ao nível superior (por exemplo, recuperando todos os dados de uma CustomerID específica). Requer um planejamento cuidadoso para garantir que a chave de primeiro nível tenha alta cardinalidade e seja incluída na maioria das consultas. Mais complexo de gerenciar do que uma chave de partição regular. Se as consultas não se alinharem com a hierarquia (por exemplo, filtrando apenas por OrderID quando CustomerID for o primeiro nível), o desempenho da consulta poderá sofrer.

Chaves de partição para contêineres de leitura pesada

Para a maioria dos contêineres, esses critérios são tudo o que você precisa considerar ao escolher uma chave de partição. No entanto, para contêineres grandes de leitura pesada, é bom escolher uma chave de partição que aparece com frequência como um filtro nas suas consultas. Incluir a chave de partição no predicado de filtro permite que as consultas sejam roteada com eficiência apenas para as partições físicas relevantes.

Essa propriedade é uma boa opção de chave de partição se a maioria das solicitações da carga de trabalho forem consultas e a maioria das consultas usar um filtro de igualdade na mesma propriedade. Por exemplo, se você executar com frequência uma consulta que filtra em UserID, selecionar UserID como a chave de partição reduziria o número de consultas entre partições.

Se o contêiner for pequeno, você provavelmente não terá partições físicas suficientes para se preocupar com o desempenho de consultas de partição cruzada. A maioria dos contêineres pequenos no Azure Cosmos DB requer apenas uma ou duas partições físicas.

Se o contêiner puder aumentar para mais de algumas partições físicas, você deverá selecionar uma chave de partição que minimize as consultas entre partições. O contêiner precisará de mais do que algumas partições físicas se qualquer um dos seguintes cenários for verdadeiro:

  • Seu contêiner tem mais de 30.000 unidades de solicitação provisionadas

  • O contêiner armazena mais de 100 GB de dados

Usar a ID do item como a chave de partição

Observação

Esta seção se aplica principalmente à API para NoSQL. Outras APIs, como a API para Gremlin, não dão suporte ao identificador exclusivo como a chave de partição.

Se o contêiner tiver uma propriedade com uma ampla gama de valores possíveis, provavelmente será uma ótima opção de chave de partição. Um exemplo dessa propriedade é a ID do item. Nos contêineres pequenos de leitura pesada ou contêineres de gravação pesada de qualquer tamanho, a ID do item (/id) é naturalmente uma ótima opção para a chave de partição.

A ID do item de propriedade do sistema está presente em cada item em seu contêiner. Você pode ter outras propriedades que representam uma ID lógica do item. Em muitos casos, esses identificadores exclusivos também são ótimas opções de chave de partição pelos mesmos motivos que a ID do item.

A ID do item é uma ótima opção de chave de partição pelos seguintes motivos:

  • Há uma grande variedade de valores possíveis (uma única ID do item por item).
  • Como há uma só ID do item por item, a ID do item é ótimo para balancear uniformemente o consumo de RU e o armazenamento de dados.
  • Você pode facilmente fazer leituras de pontos eficientes, pois sempre saberá a chave de partição de um item se souber a ID do item.

Considere as seguintes limitações ao selecionar a ID do item como a chave de partição:

  • Se a ID do item for a chave de partição, ela se tornará um identificador exclusivo para todo o contêiner. Não é possível criar itens com identificadores duplicados.
  • Se tiver um contêiner de leitura pesada com muitas partições físicas, as consultas serão mais eficientes se tiverem um filtro de igualdade com a ID do item.
  • Procedimentos armazenados ou gatilhos não podem direcionar várias partições lógicas.

Conteúdo relacionado