Fråga en Azure Cosmos DB-container

  • Artikel

GÄLLER FÖR: NoSQL

Den här artikeln beskriver hur du kör frågor mot en container (samling, graf eller tabell) i Azure Cosmos DB. I synnerhet beskrivs hur partitions- och partitionsfrågor fungerar i Azure Cosmos DB.

Frågekörning inom en partition

När du frågar efter data från containrar, om frågan har ett angivet partitionsnyckelfilter, optimerar Azure Cosmos DB automatiskt frågan. Den dirigerar frågan till de fysiska partitioner som motsvarar de partitionsnyckelvärden som anges i filtret.

Tänk till exempel på frågan nedan med ett likhetsfilter på DeviceId. Om vi kör den här frågan på en container som partitionerats på DeviceIdfiltreras den här frågan till en enda fysisk partition.

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

Precis som i det tidigare exemplet filtrerar den här frågan även till en enda partition. Om du lägger till filtret på Location ändras inte följande fråga:

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

Här är en fråga som har ett intervallfilter på partitionsnyckeln och som inte begränsas till en enda fysisk partition. För att vara en partitionsfråga måste frågan ha ett likhetsfilter som innehåller partitionsnyckeln:

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

Frågekörning mellan partitioner

Följande fråga har inget filter på partitionsnyckeln (DeviceId). Därför måste den skickas till alla fysiska partitioner där den körs mot varje partitions index:

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

Varje fysisk partition har ett eget index. När du kör en fråga mellan partitioner på en container kör du därför en fråga per fysisk partition. Azure Cosmos DB aggregerar automatiskt resultat över olika fysiska partitioner.

Indexen i olika fysiska partitioner är oberoende av varandra. Det finns inget globalt index i Azure Cosmos DB.

Parallell frågekörning mellan partitioner

Azure Cosmos DB SDK:erna 1.9.0 och senare stöder alternativ för parallell frågekörning. Parallell frågekörning mellan partitioner gör att du kan genomföra frågor med låg latens mellan partitioner.

Du kan hantera parallell frågekörning genom att justera följande parametrar:

  • MaxConcurrency: Anger det maximala antalet samtidiga nätverksanslutningar till containerns partitioner. Om du anger den här egenskapen till -1hanterar SDK graden av parallellitet. Om är inställt på MaxConcurrency0finns det en enda nätverksanslutning till containerns partitioner.

  • MaxBufferedItemCount: Avväger frågesvarstid kontra minnesanvändning på klientsidan. Om det här alternativet utelämnas eller anges till -1 hanterar SDK:n antalet objekt som buffras under en parallell frågekörning.

På grund av Azure Cosmos DB:s möjlighet att parallellisera frågor mellan partitioner skalas frågesvarstiden vanligtvis och systemet lägger till fysiska partitioner. RU-avgiften ökar dock avsevärt i takt med att det totala antalet fysiska partitioner ökar.

När du kör en fråga mellan partitioner gör du i princip en separat fråga per enskild fysisk partition. Även om frågor mellan partitioner använder indexet är de, om de är tillgängliga, fortfarande inte lika effektiva som frågor i partitionen.

Användbart exempel

Här är en analogi för att bättre förklara frågor mellan partitioner:

Anta att du är en leveransdrivrutin som måste leverera paket till olika lägenhetskomplex. Varje lägenhetskomplex har en lista på de lokaler som har alla boendes enhetsnummer. Vi kan jämföra varje lägenhetskomplex med en fysisk partition och varje lista med den fysiska partitionens index.

Vi kan jämföra frågor mellan partitioner och partitioner med det här exemplet:

Fråga i partition (exempel)

Om leveransdrivrutinen känner till rätt lägenhetskomplex (fysisk partition) kan de omedelbart köra till rätt byggnad. Föraren kan kontrollera lägenhetskomplexets lista över de boendes enhetsnummer (indexet) och snabbt leverera lämpliga paket. I det här fallet slösar föraren inte någon tid eller ansträngning på att köra till ett lägenhetskomplex för att kontrollera och se om några paketmottagare bor där.

Fråga mellan partitioner (uttjäntas)

Om leveransföraren inte känner till rätt lägenhetskomplex (fysisk partition) måste de köra till varje enskild lägenhetsbyggnad och kontrollera listan med alla boendes enhetsnummer (indexet). När föraren anländer till varje lägenhetskomplex kan de fortfarande använda listan över adresserna för varje boende. De måste dock kontrollera varje lägenhetskomplexs lista, oavsett om några paketmottagare bor där eller inte. Det här exemplet är hur frågor mellan partitioner fungerar. Även om de kan använda indexet (vilket innebär att de inte behöver knacka på varje dörr), måste de separat kontrollera indexet för varje fysisk partition.

Fråga mellan partitioner (begränsad till endast några få fysiska partitioner)

Om leveransföraren vet att alla paketmottagare bor i ett visst fåtal lägenhetskomplex behöver de inte köra till var och en. När du kör till några lägenhetskomplex kräver fortfarande mer arbete än att besöka bara en enda byggnad, sparar leveransföraren fortfarande betydande tid och ansträngning. Om en fråga har partitionsnyckeln i filtret med nyckelordet IN kontrollerar den bara den relevanta fysiska partitionens index efter data.

Undvik frågor mellan partitioner

För de flesta containrar är det oundvikligt att ha vissa frågor mellan partitioner, vilket är okej! Nästan alla frågeåtgärder stöds mellan partitioner, både för logiska partitionsnycklar och fysiska partitioner. Azure Cosmos DB har också många optimeringar i frågemotorn och klient-SDK:er för att parallellisera frågekörning över fysiska partitioner.

För de flesta läsintensiva scenarier rekommenderar vi att du väljer den vanligaste egenskapen i dina frågefilter. Du bör också se till att partitionsnyckeln följer andra metodtips för val av partitionsnyckel.

Att undvika frågor mellan partitioner är vanligtvis bara viktigt med stora containrar. Du debiteras minst cirka 2,5 RU:er varje gång du kontrollerar en fysisk partitions index för resultat även om inga objekt i den fysiska partitionen matchar frågans filter. Om du bara har en (eller bara några) fysiska partitioner förbrukar frågor mellan partitioner därför inte betydligt fler RU:er än frågor i partitionen.

Antalet fysiska partitioner är kopplat till mängden etablerade RU:er. Varje fysisk partition tillåter upp till 10 000 etablerade RU:er och kan lagra upp till 50 GB data. Azure Cosmos DB hanterar automatiskt fysiska partitioner åt dig. Antalet fysiska partitioner i containern är beroende av ditt etablerade dataflöde och förbrukade lagringsutrymme.

Du bör försöka undvika frågor mellan partitioner om din arbetsbelastning uppfyller följande kriterier:

  • Du planerar att ha över 30 000 RU:er etablerade
  • Du planerar att lagra över 100 GB data

Nästa steg

I följande artiklar lär du dig mer om partitionering i Azure Cosmos DB: