Delen via


Best practices voor indexeren in Azure DocumentDB

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.

Aanbeveling

In Azure DocumentDB 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. Bij grootschalige uitvoering moeten alleen de doorzoekbare velden worden geïndexeerd, terwijl alle resterende velden die niet worden gebruikt in querypredicaten, uitgesloten moeten blijven van de index.

Indexeringsstrategie voor efficiënte gegevensopname

Voor grote workloadmigraties naar Azure DocumentDB is het raadzaam om indexen te maken na de gegevensbelasting voor een efficiënte uitvoering. Dit vermindert de schrijfoverhead aanzienlijk, minimaliseert het resourceverbruik en versnelt de prestaties van gegevensopname. Het onderhouden van indexen tijdens bulkopname kan invoegingen vertragen, omdat elke schrijfbewerking alle toepasselijke indexen moet bijwerken.

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.

Opmerking

Standaard reageert Azure DocumentDB 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.

Opmerking

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 zorgt ervoor dat de Shell niet meer wacht op een reactie van de server, terwijl de server asynchroon doorgaat met het bouwen van de index op 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 'cosmicworks'-database en de 'employee'-collectie.

{
    "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 vijf 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 veel tekens of als de documenten geen meerdere niveau's van genestheid bevatten, zorgt het opgeven van grote indexsleutels ervoor dat deze scenario's worden afgedekt. De grote indexsleutel is nu het standaardgedrag van de engine.

Bekijk dit voorbeeld 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
    }
    ]
})

De voorkeur geven aan indexopbouw boven nieuwe schrijfbewerkingen met behulp van de blokkeeroptie

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 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
})

Bekijk tekstindexering, waarmee u efficiënt kunt zoeken en query's kunt uitvoeren op gegevens op basis van tekst.

Volgende stap