Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
GILT FÜR: 
MongoDB-vCore
Für abfragefähige Felder sollten immer Indizes erstellt werden
Auf Prädikaten und Aggregaten basierende Lesevorgänge fragen den Index für die entsprechenden Filter ab. Wenn keine Indizes vorhanden sind, führt die Datenbank-Engine eine Dokumentenprüfung durch, um die passenden Dokumente zu finden. Scans sind immer teuer und werden immer teurer, je größer die Datenmenge in einer Sammlung ist. Für eine optimale Abfrageleistung sollten immer Indizes für alle abfragbaren Felder erstellt werden.
Vermeiden unnötiger Indizes und standardmäßiges Indizieren aller Felder
Indizes sollten nur für abfragbare Felder erstellt werden. Die Platzhalterindizierung sollte nur verwendet werden, wenn die Abfragemuster unvorhersehbar sind und jedes Feld in der Dokumentstruktur Teil der Abfragefilter sein kann.
Tipp
Azure Cosmos DB for MongoDB vCore indiziert standardmäßig nur das Feld _id. Alle anderen Felder werden standardmäßig nicht indiziert. Die zu indizierenden Felder sollten im Voraus geplant werden, um die Abfrageleistung zu maximieren und gleichzeitig die Auswirkungen auf die Schreibvorgänge durch die Indizierung zu vieler Felder zu minimieren.
Wenn ein neues Dokument zum ersten Mal eingefügt wird oder ein bestehendes Dokument aktualisiert oder gelöscht wird, wird jedes der angegebenen Felder im Index ebenfalls aktualisiert. Wenn die Indizierungsrichtlinie eine große Anzahl von Feldern (oder alle Felder des Dokuments) enthält, werden vom Server mehr Ressourcen für die Aktualisierung der entsprechenden Indizes verbraucht. Beim Skalieren sollten nur die abfragbaren Felder indiziert werden, während alle anderen Felder, die nicht in Abfrageprädikaten verwendet werden, vom Index ausgeschlossen bleiben sollten.
Indizierungsstrategie für eine effiziente Erfassung von Daten
Für große Workloadmigrationen in Azure Cosmos DB für MongoDB vCore empfiehlt es sich, Indizes nach dem Laden der Daten zur effizienten Ausführung zu erstellen. Dadurch wird der Schreibaufwand erheblich reduziert, der Ressourcenverbrauch minimiert und die Datenaufnahmeleistung beschleunigt. Die Aufrechterhaltung von Indizes während der Massenaufnahme kann Einfügungen verlangsamen, da jeder Schreibvorgang alle entsprechenden Indizes aktualisieren muss.
Für mehrere Indizes, die auf historischen Daten erstellt werden, geben Sie nicht blockierende createIndex-Befehle für jedes Feld aus
Es ist nicht immer möglich, alle Abfragemuster im Voraus zu planen, vor allem, wenn sich die Anforderungen der Anwendung ändern. Sich ändernde Anwendungsanforderungen erfordern zwangsläufig, dass dem Index auf einem Cluster mit einer großen Menge an historischen Daten Felder hinzugefügt werden.
In solchen Szenarien sollte jeder createIndex-Befehl asynchron erteilt werden, ohne auf eine Antwort des Servers zu warten.
Hinweis
Standardmäßig reagiert Azure Cosmos DB for MongoDB vCore erst dann auf einen createIndex-Vorgang, wenn der Index vollständig auf historischen Daten basiert. Je nach Größe des Clusters und der Menge der eingelesenen Daten kann dies einige Zeit in Anspruch nehmen und so aussehen, als würde der Server nicht auf den Befehl createIndex reagieren.
Wenn die createIndex-Befehle über die Mongo Shell ausgegeben werden, verwenden Sie Strg + C, um den Befehl zu unterbrechen, damit Sie nicht mehr auf eine Antwort warten müssen, sondern die nächsten Vorgänge ausführen können.
Hinweis
Wenn Sie Strg + C verwenden, um den Befehl createIndex zu unterbrechen, nachdem er ausgegeben wurde, wird der Vorgang der Indexerstellung auf dem Server nicht beendet. Die Shell muss nicht mehr auf eine Antwort vom Server warten, während der Server asynchron weiter den Index über die vorhandenen Dokumente aufbaut.
Erstellen zusammengesetzter Indizes für Abfragen mit Prädikaten für mehrere Felder
Zusammengesetzte Indizes sollten in den folgenden Szenarien verwendet werden:
- Abfragen mit Filtern für mehrere Felder
- Abfragen mit Filtern für mehrere Felder und mit einem oder mehreren Feldern, die in auf- oder absteigender Reihenfolge sortiert sind
Sehen Sie das das folgende Dokument in der Datenbank „cosmicworks“ und der Sammlung „employee“ an.
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Betrachten Sie die folgende Abfrage, um alle Mitarbeiter mit dem Nachnamen 'Smith' zu finden, die seit mehr als fünf Jahren im Unternehmen angestellt sind.
db.employee.find({"lastName": "Smith", "timeInOrgInYears": {"$gt": 5}})
Ein zusammengesetzter Index auf „lastName“ und „timeInOrgInYears“ optimiert diese Abfrage:
use cosmicworks;
db.employee.createIndex({"lastName" : 1, "timeInOrgInYears" : 1})
Nachverfolgen des Status eines createIndex-Vorgangs
Wenn Indizes hinzugefügt werden und historische Daten indiziert werden müssen, kann der Fortschritt des Vorgangs zur Indexerstellung mit db.currentOp() verfolgt werden.
Anhand dieses Beispiels können Sie den Fortschritt der Indizierung in der Datenbank „cosmicworks“ verfolgen.
use cosmicworks;
db.currentOp()
Wenn ein createIndex-Vorgang ausgeführt wird, sieht die Antwort wie folgt aus:
{
"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
}
Standardmäßige Aktivierung großer Indexschlüssel
Selbst wenn die Dokumente keine Schlüssel mit einer großen Anzahl von Zeichen enthalten oder die Dokumente nicht mehrere Verschachtelungsebenen aufweisen, wird durch die Angabe großer Indexschlüssel sichergestellt, dass diese Szenarien abgedeckt sind. Jetzt ist der große Indexschlüssel das Standardverhalten der Engine.
Betrachten Sie dieses Beispiel, um große Indexschlüssel für die Sammlung "large_index_coll" in der Datenbank "kosmische Werke" zu aktivieren.
use cosmicworks;
db.runCommand(
{
"createIndexes": "large_index_coll",
"indexes": [
{
"key": { "ikey": 1 },
"name": "ikey_1",
"enableLargeIndexKeys": true
}
]
})
Priorisierung von Indexerstellungen gegenüber neuen Schreibvorgängen mit der Blockierungsoption
Für Szenarien, in denen der Index erstellt werden soll, bevor Daten geladen werden, sollte die Blockierungsoption verwendet werden, um eingehende Schreibvorgänge zu blockieren, bis der Indexaufbau abgeschlossen ist.
Die Einstellung { "blocking": true } eignet sich für Migrationshilfsprogramme, bei denen Indizes für leere Sammlungen erstellt werden, bevor Datenschreibvorgänge beginnen.
Sehen Sie sich ein Beispiel für die Blockierungsoption für die Indexerstellung für die Sammlung „employee“ in der Datenbank „cosmicworks“ an:
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"name":1}, "name":"name_1"}],
blocking: true
})
Zugehöriger Inhalt
Sehen Sie sich die Informationen zur Textindizierung an. Sie ermöglicht effiziente Such- und Abfragevorgänge für textbasierte Daten.