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 situaties wilt u dit automatische gedrag mogelijk overschrijven om beter aan uw vereisten te voldoen. 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
hetheadquarters
pad is/headquarters/employees/?
het
locations
pad iscountry
/locations/[]/country/?
het pad naar iets onder
headquarters
is/headquarters/*
We kunnen bijvoorbeeld het /headquarters/employees/?
pad opnemen. Dit pad zorgt ervoor dat de employees
eigenschap wordt geïndexeerd, maar dat er geen extra geneste JSON binnen 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 benadering 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 bevatten waarden die zijn 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. Vectorenzoekopdrachten hebben een lagere latentie, hogere doorvoer en minder RU-verbruik bij het toepassen 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 enquantizedFlat
indextypen passen de index van Azure Cosmos DB toe om elke vector op te slaan en te lezen bij het uitvoeren van een vectorzoekopdracht. Vectorzoekopdrachten met eenflat
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 van505
dimensies voor vectoren op een platte index.De
quantizedFlat
index slaat gekwantiseerde (gecomprimeerde) vectoren op de index op. Vectorzoekopdrachten metquantizedFlat
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 metquantized flat
moeten echter lagere latentie, hogere doorvoer en lagere RU-kosten hebben dan vectorzoekopdrachten in eenflat
index. Dit is een goede optie voor scenario's waarbij u queryfilters gebruikt om de vectorzoekopdracht te beperken tot een relatief kleine set vectoren en hoge nauwkeurigheid is vereist.De
diskANN
index is een afzonderlijke index die specifiek is gedefinieerd voor vectoren die DiskANN toepassen, 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 danquantizedFlat
offlat
.
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-calaire waarde, wordt er een waarde aan de index toegevoegd 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 deORDER 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 heeft, 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, neemt minder tijd en verbruikt minder RU's, als deze een samengestelde index kan toepassen op (name ASC, age ASC)
.
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 vereist dan uitsluitend 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 dit 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 een samengestelde index toe te passen:
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 deORDER 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 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
ofDESC
) 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, bij het toevoegen van een nieuw geïndexeerd pad 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
none
op , - 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.