Azure Cosmos DB för NoSQL globala sekundära index (förhandsversion)

Viktigt!

Azure Cosmos DB för NoSQL globala sekundära index är för närvarande i förhandsversion. Mer information finns i kompletterande användningsvillkor för förhandsversioner av Microsoft Azure.

Globala sekundära index (GSI:er) förbättrar frågeeffektiviteten genom att lagra data med en annan partitionsnyckel än källcontainern. GSI:er är skrivskyddade containrar som synkroniseras automatiskt med källcontainern. Varje GSI har sin egen partitionsnyckel, indexeringsprincip, dataflödesgräns (RU) och datamodell.

Användningsfall

Program behöver ofta köra frågor mot data med andra egenskaper än partitionsnyckeln. Dessa frågor måste köras över alla partitioner, även om vissa partitioner inte innehåller data som matchar filtervillkoren. Därför förbrukar frågor som inte innehåller partitionsnyckeln fler RU:er och har högre svarstid.

Med ett globalt sekundärt index kan du:

• Lagra data med en annan partitionsnyckel för att konvertera frågor mellan partitioner i källcontainern till enskilda partitionsfrågor.
• Lägg till GSI:er i befintliga containrar för att hålla frågorna effektiva när programmet behöver ändras.
• Isolera en delmängd av din arbetsbelastning, till exempel att skapa vektor- eller fulltextsökningsindex i GSI utan att påverka transaktionsåtgärder i källcontainern.

Fördelar med globalt sekundärt index

Azure Cosmos DB globala sekundära index har följande fördelar:

• Automatisk synkronisering: Indexcontainrar synkroniseras automatiskt med källcontainern, vilket eliminerar behovet av anpassad logik i klientprogram.
• Slutlig konsekvens: Indexcontainrar är så småningom konsekventa med källcontainern utan att påverka skrivfördröjningen i källan.
• Prestandaisolering: Indexcontainrar har egna lagrings- och RU-gränser, vilket ger prestandaisolering.
• Optimerad läsprestanda: Finjusterad datamodell, partitionsnyckel och indexeringsprincip för optimerad läsprestanda med stöd för frågor med hjälp av den omfattande NoSQL frågesyntaxen.
• Förbättrad skrivprestanda: Klienter behöver bara skriva till källcontainern, vilket förbättrar skrivprestanda jämfört med en strategi för skrivning med flera containrar.
• Read-Only Containers: Skrivningar till indexcontainern är asynkrona och hanteras automatiskt. Klientprogram behöver inte skriva direkt till indexcontainern.
• Flera index: Du kan skapa flera indexcontainrar för samma källcontainer.

Att definiera globala sekundära index

Att skapa ett globalt sekundärt index liknar att skapa en ny container, med tillagda egenskaper för att ange källcontainern och en fråga som definierar GSI-datamodellen. Många anpassningar för containrar gäller även för GSI:er, inklusive anpassade indexerings-, vektor- och fulltextsökningsprinciper. GSI-containrar måste använda autoskalerad genomströmning, vilket hjälper dem att svara på trafiktoppar utan att bli begränsade eller komma efter med uppdateringar i källcontainern.

Frågan som definierar en GSI måste följa följande begränsningar. När GSI:n har skapats kan du fråga den med hjälp av den fullständiga Azure Cosmos DB för NoSQL frågesyntax.

• SELECT-instruktionen kan projicera egenskaper från valfri nivå i JSON-trädet eller använda SELECT * för att inkludera alla egenskaper. Beräknade egenskaper plattas ut till den översta nivån i GSI.
• Egenskapsalias (AS) stöds inte i definitionsfrågan.
• Frågor kan inte innehålla en WHERE-sats eller andra satser som JOIN, DISTINCT, GROUP BY, ORDER BY, TOP, OFFSET LIMIT eller EXISTS.
• Systemfunktioner och användardefinierade funktioner (UDF) stöds inte.

Varje objekt i GSI har en en-till-en-mappning till ett objekt i källcontainern. För att upprätthålla den här mappningen fylls fältet i GSI-objekt automatiskt och källobjektvärdet representeras som . När du använder inkluderas källan automatiskt som i GSI-objekt. När du projicerar specifika egenskaper måste du uttryckligen inkludera om det behövs.

En giltig fråga är till exempel: . I GSI visas , och som egenskaper på den översta nivån, även om var kapslad i källan. Den här frågan definierar datamodellen för GSI och avgör vilka egenskaper som ingår för varje objekt. Källcontainern och definitionsfrågan kan inte ändras när den har skapats.

Lär dig hur du skapar globala sekundära index.

Tips/Råd

Om en projicerad egenskap inte finns i alla källobjekt använder GSI null-värden för saknade egenskaper. Om du väljer en partitionsnyckel som inte finns i alla objekt kan du nå storleksgränsen på 20 GB logisk partition. Konfigurera aviseringar för att övervaka om lagringen för en logisk partitionsnyckel närmar sig 20 GB.

Synkronisera globala sekundära index

Globala sekundära index hålls automatiskt synkroniserade med ändringar av data i källcontainrar med hjälp av ändringsflöde. När en GSI definieras för en källcontainer skapas och hanteras ett ändringsflödesjobb åt dig. Ändringar återspeglas asynkront i data i indexcontainrar och påverkar inte skrivningar till källcontainern. Indexcontainrar är så småningom konsekventa med källcontainern oavsett vilken konsekvensnivå som angetts för kontot.

Ändringsflödesläsningar förbrukar RU:er från källcontainern och skrivningar till GSI förbrukar RU:er från GSI-containern. RU:n som tilldelas till båda containrarna avgör hur snabbt data hydratiseras och synkroniseras.

Globala sekundära index i multiregionkonton

För Azure Cosmos DB konton med en enda region sker ändringsflödesläsningar från källcontainern och skrivningar till GSI i den regionen. I ett konto i flera regioner med en enda skrivregion sker ändringsflödesläsningar och GSI-skrivningar i skrivregionen. I ett konto med flera skrivregioner sker ändringsflödesläsningar och GSI-skrivningar i någon av skrivregionerna. Om det finns en redundansväxling för ditt konto sker ändringsflödesläsningar och GSI-skrivningar i den nya skrivregionen.

Utföra förfrågningar mot globala sekundära index

Att köra frågor mot globala sekundära index liknar att köra frågor mot andra containrar. Du kan använda den fullständiga, omfattande Azure Cosmos DB för NoSQL frågesyntax för att utföra frågor på GSI:er, inklusive vektor, fulltextsökning och hybridsökningsfrågor. Precis som andra containrar bör du justera indexeringsprincipen på GSI:er baserat på dina frågemönster.

Eftersom globala sekundära index kan ha en annan partitionsnyckel än källan, kan förfrågningar som spänner över flera partitioner på källan bli förfrågningar som endast involverar en partition på det globala sekundära indexet. Enskilda partitionsfrågor förbättrar svarstiden och minskar RU-förbrukningen.

Bästa praxis

Välj partitionsnyckeln

• GSI-partitionsnycklar följer samma designprinciper som alla containrar. Lär dig metodtips för att välja en partitionsnyckel.
• Undvik ojämn distribution som orsakas av null-värden genom att välja en partitionsnyckel som finns i alla eller nästan alla källobjekt.
• Använd hierarkiska partitionsnycklar med den sista nivån som en egenskap med hög kardinalitet som . GSI:er är unikt placerade för hierarkiska partitionsnycklar som slutar med eftersom systemet automatiskt underhåller skrivningar och generering. Detta optimerar partitionsnycklar som kan leda till att logiska partitioner närmar sig lagringsgränsen på 20 GB utan att offra några skriv- eller läsmönster.

Utforma projektioner baserat på frågor

• Endast projektegenskaper som du behöver för dina dataåtkomstmönster. Undvik att projicera egenskaper som sällan används för att minimera lagrings- och RU-förbrukningen.
• Testa GSI-definitionsfrågan noggrant innan du skapar den. Det går inte att ändra definitionen när den har skapats.
• Använd endast om du behöver alla egenskaper. Selektiva prognoser är mer effektiva.

Optimera för prestanda

• Justera indexeringsprincipen på GSI:er baserat på dina frågemönster, precis som för alla containrar.
• Kom ihåg att RU:er används separat: läsningar kommer från källcontainern under bearbetningen av ändringsflöde och skrivningar är till GSI under synkroniseringen. Etablera genomströmning på båda containrarna på lämpligt sätt.
• Använd autoskalningsdataflöde på GSI:er för att hantera synkroniseringstoppar utan begränsning.

Övervakning

Övervaka GSI:s hälsa och prestanda med hjälp av måttet Global Secondary Index Propagation Latency in Seconds i avsnittet Metrics i Azure-portalen. Det här måttet spårar fördröjningen mellan käll- och GSI:er under den inledande versionen och pågående synkronisering. Mer information finns i mått som stöds för Microsoft.DocumentDB/DatabaseAccounts.

Felsökning av vanliga problem

Jag vill förstå fördröjningen mellan min källcontainer och GSI:er

Måttet för spridningssvarstid visar den genomsnittliga skillnaden i sekunder mellan käll- och GSI-data. Om du vill visa fördröjning för en enskild GSI väljer du Tillämpa delning och sedan GlobalSecondaryIndexName i värdelistan.

Jag vill veta när min GSI är redo att fråga

Det finns två statustyper för att skilja mellan spridningssvarstid när du skapar GSI för första gången och svarstid för aktiva GSI:er. Använd måttet global sekundär indexspridningssvarstid i sekunder och välj Tillämpa delning. Välj värdet GlobalSecondaryIndexStatus för att visa svarstid för globala sekundära index i statusen Aktiv eller InitialBuildAfterCreate . Du kan använda det här måttet och statusen för att konfigurera aviseringar om svarstiden överskrider ett visst tröskelvärde.

Jag vill veta om min GSI har tillräckligt med dataflöde

RUs som provisionerats på källan och den globala sekundära indexen (GSI) påverkar ändringshastigheten. Kontrollera måttet Normaliserad RU-förbrukning , om den är för hög kan containern ha nytta av att öka maximalt antal RU:er.

Nästa steg

Datamodellering och partitioneringLär dig hur du konfigurerar globala sekundära index