Aanbevolen procedures voor indexeren in Azure Cosmos DB voor MongoDB vCore
VAN TOEPASSING OP: 
MongoDB vCore
Queryerbare velden moeten altijd indexen hebben gemaakt
Leesbewerkingen op basis van predicaten en aggregaties raadplegen de index voor de bijbehorende filters. Als er geen indexen zijn, voert de database-engine een documentscan uit om de overeenkomende documenten op te halen. Scans zijn altijd duur en worden geleidelijk duurder naarmate het volume aan gegevens in een verzameling toeneemt. Voor optimale queryprestaties moeten indexen altijd worden gemaakt voor alle querybare velden.
Vermijd onnodige indexen en het standaard indexeren van alle velden
Indexen mogen alleen worden gemaakt voor opvraagbare velden. Het indexeren van jokertekens mag alleen worden gebruikt wanneer querypatronen onvoorspelbaar zijn wanneer een veld in de documentstructuur deel kan uitmaken van queryfilters.
Tip
In Azure Cosmos DB voor MongoDB vCore wordt standaard alleen het _id veld geïndexeerd. Alle andere velden worden niet standaard geïndexeerd. De velden die moeten worden geïndexeerd, moeten van tevoren worden gepland om de queryprestaties te maximaliseren, terwijl de gevolgen voor schrijfbewerkingen van te veel velden worden geminimaliseerd.
Wanneer een nieuw document voor het eerst wordt ingevoegd of een bestaand document wordt bijgewerkt of verwijderd, wordt elk van de opgegeven velden in de index ook bijgewerkt. Als het indexeringsbeleid een groot aantal velden (of alle velden in het document) bevat, worden er meer resources door de server gebruikt bij het bijwerken van de bijbehorende indexen. Wanneer u op schaal uitvoert, moeten alleen de querybare velden worden geïndexeerd, terwijl alle resterende velden die niet worden gebruikt in querypredicaten, uitgesloten blijven van de index.
De benodigde indexen maken vóór gegevensopname
Voor optimale prestaties moeten indexen vooraf worden gemaakt voordat gegevens worden geladen. Alle documentschrijfbewerkingen, updates en verwijderingen werken de bijbehorende indexen synchroon bij. Als er indexen worden gemaakt nadat gegevens zijn opgenomen, worden er meer serverresources gebruikt om historische gegevens te indexeren. Afhankelijk van de grootte van de historische gegevens is deze bewerking tijdrovend en heeft dit invloed op de stabiele lees- en schrijfprestaties.
Notitie
Voor scenario's waarin wijziging van leespatronen en indexen moeten worden toegevoegd, moet achtergrondindexering worden ingeschakeld, wat kan worden gedaan via een ondersteuningsticket.
Voor meerdere indexen die zijn gemaakt op historische gegevens, geeft u niet-blokkering van createIndex-opdrachten voor elk veld uit
Het is niet altijd mogelijk om vooraf alle querypatronen te plannen, met name naarmate de toepassingsvereisten zich ontwikkelen. Als u de toepassing wijzigt, moeten velden onvermijdelijk worden toegevoegd aan de index op een cluster met een grote hoeveelheid historische gegevens.
In dergelijke scenario's moet elke createIndex-opdracht asynchroon worden uitgegeven zonder te wachten op een reactie van de server.
Notitie
Standaard reageert Azure Cosmos DB voor MongoDB vCore alleen op een createIndex-bewerking nadat de index volledig is gebouwd op historische gegevens. Afhankelijk van de grootte van het cluster en het opgenomen volume van gegevens, kan dit even duren en worden weergegeven alsof de server niet reageert op de opdracht createIndex.
Als de createIndex-opdrachten worden uitgegeven via de Mongo Shell, gebruikt u Ctrl + C om de opdracht te onderbreken om te stoppen met wachten op een antwoord en de volgende set bewerkingen uit te voeren.
Notitie
Als u Ctrl+C gebruikt om de opdracht createIndex te onderbreken nadat deze is uitgegeven, wordt de indexbuildbewerking op de server niet beëindigd. Het stopt de Shell om te wachten op een reactie van de server, terwijl de server asynchroon de index blijft bouwen via de bestaande documenten.
Samengestelde indexen maken voor query's met predicaten op meerdere velden
Samengestelde indexen moeten worden gebruikt in de volgende scenario's:
- Query's met filters op meerdere velden
- Query's met filters op meerdere velden en met een of meer velden gesorteerd in oplopende of aflopende volgorde
Bekijk het volgende document in de database 'kosmische werken' en 'werknemer'-verzameling
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Bekijk de volgende query om alle werknemers met de achternaam 'Smith' voor meer dan 5 jaar bij de organisatie te vinden:
db.employee.find({"lastName": "Smith", "timeInOrgInYears": {"$gt": 5}})
Met een samengestelde index voor zowel 'lastName' als 'timeInOrgInYears' wordt deze query geoptimaliseerd:
use cosmicworks;
db.employee.createIndex({"lastName" : 1, "timeInOrgInYears" : 1})
De status van een createIndex-bewerking bijhouden
Wanneer indexen worden toegevoegd en historische gegevens moeten worden geïndexeerd, kan de voortgang van de indexbuildbewerking worden bijgehouden met db.currentOp().
Bekijk dit voorbeeld om de voortgang van de indexering in de database 'kosmische werken' bij te houden.
use cosmicworks;
db.currentOp()
Wanneer een createIndex-bewerking wordt uitgevoerd, ziet het antwoord er als volgt uit:
{
"inprog": [
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451493:1719209762286363",
"op_prefix": 30000451493,
"currentOpTime": "2024-06-24T06:16:02.000Z",
"secs_running": 0,
"command": { "aggregate": "" },
"op": "command",
"waitingForLock": false
},
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451876:1719209638351743",
"op_prefix": 30000451876,
"currentOpTime": "2024-06-24T06:13:58.000Z",
"secs_running": 124,
"command": { "createIndexes": "" },
"op": "workerCommand",
"waitingForLock": false,
"progress": {},
"msg": ""
}
],
"ok": 1
}
Standaard grote indexsleutels inschakelen
Zelfs als de documenten geen sleutels bevatten met een groot aantal tekens of als de documenten geen meerdere geneste niveaus bevatten, zorgt het opgeven van grote indexsleutels ervoor dat deze scenario's worden behandeld.
Overweeg deze sampe om grote indexsleutels in te schakelen voor de verzameling 'large_index_coll' in de database 'kosmische werken'.
use cosmicworks;
db.runCommand(
{
"createIndexes": "large_index_coll",
"indexes": [
{
"key": { "ikey": 1 },
"name": "ikey_1",
"enableLargeIndexKeys": true
}
]
})
Index builds prioriteren via nieuwe schrijfbewerkingen met behulp van de blokkeringsoptie
Voor scenario's waarin de index moet worden gemaakt voordat gegevens worden geladen, moet de blokkeringsoptie worden gebruikt om binnenkomende schrijfbewerkingen te blokkeren totdat de indexbuild is voltooid.
Instelling { "blocking": true } is met name handig in migratiehulpprogramma's waarbij indexen worden gemaakt voor lege verzamelingen voordat gegevens worden weggeschreven.
Bekijk een voorbeeld van de blokkeringsoptie voor het maken van indexen voor de verzameling 'werknemer' in de database 'kosmische werken':
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"name":1}, "name":"name_1"}],
blocking: true
})
Gerelateerde inhoud
Bekijk tekstindexering, waarmee u efficiënt kunt zoeken en query's kunt uitvoeren op gegevens op basis van tekst.