Dela via

Fråga en Azure Cosmos DB-container

GÄLLER FÖR: NoSQL

Den här artikeln beskriver hur du frågar efter data (till exempel en samling, graf eller tabell) i en container 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 dig till exempel följande fråga 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 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 standard globalt index i Azure Cosmos DB.

Optimera frågor mellan partitioner med globala sekundära index

Globala sekundära index (förhandsversion) ger en alternativ metod för att undvika frågor mellan partitioner utan att ändra containerns partitionsnyckel. Ett globalt sekundärt index skapar en separat, automatiskt synkroniserad container med en annan partitionsnyckel optimerad för specifika frågemönster.

Om containern till exempel partitioneras av DeviceId men du ofta frågar efter Locationkan du skapa ett globalt sekundärt index partitionerat av Location. Frågan som tidigare var en fråga mellan partitioner kan nu köras som en partitionsfråga mot det globala sekundära indexet:

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

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. MaxConcurrency Om värdet är 0 finns det en enda nätverksanslutning till containerns partitioner.

  • MaxBufferedItemCount: Avväger frågefördröjning gentemot minnesanvändning på klientsidan. Om det här alternativet utelämnas eller anges till -1 hanterar SDK antalet objekt som buffras under 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. Avgiften för enheter för begäran ö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 leveransförare 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 för 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 antalet 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 tilldelade RU:er
  • Du planerar att lagra över 100 GB data

Överväg att använda globala sekundära index (förhandsversion) för att undvika frågor mellan partitioner. Med globala sekundära index kan du skapa ytterligare containrar med olika partitionsnycklar, som automatiskt synkroniseras med källcontainern. Den här metoden kan eliminera frågor mellan partitioner för specifika frågemönster utan att kräva ändringar i din befintliga programlogik eller partitionsnyckel.

Nästa steg