Fråga en Azure Cosmos DB-container
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 frågor mellan partitioner och partitioner 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å DeviceId
filtreras 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 i praktiken 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
-1
hanterar SDK graden av parallellitet. Om är inställt påMaxConcurrency
0
finns 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 när 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, om det är tillgängligt, är de fortfarande inte alls 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 hjälp av 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 leveransdrivrutinen 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 leveransdrivrutinen vet att alla paketmottagare bor i några få 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 mellan 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 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: