Consultar um contentor do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

Este artigo explica como consultar um contentor (coleção, gráfico ou tabela) no Azure Cosmos DB. Em particular, aborda a forma como as consultas entre partições e partições funcionam no Azure Cosmos DB.

Consulta na partição

Quando consulta dados de contentores, se a consulta tiver um filtro de chave de partição especificado, o Azure Cosmos DB otimiza automaticamente a consulta. Encaminha a consulta para as partições físicas correspondentes aos valores da chave de partição especificados no filtro.

Por exemplo, considere a consulta abaixo com um filtro de igualdade em DeviceId. Se executarmos esta consulta num contentor particionado no DeviceId, esta consulta filtra para uma única partição física.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Tal como acontece com o exemplo anterior, esta consulta também filtra para uma única partição. Adicionar o filtro não Location altera a seguinte consulta:

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'

Eis uma consulta que tem um filtro de intervalo na chave de partição e não será confinada a uma única partição física. Para ser uma consulta na partição, a consulta tem de ter um filtro de igualdade que inclua a chave de partição:

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Consulta entre partições

A seguinte consulta não tem um filtro na chave de partição (DeviceId). Por conseguinte, tem de se destacar em todas as partições físicas em que é executada em relação ao índice de cada partição:

SELECT * FROM c WHERE c.Location = 'Seattle`

Cada partição física tem o seu próprio índice. Por conseguinte, quando executa uma consulta entre partições num contentor, está efetivamente a executar uma consulta por partição física. O Azure Cosmos DB agrega automaticamente resultados em diferentes partições físicas.

Os índices em diferentes partições físicas são independentes uns dos outros. Não existe nenhum índice global no Azure Cosmos DB.

Consulta entre partições paralelas

Os SDKs do Azure Cosmos DB 1.9.0 e posteriores suportam opções de execução de consultas paralelas. As consultas entre partições paralelas permitem-lhe realizar consultas entre partições de baixa latência.

Pode gerir a execução paralela da consulta ao otimizar os parâmetros abaixo:

  • MaxConcurrency: define o número máximo de ligações de rede simultâneas para as partições do contentor. Se definir esta propriedade como -1, o SDK gere o grau de paralelismo. Se estiver MaxConcurrency definido como 0, existe uma única ligação de rede às partições do contentor.

  • MaxBufferedItemCount: negoceia a latência da consulta em relação à utilização da memória do lado do cliente. Se esta opção for omitida ou definida como -1, o SDK gere o número de itens em memória intermédia durante a execução paralela da consulta.

Devido à capacidade do Azure Cosmos DB para paralelizar consultas entre partições, a latência de consulta geralmente dimensiona, bem como o sistema adiciona partições físicas. No entanto, o custo de RU aumenta significativamente à medida que o número total de partições físicas aumenta.

Quando executa uma consulta entre partições, está essencialmente a fazer uma consulta separada por partição física individual. Embora as consultas entre partições utilizem o índice, se disponíveis, ainda não são tão eficientes como as consultas na partição.

Exemplo útil

Segue-se uma analogia para explicar melhor as consultas entre partições:

Imagine que é um motorista de entregas que tem de entregar pacotes para diferentes complexos de apartamentos. Cada complexo de apartamentos tem uma lista no local que tem todos os números de unidade dos residentes. Podemos comparar cada complexo de apartamentos com uma partição física e cada lista com o índice da partição física.

Podemos comparar consultas entre partições e partições com este exemplo:

Consulta na partição (exemplo)

Se o controlador de entrega souber o complexo de apartamentos correto (partição física), pode imediatamente dirigir até ao edifício correto. O controlador pode verificar a lista do complexo de apartamentos dos números de unidade dos residentes (o índice) e entregar rapidamente os pacotes adequados. Neste caso, o condutor não perde tempo ou esforço ao dirigir-se para um complexo de apartamentos para verificar se algum destinatário do pacote vive lá.

Consulta entre partições (fan-out)

Se o controlador de entrega não souber o complexo de apartamentos correto (partição física), terá de dirigir até todos os edifícios de apartamentos e verificar a lista com todos os números de unidade dos residentes (o índice). Assim que o motorista chegar a cada complexo de apartamentos, eles ainda podem usar a lista dos endereços de cada residente. No entanto, precisam de verificar a lista de todos os complexos de apartamentos, quer os destinatários do pacote vivam lá ou não. Este exemplo é como funcionam as consultas entre partições. Embora possam utilizar o índice (ou seja, não precisam de bater em todas as portas), têm de verificar separadamente o índice para cada partição física.

Consulta entre partições (no âmbito de apenas algumas partições físicas)

Se o condutor da entrega souber que todos os destinatários do pacote vivem dentro de alguns complexos de apartamentos, não precisam de conduzir até cada um deles. Enquanto conduz para alguns complexos de apartamentos ainda requer mais trabalho do que visitar apenas um único edifício, o motorista de entrega ainda poupa tempo e esforço significativos. Se uma consulta tiver a chave de partição no respetivo filtro com a IN palavra-chave, verifica apenas os índices da partição física relevante para obter dados.

Evitar consultas entre partições

Para a maioria dos contentores, ter algumas consultas entre partições é inevitável, o que não há problema! Quase todas as operações de consulta são suportadas em partições, tanto para chaves de partição lógicas como para partições físicas. O Azure Cosmos DB também tem muitas otimizações no motor de consulta e nos SDKs de cliente para paralelizar a execução de consultas em partições físicas.

Para a maioria dos cenários de leitura intensiva, recomendamos que selecione a propriedade mais comum nos filtros de consulta. Também deve certificar-se de que a chave de partição cumpre as melhores práticas de seleção de outras chaves de partição.

Normalmente, evitar consultas entre partições só importa com contentores grandes. É-lhe cobrado um mínimo de cerca de 2,5 RU de cada vez que verifica o índice de uma partição física para obter resultados, mesmo que nenhum itens na partição física corresponda ao filtro da consulta. Como tal, se tiver apenas uma (ou apenas algumas) partições físicas, as consultas entre partições não consomem significativamente mais RU do que consultas na partição.

O número de partições físicas está associado à quantidade de RU aprovisionadas. Cada partição física permite até 10 000 RU aprovisionadas e pode armazenar até 50 GB de dados. O Azure Cosmos DB gere automaticamente partições físicas automaticamente. O número de partições físicas no contentor depende do débito aprovisionado e do armazenamento consumido.

Deve tentar evitar consultas entre partições se a carga de trabalho cumprir os seguintes critérios:

  • Planeia ter mais de 30 000 RU aprovisionadas
  • Planeia armazenar mais de 100 GB de dados

Passos seguintes

Veja os seguintes artigos para saber mais sobre a criação de partições no Azure Cosmos DB: