Indexeringsbeleid in Azure Cosmos DB

VAN TOEPASSING OP: NoSQL

In Azure Cosmos DB heeft elke container een indexeringsbeleid dat bepaalt hoe de items van de container moeten worden geïndexeerd. Het standaard indexeringsbeleid voor nieuw gemaakte containers indexeert elke eigenschap van elk item en dwingt bereikindexen af voor elke tekenreeks of elk getal. Dit levert u goede queryprestaties op zonder dat u van tevoren aan indexering en indexbeheer hoeft te denken.

In sommige gevallen wilt u mogelijk dit automatische gedrag overschrijven, zodat het beter aansluit bij uw vereisten. U kunt het indexeringsbeleid van een container aanpassen door de indexeringsmodus in te stellen en eigenschappenpaden op te nemen of uit te sluiten.

Notitie

De methode voor het bijwerken van indexeringsbeleid dat in dit artikel wordt beschreven, is alleen van toepassing op de Azure Cosmos DB-API voor NoSQL. Meer informatie over indexeren in de Azure Cosmos DB-API voor MongoDB

Indexeringsmodus

Azure Cosmos DB ondersteunt twee indexeringsmodi:

• Consistent: de index wordt synchroon bijgewerkt wanneer u items maakt, bijwerkt of verwijdert. Dit betekent dat de consistentie van uw leesquery's de consistentie is die voor het account is geconfigureerd.
• Geen: Indexering is uitgeschakeld voor de container. Deze modus wordt vaak gebruikt wanneer een container wordt gebruikt als een puur sleutel-waardearchief zonder dat er secundaire indexen nodig zijn. Het kan ook worden gebruikt om de prestaties van bulkbewerkingen te verbeteren. Nadat de bulkbewerkingen zijn voltooid, kan de indexmodus worden ingesteld op Consistent en vervolgens worden bewaakt met de IndexTransformationProgress totdat deze is voltooid.

Notitie

Azure Cosmos DB ondersteunt ook een luie indexeringsmodus. Luie indexering voert updates op de index met een veel lager prioriteitsniveau uit als de engine geen andere taken uitvoert. Dit kan leiden tot inconsistente of onvolledige queryresultaten. Als u van plan bent een query uit te voeren op een Azure Cosmos DB-container, moet u geen luie indexering selecteren. Nieuwe containers kunnen geen luie indexering selecteren. U kunt een uitzondering aanvragen door contact op te cosmosdbindexing@microsoft.com leggen (behalve als u een Azure Cosmos DB-account gebruikt in de serverloze modus die geen ondersteuning biedt voor luie indexering).

Indexeringsbeleid is standaard ingesteld op automatic. Dit wordt bereikt door de automatic eigenschap in het indexeringsbeleid in te stellen op true. Als u deze eigenschap instelt om Azure Cosmos DB toe te true staan items automatisch te indexeren terwijl ze worden geschreven.

Indexgrootte

In Azure Cosmos DB is de totale verbruikte opslag de combinatie van zowel de gegevensgrootte als de indexgrootte. Hier volgen enkele functies van de indexgrootte:

• De indexgrootte is afhankelijk van het indexeringsbeleid. Als alle eigenschappen zijn geïndexeerd, kan de indexgrootte groter zijn dan de gegevensgrootte.
• Wanneer gegevens worden verwijderd, worden indexen op bijna continue basis gecomprimeerd. Voor kleine gegevensverwijderingen ziet u echter mogelijk niet onmiddellijk een afname van de indexgrootte.
• De indexgrootte kan tijdelijk toenemen wanneer fysieke partities worden gesplitst. De indexruimte wordt vrijgegeven nadat de partitiesplitsing is voltooid.

Eigenschapspaden opnemen en uitsluiten

