Compartilhar via


Consultar um contêiner do Azure Cosmos DB

Este artigo explica como consultar dados (como uma coleção, grafo ou tabela) em um contêiner no Azure Cosmos DB. Em particular, ele aborda como as consultas em partição e entre partições funcionam em Azure Cosmos DB.

Consulta na partição

Quando você consulta dados de contêineres, se a consulta tiver um filtro de chave de partição especificado, o Azure Cosmos DB otimiza automaticamente a consulta. Ele encaminha a consulta para as partições físicas correspondentes aos valores de chave de partição especificados no filtro.

Por exemplo, considere a consulta a seguir com um filtro de igualdade em DeviceId. Se executarmos essa consulta em um contêiner particionado em DeviceId, essa consulta será filtrada para uma única partição física.

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

Assim como no exemplo anterior, essa consulta também filtra para uma única partição. Adicionar o filtro em Location não altera a consulta a seguir:

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

Aqui está uma consulta que tem um filtro de intervalo na chave de partição e não será delimitada para uma única partição física. Para ser uma consulta na partição, a consulta deve 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 consulta a seguir não tem um filtro na chave de partição (DeviceId). Portanto, ele deve se espalhar para todas as partições físicas em que é executado no índice de cada partição:

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

Cada partição física tem seu próprio índice. Portanto, ao executar uma consulta entre partições em um contêiner, você está efetivamente executando uma consulta por partição física. O Azure Cosmos DB agrega automaticamente os resultados em diferentes partições físicas.

Os índices em diferentes partições físicas são independentes um do outro. Não há nenhum índice global padrão no Azure Cosmos DB.

Otimizar consultas entre partições com índices secundários globais

Índices secundários globais (versão prévia) fornecem uma abordagem alternativa para evitar consultas entre partições sem alterar a chave de partição do contêiner. Um índice secundário global cria um contêiner separado e sincronizado automaticamente com uma chave de partição diferente otimizada para padrões de consulta específicos.

Por exemplo, se o seu contêiner estiver particionado por DeviceId, mas você pesquisar com frequência por Location, poderá criar um índice secundário global particionado por Location. A consulta que anteriormente era uma consulta de partição cruzada agora pode ser executada como uma consulta em partição em relação ao índice secundário global:

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

Consulta entre partições em paralelo

Os SDKs do Azure Cosmos DB 1.9.0 e versões superiores dão suporte a opções de execução de consultas paralelas. Consultas entre partições em paralelo permitem que você execute consultas entre partições de baixa latência.

Você pode gerenciar a execução de consulta paralela ajustando os seguintes parâmetros:

  • MaxConcurrency: define o número máximo de conexões de rede simultâneas para as partições do contêiner. Se você definir essa propriedade como -1, o SDK gerenciará o grau de paralelismo. Se o MaxConcurrency valor for definido como 0, haverá uma única conexão de rede com as partições do contêiner.

  • MaxBufferedItemCount: negocia a latência de consulta versus a utilização de memória no cliente. Se essa opção for omitida ou definida como -1, o SDK gerenciará o número de itens armazenados em buffer durante a execução de consulta paralela.

Devido à capacidade do Azure Cosmos DB de paralelizar consultas entre partições, a latência da consulta geralmente é bem dimensionada, pois o sistema adiciona partições físicas. No entanto, à medida que o número total de partições físicas aumenta, a cobrança de Unidades de Solicitação (RUs) aumenta significativamente.

Quando você executa uma consulta entre partições, basicamente está fazendo uma consulta separada por partição física individual. Embora as consultas entre partições utilizem o índice, se disponível, elas ainda não são tão eficientes quanto as consultas em partição.

Exemplo útil

Aqui está uma analogia para explicar melhor as consultas entre partições:

Imagine que você é um motorista de entrega que tem que entregar pacotes para diferentes complexos de apartamentos. Cada complexo de apartamentos tem uma lista nas instalações que contém todos os números das unidades dos moradores. Podemos comparar cada apartamento em condomínio com uma partição física e cada lista com o índice da partição física.

Podemos comparar consultas em partição e entre partições usando este exemplo:

Consulta na partição (exemplo)

Se o motorista de entrega souber o condomínio correto (partição física), ele pode dirigir imediatamente para o prédio correto. O motorista pode verificar a lista do complexo de apartamentos com os números das unidades dos moradores (o índice) e entregar rapidamente os pacotes apropriados. Nesse caso, o motorista não perde tempo ou esforço dirigindo até um complexo de apartamentos para verificar se algum destinatário do pacote mora lá.

Consulta entre partições (fan-out)

Se o entregador não souber o complexo de apartamentos correto (partição física), ele precisará dirigir até cada prédio de apartamentos e verificar a lista com todos os números das unidades dos moradores (o índice). Uma vez que o motorista chega a cada complexo de apartamentos, eles ainda podem usar a lista dos endereços de cada morador. No entanto, eles precisam verificar a lista de cada complexo de apartamentos, se algum destinatário do pacote mora lá ou não. Esse exemplo mostra como funcionam as consultas entre partições. Embora possam usar o índice (ou seja, não precisam bater em todas as portas), eles devem verificar separadamente o índice de cada partição física.

Consulta entre partições (com escopo para apenas algumas partições físicas)

Se o entregador souber que todos os destinatários do pacote moram em alguns poucos complexos de apartamentos, não precisará dirigir até cada um deles. Embora dirigir para alguns complexos de apartamentos ainda exija mais trabalho do que visitar apenas um único prédio, o entregador ainda economiza tempo e esforço significativos. Se uma consulta tiver a chave de partição no seu filtro com a palavra-chave IN, ela verificará apenas os índices da partição física relevante em busca de dados.

Evite as consultas entre partições

Para a maioria dos contêineres, ter algumas consultas entre partições é inevitável, o que não faz mal! Quase todas as operações de consulta são suportadas em todas as partições, tanto para chaves de partição lógica quanto para partições físicas. O Azure Cosmos DB também tem muitas otimizações no mecanismo de consulta e nos SDKs do cliente para paralelizar a execução da consulta em partições físicas.

Para a maioria dos cenários de leitura intensa, recomendamos selecionar a propriedade mais comum nos seus filtros de consulta. Você também deve verificar se a chave de partição está em conformidade com outras práticas recomendadas de seleção de chave de partição.

Evitar consultas entre partições normalmente só é importante para grandes contêineres. Você é cobrado por um mínimo de cerca de 2,5 RUs cada vez que verifica o índice de uma partição física para resultados, mesmo que nenhum item na partição física corresponda ao filtro da consulta. Dessa forma, se você tiver apenas uma (ou apenas algumas) partições físicas, as consultas de partição cruzada não consumirão significativamente mais RUs do que as consultas em partição.

O número de partições físicas está vinculado ao número de RUs provisionadas. Cada partição física permite até 10.000 RUs provisionadas e pode armazenar até 50 GB de dados. O Azure Cosmos DB gerencia automaticamente as partições físicas para você. O número de partições físicas no contêiner depende da taxa de transferência provisionada e do armazenamento consumido.

Você deve tentar evitar consultas entre partições se sua carga de trabalho atender aos critérios a seguir:

  • Você planeja ter mais de 30.000 RUs provisionadas
  • Você planeja armazenar mais de 100 GB de dados

Considere usar índices secundários globais (versão prévia) para evitar consultas entre partições. Os índices secundários globais permitem que você crie contêineres adicionais com chaves de partição diferentes, sincronizadas automaticamente com o contêiner de origem. Essa abordagem pode eliminar consultas de partição cruzada para padrões de consulta específicos sem exigir alterações na lógica do aplicativo ou na chave de partição existente.

Próximas etapas