Partilhar via

Criação de partições e dimensionamento horizontal no Azure Cosmos DB

  • Aplica-se a: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

O Azure Cosmos DB usa particionamento para dimensionar contêineres em um banco de dados para atender às necessidades de desempenho do seu aplicativo. Os itens em um contêiner são divididos em subconjuntos distintos chamados partições lógicas. As partições lógicas se formam 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 UserID propriedade. Se UserID servir como a chave de partição para os itens no contêiner e houver 1.000 valores exclusivos UserID , 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 um ID de item exclusivo dentro dessa partição. A combinação da chave de partição e do ID do item cria o índice do item, que identifica exclusivamente o item. Escolher uma chave de partição é uma decisão importante que afeta o desempenho do seu 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 recipiente que contém dados sobre nutrição alimentar, todos os itens contêm uma foodGroup propriedade. 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 Productse 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. As chaves de partição eficazes têm uma ampla gama de valores possíveis. Por exemplo, em um contêiner onde todos os itens contêm uma foodGroup propriedade, os dados dentro da Beef Products partição lógica podem crescer até 20 GB. Selecionar uma chave de partição com uma ampla gama de valores possíveis garante que o contêiner seja capaz de escalar.

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

Divisórias 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 destas 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é 10.000 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).

Nota

As partições físicas são uma implementação interna do sistema, totalmente gerenciada pelo Azure Cosmos DB. Ao desenvolver suas soluções, não se concentre em partições físicas porque você não pode controlá-las. Em vez disso, concentre-se nas chaves de partição. A escolha de 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 provisionada ou o tamanho dos dados aumenta, o Azure Cosmos DB cria automaticamente novas partições físicas dividindo as existentes. As divisões de partição física não afetam a disponibilidade do seu aplicativo. Após a divisão da partição física, todos os dados dentro de uma única partição lógica ainda serão armazenados na mesma partição física. Uma divisão de partição física simplesmente cria um novo mapeamento de partições lógicas para partições físicas.

A taxa de transferência provisionada para um contêiner se divide 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". As partições quentes causam 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 Productse 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. Dentro da partição física selecionada, as chaves Beef Productsde partição lógica , Vegetable and Vegetable Productse Soups, Sauces, and Gravies podem, coletivamente, utilizar os 6.000 RU/s provisionados 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 de taxa de transferência. Para obter mais informações, consulte Escolhendo a chave de partição lógica correta.

Gerenciando 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 distribuir a carga por mais partições físicas. Saiba mais sobre partições físicas.

O Azure Cosmos DB usa particionamento baseado em hash para distribuir partições lógicas entre partições físicas. O Azure Cosmos DB cria o hash do valor da chave de partição de um item. O resultado em hash determina a partição lógica. Em seguida, o Azure Cosmos DB aloca os hashes do espaço da chave de partição uniformemente nas partições físicas.

As transações em procedimentos armazenados ou gatilhos são permitidas apenas 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 suportam coletivamente a taxa de transferência alocada para essa partição física. O Azure Cosmos DB gerencia automaticamente 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. Partição definida na imagem refere-se a um grupo de partições físicas que gerenciam as mesmas chaves de partição lógica 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 um item { "userId" : "Andrew", "worksFor": "Microsoft" } se você escolher "userId" como a chave de partição, a seguir estão os dois componentes de chave de partição:

  • 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 do tipo string ou numérico.

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

Selecionar sua chave de partição é uma escolha de design simples, mas importante, no Azure Cosmos DB. Depois de selecionar sua chave de partição, você não pode alterá-la no lugar. Se você precisar alterar sua chave de partição, mova seus dados para um novo contêiner com a chave de partição desejada. Os trabalhos de cópia de contêiner ajudam nesse processo. Como alternativa, você pode adicionar índices secundários globais (visualização) para criar cópias de seus dados com diferentes chaves de partição otimizadas para padrões de consulta específicos.

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

  • Seja um imóvel que tenha um valor, que não muda. Se uma propriedade for sua chave de partição, você não poderá atualizar o valor dessa propriedade.

  • Conter apenas String valores — ou converter números em um String se eles podem exceder os limites de números de precisão dupla de acordo com o Institute of Electrical and Electronics Engineers (IEEE) 754 binário64. 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.

  • Ter uma cardinalidade elevada. Em outras palavras, o imóvel deve ter uma ampla gama de valores possíveis.

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

  • Ter valores que não sejam maiores do que 2048 bytes normalmente, 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 de vários itens no Azure Cosmos DB, precisará usar procedimentos armazenados ou gatilhos. Todos os procedimentos armazenados e gatilhos baseados em JavaScript têm como escopo uma única partição lógica.

Nota

Se você tiver apenas uma partição física, o valor da chave de partição pode não ser relevante porque todas as consultas visam a mesma partição física.

Tipos de chaves de partição

Estratégia de particionamento Quando utilizar Vantagens Desvantagens
Chave de partição regular (por exemplo, CustomerId, OrderId) Use quando a chave de partição tiver alta cardinalidade e estiver alinhada com padrões de consulta (por exemplo, filtragem por CustomerId). Adequado para cargas de trabalho em que as consultas visam principalmente os dados de um único cliente (por exemplo, recuperar todos os pedidos de um cliente). Simples de gerir. 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 quentes 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 para uma chave específica crescer rapidamente.
Chave de partição sintética (por exemplo, CustomerId + OrderDate) Use quando nenhum campo tiver cardinalidade alta e corresponder aos padrões de consulta. Bom para cargas de trabalho com muita gravação, onde 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 entre partições. As consultas entre partições podem levar a um maior consumo de RU (carga extra de 2-3 RU/s para cada partição física existente) e latência adicionada.
Chave de partição hierárquica (HPK) (por exemplo, CustomerId/OrderId, StoreId/ProductId) Use quando precisar de particionamento de vários níveis para suportar conjuntos de dados de grande escala. Ideal quando as consultas são filtradas no primeiro e 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 depois por OrderID). Minimiza consultas entre partições para consultas direcionadas ao nível superior (por exemplo, recuperar todos os dados de um CustomerID específico). Requer um planejamento cuidadoso para garantir que a chave de primeiro nível tenha alta cardinalidade e esteja incluída na maioria das consultas. Mais complexo de gerir do que uma chave de partição normal. Se as consultas não estiverem alinhadas com a hierarquia (por exemplo, filtrando apenas por OrderID quando CustomerID for o primeiro nível), o desempenho da consulta poderá ser prejudicado.
Global Secondary Index (GSI) - visualização (por exemplo, source usa CustomerId, GSI usa OrderId) Use quando não conseguir encontrar uma única chave de partição que funcione para todos os padrões de consulta. Ideal para cargas de trabalho que precisam consultar várias propriedades independentes de forma eficiente e têm um grande número de partições físicas. Elimina consultas entre partições ao usar a chave de partição GSI. Permite vários padrões de consulta nos mesmos dados com sincronização automática do contêiner de origem. Isolamento de desempenho entre cargas de trabalho. Cada GSI tem custos adicionais de armazenamento e RU. Os dados no GSI são eventualmente consistentes com o contêiner de origem.

Chaves de partição para contêineres com 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 com leitura pesada, convém escolher uma chave de partição que apareça com frequência como um filtro em suas consultas. A inclusão da chave de partição no predicado do filtro permite que as consultas sejam encaminhadas de forma eficiente 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 sua carga de trabalho forem consultas e a maioria das suas consultas usar um filtro de igualdade na mesma propriedade. Por exemplo, se você executar com freqüência uma consulta que filtra no 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 entre partições. A maioria dos contêineres pequenos no Azure Cosmos DB requer apenas uma ou duas partições físicas.

Se o contêiner puder crescer para mais do que algumas partições físicas, certifique-se de escolher uma chave de partição que minimize as consultas entre partições. Seu contêiner precisa de mais do que algumas partições físicas se um dos seguintes cenários for verdadeiro:

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

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

Índices secundários globais para consultas entre partições

Se seu aplicativo precisar consultar dados usando várias propriedades diferentes de forma eficiente, os índices secundários globais (visualização) fornecem uma alternativa ao uso de uma estratégia de chave de partição para o conjunto de dados. Os índices secundários globais são contêineres adicionais com diferentes chaves de partição, sincronizados automaticamente com os dados do contêiner de origem.

Considere os índices secundários globais quando:

  • Você tem vários padrões de consulta que não podem ser satisfeitos por uma única estratégia de chave de partição
  • Alterar a chave de partição existente seria perturbador
  • Você precisa isolar cargas de trabalho analíticas ou de pesquisa de operações transacionais

Os índices secundários globais ajudam a evitar consultas entre partições armazenando os mesmos dados com diferentes chaves de partição otimizadas para padrões de consulta específicos. Essa abordagem pode reduzir significativamente o consumo de RU e melhorar o desempenho da consulta em cenários onde a otimização da chave de partição por si só não é suficiente.

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

Nota

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

Se o seu contêiner tiver uma propriedade com uma ampla gama de valores possíveis, é provável que seja uma ótima opção de chave de partição. Um exemplo de tal propriedade é o ID do item. Para pequenos contêineres de leitura pesada ou contêineres pesados de gravação de qualquer tamanho, o ID do item (/id) é naturalmente uma ótima opção para a chave de partição.

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

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

  • Há uma ampla gama de valores possíveis (um ID de item exclusivo por item).
  • Como há um ID de item exclusivo por item, o ID do item faz um ótimo trabalho ao equilibrar uniformemente o consumo de RU e o armazenamento de dados.
  • Você pode facilmente fazer leituras pontuais eficientes, uma vez que você sempre sabe a chave de partição de um item se souber seu ID de item.

Considere as seguintes advertências ao selecionar o ID do item como a chave de partição:

  • Se o ID do item for a chave de partição, ele se tornará um identificador exclusivo para todo o contêiner. Não é possível criar itens com identificadores duplicados.
  • Se você 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.
  • Os procedimentos armazenados ou gatilhos não podem ter como alvo várias partições lógicas.

Conteúdos relacionados

  • Last updated on