Een aangepast indexeringsbeleid kan eigenschappenpaden opgeven die expliciet zijn opgenomen of uitgesloten van indexering. Door het aantal paden te optimaliseren dat is geïndexeerd, kunt u de latentie en RU-kosten van schrijfbewerkingen aanzienlijk verminderen. Deze paden worden gedefinieerd volgens de methode die wordt beschreven in de sectie overzicht van indexering met de volgende toevoegingen:

• een pad naar een scalaire waarde (tekenreeks of getal) eindigt met /?
• elementen uit een matrix worden samen geadresseerd via de /[] notatie (in plaats van /0, /1 enzovoort)
• het /* jokerteken kan worden gebruikt om alle elementen onder het knooppunt te vinden

Hetzelfde voorbeeld opnieuw gebruiken:

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

• employees het headquarterspad is/headquarters/employees/?

• het locationspad is country/locations/[]/country/?

• het pad naar iets onder headquarters is /headquarters/*

We kunnen bijvoorbeeld het /headquarters/employees/? pad opnemen. Dit pad zorgt ervoor dat de eigenschap werknemers wordt geïndexeerd, maar dat er geen extra geneste JSON in deze eigenschap wordt geïndexeerd.

Strategie opnemen/uitsluiten

Indexeringsbeleid moet het hoofdpad /* opnemen als een opgenomen of een uitgesloten pad.

• Neem het hoofdpad op om paden die niet hoeven te worden geïndexeerd selectief uit te sluiten. Deze methode wordt aanbevolen omdat Azure Cosmos DB proactief nieuwe eigenschappen kan indexeren die aan uw model kunnen worden toegevoegd.

• Sluit het hoofdpad uit om selectief paden op te nemen die moeten worden geïndexeerd. Het eigenschapspad van de partitiesleutel wordt niet standaard geïndexeerd met de uitsluitingsstrategie en moet indien nodig expliciet worden opgenomen.

• Voor paden met reguliere tekens die bestaan uit: alfanumerieke tekens en _ (onderstrepingsteken), hoeft u niet te ontsnappen aan de padtekenreeks rond dubbele aanhalingstekens (bijvoorbeeld '/path/?'). Voor paden met andere speciale tekens moet u de padtekenreeks rond dubbele aanhalingstekens (bijvoorbeeld '/'path-abc'/?' escapen). Als u speciale tekens in uw pad verwacht, kunt u elk pad voor veiligheid ontsnappen. Functioneel maakt het geen verschil als u elk pad of alleen de paden met speciale tekens escapet.

• De systeemeigenschap _etag wordt standaard uitgesloten van indexering, tenzij de etag wordt toegevoegd aan het opgenomen pad voor indexering.

• Als de indexeringsmodus is ingesteld op consistent, worden de systeemeigenschappen id en _ts automatisch geïndexeerd.

• Als er geen expliciet geïndexeerd pad in een item bestaat, wordt er een waarde toegevoegd aan de index om aan te geven dat het pad niet is gedefinieerd.

Alle expliciet opgenomen paden hebben waarden toegevoegd aan de index voor elk item in de container, zelfs als het pad niet is gedefinieerd voor een bepaald item.

Zie deze sectie voor voorbeelden van indexeringsbeleid voor het opnemen en uitsluiten van paden.

Prioriteit opnemen/uitsluiten

Als uw opgenomen paden en uitgesloten paden een conflict hebben, heeft het preciezere pad voorrang.

Hier volgt een voorbeeld:

Opgenomen pad: /food/ingredients/nutrition/*

Uitgesloten pad: /food/ingredients/*

In dit geval heeft het opgenomen pad voorrang op het uitgesloten pad, omdat het nauwkeuriger is. Op basis van deze paden worden alle gegevens in het food/ingredients pad of geneste binnen uitgesloten van de index. De uitzondering zou gegevens zijn binnen het opgenomen pad: /food/ingredients/nutrition/*, die zouden worden geïndexeerd.

Hier volgen enkele regels voor de prioriteit van opgenomen en uitgesloten paden in Azure Cosmos DB:

• Diepere paden zijn nauwkeuriger dan smalle paden. bijvoorbeeld: /a/b/? is nauwkeuriger dan /a/?.

• De /? is nauwkeuriger dan /*. Het is bijvoorbeeld /a/? nauwkeuriger dan /a/* dat het /a/? voorrang krijgt.

• Het pad /* moet een opgenomen pad of een uitgesloten pad zijn.

Vectorindexen

Notitie

U moet zich inschrijven voor de preview-functie van Azure Cosmos DB NoSQL Vector Index om een vectorindexeringsbeleid op te geven.>

Vectorindexen verhogen de efficiëntie bij het uitvoeren van vectorzoekopdrachten met behulp van de VectorDistance systeemfunctie. Zoekopdrachten in vectoren hebben aanzienlijk lagere latentie, hogere doorvoer en minder RU-verbruik bij het gebruik van een vectorindex. U kunt de volgende typen vectorindexbeleid opgeven:

Type	Description	Maximumdimensies
flat	Slaat vectoren op dezelfde index op als andere geïndexeerde eigenschappen.	505
quantizedFlat	Kwantificeert vectoren (comprimeert) voordat deze op de index worden opgeslagen. Dit kan de latentie en doorvoer verbeteren ten koste van een kleine hoeveelheid nauwkeurigheid.	4096
diskANN	Hiermee maakt u een index op basis van DiskANN voor snelle en efficiënte zoekopdrachten.	4096

Enkele punten om te noteren:

• De flat indextypen en quantizedFlat indextypen maken gebruik van de index van Azure Cosmos DB om elke vector op te slaan en te lezen bij het uitvoeren van een vectorzoekopdracht. Vectorzoekopdrachten met een flat index zijn brute-force zoekopdrachten en produceren 100% nauwkeurigheid of relevante overeenkomsten. Dat wil gezegd, het is gegarandeerd dat de meest vergelijkbare vectoren in de gegevensset worden gevonden. Er is echter een beperking van 505 dimensies voor vectoren op een platte index.

• In de quantizedFlat index worden gekwantiseerde (gecomprimeerde) vectoren opgeslagen op de index. Vectorzoekopdrachten met quantizedFlat indexen zijn ook brute-force zoekopdrachten, maar hun nauwkeurigheid kan iets minder zijn dan 100% omdat de vectoren worden gekwantiseerd voordat ze aan de index worden toegevoegd. Vectorzoekopdrachten met quantized flat moeten echter lagere latentie, hogere doorvoer en lagere RU-kosten hebben dan vectorzoekopdrachten in een flat index. Dit is een goede optie voor scenario's waarbij u queryfilters gebruikt om het zoeken naar vectoren te beperken tot een relatief kleine set vectoren, en zeer hoge nauwkeurigheid is vereist.

• De diskANN index is een afzonderlijke index die specifiek is gedefinieerd voor vectoren die gebruikmaken van DiskANN, een suite met high performance vector indexeringsalgoritmen die zijn ontwikkeld door Microsoft Research. DiskANN-indexen kunnen een aantal van de laagste latentie, de hoogste doorvoer en de laagste RU-kostenquery's bieden, terwijl ze nog steeds hoge nauwkeurigheid behouden. Omdat DiskANN echter een dichtstbijzijnde burenindex (ANN) is, kan de nauwkeurigheid lager zijn dan quantizedFlat of flat.

Hier volgt een voorbeeld van een indexeringsbeleid met een vectorindex:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

Belangrijk

Een vectorindexeringsbeleid moet zich bevinden op het pad dat is gedefinieerd in het vectorbeleid van de container. Meer informatie over containervectorbeleid. Vectorindexen moeten ook worden gedefinieerd op het moment van het maken van de container en kunnen niet worden gewijzigd nadat ze zijn gemaakt. In een toekomstige release kunnen vectorindexen worden gewijzigd.

Belangrijk

Het vectorpad is toegevoegd aan de sectie 'excludedPaths' van het indexeringsbeleid om te zorgen voor geoptimaliseerde prestaties voor invoeging. Als u het vectorpad niet toevoegt aan 'excludedPaths', leidt dit tot hogere RU-kosten en latentie voor vectorinvoegingen.

Ruimtelijke indexen

Wanneer u een ruimtelijk pad in het indexeringsbeleid definieert, moet u definiëren welke index type op dat pad moet worden toegepast. Mogelijke typen voor ruimtelijke indexen zijn:

• Contact

• Polygoon

• MultiPolygon

• LineString

Azure Cosmos DB maakt standaard geen ruimtelijke indexen. Als u ingebouwde SQL-functies voor ruimtelijke SQL wilt gebruiken, moet u een ruimtelijke index maken voor de vereiste eigenschappen. Zie deze sectie voor voorbeelden van indexeringsbeleid voor het toevoegen van ruimtelijke indexen.

Samengestelde indexen

Voor query's met een ORDER BY component met twee of meer eigenschappen is een samengestelde index vereist. U kunt ook een samengestelde index definiëren om de prestaties van veel gelijkheids- en bereikquery's te verbeteren. Standaard worden er geen samengestelde indexen gedefinieerd, zodat u indien nodig samengestelde indexen moet toevoegen.

In tegenstelling tot opgenomen of uitgesloten paden kunt u geen pad maken met het /* jokerteken. Elk samengesteld pad heeft een impliciete /? waarde aan het einde van het pad dat u niet hoeft op te geven. Samengestelde paden leiden tot een scalaire waarde die de enige waarde is die is opgenomen in de samengestelde index. Als een pad in een samengestelde index niet bestaat in een item of leidt tot een niet-scalaire waarde, wordt een waarde toegevoegd aan de index om aan te geven dat het pad niet is gedefinieerd.

Bij het definiëren van een samengestelde index geeft u het volgende op:

• Twee of meer eigenschapspaden. De volgorde waarin eigenschapspaden worden gedefinieerd, is van belang.

• De volgorde (oplopend of aflopend).

Notitie

Wanneer u een samengestelde index toevoegt, maakt de query gebruik van bestaande bereikindexen totdat de nieuwe samengestelde index is toegevoegd. Wanneer u daarom een samengestelde index toevoegt, ziet u mogelijk niet onmiddellijk prestatieverbeteringen. Het is mogelijk om de voortgang van indextransformatie bij te houden met behulp van een van de SDK's.

ORDER BY-query's op meerdere eigenschappen:

De volgende overwegingen worden gebruikt bij het gebruik van samengestelde indexen voor query's met een ORDER BY component met twee of meer eigenschappen:

• Als de samengestelde indexpaden niet overeenkomen met de volgorde van de eigenschappen in de ORDER BY component, kan de samengestelde index de query niet ondersteunen.

• De volgorde van samengestelde indexpaden (oplopend of aflopend) moet ook overeenkomen met de order in de ORDER BY component.

• De samengestelde index ondersteunt ook een ORDER BY component met de tegenovergestelde volgorde op alle paden.

Bekijk het volgende voorbeeld waarin een samengestelde index is gedefinieerd voor eigenschappennaam, leeftijd en _ts:

Samengestelde index	Voorbeeldquery ORDER BY	Ondersteund door samengestelde index?
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age asc	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.age ASC, c.name asc	No
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name DESC, c.age DESC	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age DESC	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC, timestamp ASC	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC	No

U moet uw indexeringsbeleid aanpassen zodat u alle benodigde ORDER BY query's kunt uitvoeren.

Query's met filters op meerdere eigenschappen

Als een query filters op twee of meer eigenschappen bevat, kan het handig zijn om een samengestelde index voor deze eigenschappen te maken.

Denk bijvoorbeeld aan de volgende query die zowel een gelijkheidsfilter als een bereikfilter heeft:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18

Deze query is efficiënter, kost minder tijd en verbruikt minder RU's als deze een samengestelde index (name ASC, age ASC)kan gebruiken.

Query's met meerdere bereikfilters kunnen ook worden geoptimaliseerd met een samengestelde index. Elke afzonderlijke samengestelde index kan echter slechts één bereikfilter optimaliseren. Bereikfilters zijn onder andere >, <, <=, >=en !=. Het bereikfilter moet als laatste in de samengestelde index worden gedefinieerd.

Bekijk de volgende query met een gelijkheidsfilter en twee bereikfilters:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18 AND c._ts > 1612212188

Deze query is efficiënter met een samengestelde index op (name ASC, age ASC) en (name ASC, _ts ASC). De query zou echter geen samengestelde index (age ASC, name ASC) gebruiken omdat de eigenschappen met gelijkheidsfilters eerst in de samengestelde index moeten worden gedefinieerd. Er zijn twee afzonderlijke samengestelde indexen vereist in plaats van één samengestelde index, (name ASC, age ASC, _ts ASC) omdat elke samengestelde index slechts één bereikfilter kan optimaliseren.

De volgende overwegingen worden gebruikt bij het maken van samengestelde indexen voor query's met filters op meerdere eigenschappen

• Filterexpressies kunnen meerdere samengestelde indexen gebruiken.
• De eigenschappen in het filter van de query moeten overeenkomen met de eigenschappen in de samengestelde index. Als een eigenschap zich in de samengestelde index bevindt, maar niet is opgenomen in de query als filter, maakt de query geen gebruik van de samengestelde index.
• Als een query andere eigenschappen heeft in het filter dat niet is gedefinieerd in een samengestelde index, wordt een combinatie van samengestelde en bereikindexen gebruikt om de query te evalueren. Hiervoor zijn minder RU's nodig dan alleen het gebruik van bereikindexen.
• Als een eigenschap een bereikfilter heeft (>, <, <=, >=of !=), moet deze eigenschap als laatste worden gedefinieerd in de samengestelde index. Als een query meer dan één bereikfilter heeft, kan deze profiteren van meerdere samengestelde indexen.
• Wanneer u een samengestelde index maakt om query's met meerdere filters te optimaliseren, heeft de ORDER samengestelde index geen invloed op de resultaten. Deze eigenschap is optioneel.

Bekijk de volgende voorbeelden waarbij een samengestelde index is gedefinieerd voor eigenschappennaam, leeftijd en tijdstempel:

Samengestelde index	Voorbeeldquery	Ondersteund door samengestelde index?
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT COUNT(1) FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name DESC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name != "John" AND c.age > 18	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 123049923	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp = 123049923	No
(name ASC, age ASC) and (name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp > 123049923	Yes

Query's met een filter en ORDER BY

Als een query filtert op een of meer eigenschappen en verschillende eigenschappen in de ORDER BY-component heeft, kan het handig zijn om de eigenschappen in het filter toe te voegen aan de ORDER BY component.

Door bijvoorbeeld de eigenschappen in het filter toe te voegen aan de ORDER BY component, kan de volgende query opnieuw worden geschreven om gebruik te maken van een samengestelde index:

Query uitvoeren met bereikindex:

SELECT *
FROM c 
WHERE c.name = "John" 
ORDER BY c.timestamp

Query uitvoeren met behulp van samengestelde index:

SELECT * 
FROM c 
WHERE c.name = "John"
ORDER BY c.name, c.timestamp

Dezelfde queryoptimalisaties kunnen worden gegeneraliseerd voor ORDER BY query's met filters, waarbij afzonderlijke samengestelde indexen maximaal één bereikfilter kunnen ondersteunen.

Query uitvoeren met bereikindex:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.timestamp

Query uitvoeren met behulp van samengestelde index:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.name, c.age, c.timestamp

Daarnaast kunt u samengestelde indexen gebruiken om query's te optimaliseren met systeemfuncties en ORDER BY:

Query uitvoeren met bereikindex:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.lastName

Query uitvoeren met behulp van samengestelde index:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.firstName, c.lastName

De volgende overwegingen zijn van toepassing bij het maken van samengestelde indexen om een query te optimaliseren met een filter en ORDER BY component:

• Als u geen samengestelde index definieert voor een query met een filter op één eigenschap en een afzonderlijke ORDER BY component met behulp van een andere eigenschap, slaagt de query nog steeds. De RU-kosten van de query kunnen echter worden verminderd met een samengestelde index, met name als de eigenschap in de ORDER BY component een hoge kardinaliteit heeft.
• Als de queryfilters op eigenschappen zijn, moeten deze eigenschappen eerst worden opgenomen in de ORDER BY component.
• Als de queryfilters op meerdere eigenschappen zijn, moeten de gelijkheidsfilters de eerste eigenschappen in de ORDER BY component zijn.
• Als de queryfilters op meerdere eigenschappen zijn toegepast, kunt u maximaal één bereikfilter of systeemfunctie gebruiken per samengestelde index. De eigenschap die wordt gebruikt in het bereikfilter of de systeemfunctie moet als laatste in de samengestelde index worden gedefinieerd.
• Alle overwegingen voor het maken van samengestelde indexen voor ORDER BY query's met meerdere eigenschappen en query's met filters op meerdere eigenschappen zijn nog steeds van toepassing.

Samengestelde index	Voorbeeldquery ORDER BY	Ondersteund door samengestelde index?
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.name ASC, c.timestamp ASC	Yes
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.timestamp > 1589840355 ORDER BY c.name ASC, c.timestamp ASC	Yes
(timestamp ASC, name ASC)	SELECT * FROM c WHERE c.timestamp > 1589840355 AND c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC	No
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.age ASC, c.name ASC,c.timestamp ASC	Yes
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.timestamp ASC	No

Query's met een filter en een aggregaties

Als een query filtert op een of meer eigenschappen en een statistische systeemfunctie heeft, kan het handig zijn om een samengestelde index te maken voor de eigenschappen in de filter- en statistische systeemfunctie. Deze optimalisatie is van toepassing op de systeemfuncties SUM en AVG .

De volgende overwegingen zijn van toepassing bij het maken van samengestelde indexen om een query te optimaliseren met een filter- en statistische systeemfunctie.

• Samengestelde indexen zijn optioneel bij het uitvoeren van query's met aggregaties. De RU-kosten van de query kunnen echter vaak aanzienlijk worden verminderd met een samengestelde index.
• Als de queryfilters op meerdere eigenschappen zijn, moeten de gelijkheidsfilters de eerste eigenschappen in de samengestelde index zijn.
• U kunt maximaal één bereikfilter per samengestelde index hebben en deze moet zich op de eigenschap in de statistische systeemfunctie bevinden.
• De eigenschap in de statistische systeemfunctie moet als laatste in de samengestelde index worden gedefinieerd.
• De order (ASC of DESC) maakt niet uit.

Samengestelde index	Voorbeeldquery	Ondersteund door samengestelde index?
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	Yes
(timestamp ASC, name ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	No
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name > "John"	No
(name ASC, age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age = 25	Yes
(age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age > 25	No

Het indexeringsbeleid wijzigen

Het indexeringsbeleid van een container kan op elk gewenst moment worden bijgewerkt met behulp van Azure Portal of een van de ondersteunde SDK's. Een update van het indexeringsbeleid activeert een transformatie van de oude index naar de nieuwe, die online en in-place wordt uitgevoerd (dus er wordt geen extra opslagruimte gebruikt tijdens de bewerking). Het oude indexeringsbeleid wordt efficiënt getransformeerd naar het nieuwe beleid zonder dat dit van invloed is op de beschikbaarheid van schrijfbewerkingen, lees-beschikbaarheid of de doorvoer die in de container is ingericht. Indextransformatie is een asynchrone bewerking en de tijd die nodig is om te voltooien, is afhankelijk van de ingerichte doorvoer, het aantal items en de grootte ervan. Als er meerdere indexeringsbeleidsupdates moeten worden aangebracht, is het raadzaam om alle wijzigingen als één bewerking uit te voeren om de indextransformatie zo snel mogelijk te laten voltooien.

Belangrijk

Indextransformatie is een bewerking die aanvraageenheden verbruikt.

Notitie

U kunt de voortgang van indextransformatie bijhouden in Azure Portal of met behulp van een van de SDK's.

Er is geen invloed op het schrijven van beschikbaarheid tijdens indextransformaties. De indextransformatie maakt gebruik van uw ingerichte RU's, maar heeft een lagere prioriteit dan uw CRUD-bewerkingen of -query's.

Het is niet van invloed op de beschikbaarheid van leesbewerkingen bij het toevoegen van nieuwe geïndexeerde paden. Query's maken alleen gebruik van nieuwe geïndexeerde paden zodra een indextransformatie is voltooid. Met andere woorden, wanneer u een nieuw geïndexeerd pad toevoegt, hebben query's die profiteren van dat geïndexeerde pad dezelfde prestaties vóór en tijdens de indextransformatie. Nadat de indextransformatie is voltooid, begint de query-engine de nieuwe geïndexeerde paden te gebruiken.

Wanneer u geïndexeerde paden verwijdert, moet u al uw wijzigingen groeperen in één indexeringsbeleidstransformatie. Als u meerdere indexen verwijdert en dit doet in één wijziging van het indexeringsbeleid, biedt de query-engine consistente en volledige resultaten tijdens de indextransformatie. Als u echter indexen verwijdert via meerdere wijzigingen in het indexeringsbeleid, levert de query-engine geen consistente of volledige resultaten totdat alle indextransformaties zijn voltooid. De meeste ontwikkelaars verwijderen geen indexen en proberen vervolgens onmiddellijk query's uit te voeren die gebruikmaken van deze indexen, dus in de praktijk is dit onwaarschijnlijk.

Wanneer u een geïndexeerd pad neergeeft, stopt de query-engine onmiddellijk met het gebruik ervan en voert u in plaats daarvan een volledige scan uit.

Notitie

Indien mogelijk moet u altijd meerdere indexverwijderingen groeperen in één wijziging van het indexeringsbeleid.

Belangrijk

Het verwijderen van een index wordt onmiddellijk van kracht, terwijl het toevoegen van een nieuwe index enige tijd in beslag neemt omdat er een indexeringstransformatie nodig is. Wanneer u de ene index vervangt door een andere index (bijvoorbeeld door één eigenschapsindex te vervangen door een samengestelde index), moet u eerst de nieuwe index toevoegen en vervolgens wachten tot de indextransformatie is voltooid voordat u de vorige index verwijdert uit het indexeringsbeleid. Anders heeft dit een negatieve invloed op de mogelijkheid om een query uit te voeren op de vorige index en kunnen actieve workloads die naar de vorige index verwijzen, worden verbroken.

Indexeringsbeleid en TTL

Voor het gebruik van de TTL-functie (Time-to-Live) is indexering vereist. Dit betekent het volgende:

• het is niet mogelijk om TTL te activeren voor een container waarop de indexeringsmodus is ingesteld noneop ,
• Het is niet mogelijk om de indexeringsmodus in te stellen op Geen in een container waarin TTL wordt geactiveerd.

Voor scenario's waarin geen eigenschapspad moet worden geïndexeerd, maar TTL is vereist, kunt u een indexeringsbeleid gebruiken met een indexeringsmodus ingesteld op consistent, geen opgenomen paden en /* als het enige uitgesloten pad.

Volgende stappen

Lees meer over indexeren in de volgende artikelen:

• Overzicht van indexering
• Indexeringsbeleid beheren