Freigeben über

Übersicht über die Indizierung in Azure Cosmos DB

  • Gilt für:: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB ist eine schemaunabhängige Datenbank, mit der Sie ihre Anwendung durchlaufen können, ohne sich mit der Schema- oder Indexverwaltung befassen zu müssen. Standardmäßig indexiert Azure Cosmos DB automatisch jede einzelne Eigenschaft aller Elemente in Ihrem container, ohne ein Schema definieren oder sekundäre Indizes konfigurieren zu müssen.

In diesem Artikel wird erläutert, wie Azure Cosmos DB Daten indiziert und wie Indizes verwendet werden, um die Abfrageleistung zu verbessern. Sie sollten zunächst diesen Abschnitt lesen, bevor Sie sich mit dem Anpassen von Indizierungsrichtlinien beschäftigen.

Von Elementen zu Strukturen

Bei jedem Speichern eines Elements in einem Container wird dessen Inhalt als ein JSON-Dokument projiziert und anschließend in eine strukturierte Darstellung konvertiert. Diese Konvertierung bedeutet, dass jede Eigenschaft dieses Elements als Knoten in einer Struktur dargestellt wird. Als übergeordnetes Element für alle Eigenschaften auf oberster Ebene des Elements wird ein Pseudostammknoten erstellt. Die Blattknoten enthalten die eigentlichen Skalarwerte eines Elements.

Betrachten Sie z. B. dieses Element:

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

Diese Struktur stellt das JSON-Beispielelement dar:

Diagramm des vorherigen JSON-Elements, das als Baum dargestellt wird.

Beachten Sie, wie Arrays in der Struktur codiert werden: Jeder Eintrag in einem Array erhält direkt einen Zwischenknoten, der mit dem Index dieses Eintrags innerhalb des Arrays bezeichnet ist (0, 1 usw.).

n Strukturen zu Eigenschaftenpfaden

Azure Cosmos DB wandelt Elemente in Bäume um, da es dem System ermöglicht, mithilfe ihrer Pfade innerhalb dieser Strukturen auf Eigenschaften zu verweisen. Um den Pfad für eine Eigenschaft abzurufen, können Sie die Struktur vom Stammknoten aus bis zu dieser Eigenschaft durchlaufen. Verketten Sie dabei die Bezeichnungen aller durchlaufenen Knoten.

Dies sind die Pfade für jede Eigenschaft aus dem zuvor beschriebenen Beispielelement:

  • : „Deutschland“
  • : „Berlin“
  • : „Frankreich“
  • : „Paris“
  • : „Belgien“
  • : 250
  • : „Moskau“
  • : „Athen“

Azure Cosmos DB indiziert effektiv den Pfad jeder Eigenschaft und den entsprechenden Wert, wenn ein Element geschrieben wird.

Indextypen

Azure Cosmos DB unterstützt derzeit drei Arten von Indizes. Sie können diese Indextypen beim Definieren der Indizierungsrichtlinie konfigurieren.

Bereichsindex

Die Bereichsindizes basieren auf einer geordneten baumähnlichen Struktur. Dieser Indextyp wird für Folgendes verwendet:

  • Gleichheitsabfragen:

    SELECT * FROM container c WHERE c.property = 'value'

    SELECT * FROM c WHERE c.property IN ("value1", "value2", "value3")

  • Gleichheitsübereinstimmung für ein Arrayelement

    SELECT * FROM c WHERE ARRAY_CONTAINS(c.tags, "tag1")

  • Bereichsabfragen:

    SELECT * FROM container c WHERE c.property > 'value'

    Hinweis

    Funktioniert für , , , ,

  • Überprüfen, ob eine Eigenschaft vorhanden ist:

    SELECT * FROM c WHERE IS_DEFINED(c.property)

  • Zeichenfolgensystemfunktionen:

    SELECT * FROM c WHERE CONTAINS(c.property, "value")

    SELECT * FROM c WHERE STRINGEQUALS(c.property, "value")

  • fragt Folgendes ab:

    SELECT * FROM container c ORDER BY c.property

  • fragt Folgendes ab:

    SELECT child FROM container c JOIN child IN c.properties WHERE child = 'value'

Range-Indizes können für Skalarwerte (Zeichenfolge oder Zahl) verwendet werden. Die standardmäßige Indizierungsrichtlinie für neu erstellte Container erzwingt Bereichsindizes für jede Zeichenfolge oder Zahl. Informationen zum Konfigurieren von Bereichsindizes finden Sie unter Manage indexing policies in Azure Cosmos DB.

Hinweis

Eine Klausel, die von einer einzelnen Eigenschaft sortiert wird, benötigt immer einen Bereichsindex und schlägt fehl, wenn der pfad, auf den verwiesen wird, keinen hat. Ebenso benötigt eine Abfrage, die nach mehreren Eigenschaften sortiert wird, immer einen zusammengesetzten Index.

Räumlicher Index

Räumliche Indizes ermöglichen effiziente Abfragen von Geospatialobjekten wie Punkten, Linien, Polygonen und Multipolygons. Diese Abfragen verwenden , , Schlüsselwörter. Im Folgenden finden Sie einige Beispiele für die Verwendung des räumlichen Indextyps:

  • Abfragen zum räumlichen Abstand:

    SELECT * FROM container c WHERE ST_DISTANCE(c.property, { "type": "Point", "coordinates": [0.0, 10.0] }) < 40

  • Räumliche Abfragen:

    SELECT * FROM container c WHERE ST_WITHIN(c.property, {"type": "Point", "coordinates": [0.0, 10.0] })

  • Abfragen zur räumlichen Überschneidung:

    SELECT * FROM c WHERE ST_INTERSECTS(c.property, { 'type':'Polygon', 'coordinates': [[ [31.8, -5], [32, -5], [31.8, -5] ]]  })

Spatial-Indizes können für ordnungsgemäß formatierte GeoJSON-Objekte verwendet werden. Derzeit werden Point, LineString, Polygon und MultiPolygon unterstützt. Informationen zum Konfigurieren von räumlichen Indizes finden Sie unter Manage indexing policies in Azure Cosmos DB.

Wichtig

Azure Cosmos DB räumliche Indizierung entspricht nicht dem 2dsphere Indexverhalten von MongoDB, auch wenn die Azure Cosmos DB für die MongoDB-API verwendet wird.

Cosmos DB unterstützt Geospatialabfragen zwar über seinen nativen räumlichen Index und seine Funktionen wie , und implementiert nicht das Geospatialabfragemodul oder das Ausführungsmodell von MongoDB. Dies führt zu folgendem Ergebnis:

  • Das Erstellen eines Indexes in der MongoDB-API garantiert nicht dieselben Leistungsmerkmale wie MongoDB.
  • Abfrageausführungspläne und Optimierungsstrategien unterscheiden sich zwischen Cosmos DB und MongoDB.
  • Anwendungen, die von MongoDB migriert werden, können ein anderes Leistungsverhalten für Geospatialabfragen beobachten, auch wenn Indizes erfolgreich erstellt werden.

Überprüfen Sie für optimale Leistung, ob Ihre Daten als gültige GeoJSON gespeichert sind, und verwenden Sie die räumlichen Funktionen von Cosmos DB, die für den nativen räumlichen Index optimiert sind.

Zusammengesetzte Indizes

Zusammengesetzte Indizes erhöhen die Effizienz, wenn Sie Vorgänge für mehrere Felder durchführen. Dieser Indextyp wird für Folgendes verwendet:

  • fragt mehrere Eigenschaften ab:

    SELECT * FROM container c ORDER BY c.property1, c.property2

  • Abfragen mit einem Filter und . Diese Abfragen können einen zusammengesetzten Index verwenden, wenn die Filter-Eigenschaft der -Klausel hinzugefügt wird.

    SELECT * FROM container c WHERE c.property1 = 'value' ORDER BY c.property1, c.property2

  • Abfragen mit einem Filter auf zwei oder mehr Eigenschaften, bei denen mindestens eine Eigenschaft ein Gleichheitsfilter ist:

    SELECT * FROM container c WHERE c.property1 = 'value' AND c.property2 > 'value'

Solange ein Filter-Prädikat einen der Indextypen verwendet, wertet das Abfragemodul diese zuerst aus, bevor der Rest überprüft wird. Ein Beispiel wäre, wenn Sie eine SQL-Abfrage wie haben.

  • Diese Abfrage filtert zuerst nach Einträgen, bei denen firstName = "Andrew", indem der Index verwendet wird. Anschließend werden alle Einträge mit „firstName“ = „Andrew“ über eine nachfolgende Pipeline übergeben, um das Filterprädikat CONTAINS auszuwerten.

  • Sie können Abfragen beschleunigen und vollständige Containerscans vermeiden, wenn Sie Funktionen verwenden, die eine vollständige Überprüfung wie CONTAINS durchführen. Sie können weitere Filterprädikate hinzufügen, die den Index verwenden, um diese Abfragen zu beschleunigen. Die Reihenfolge der Filterklauseln ist nicht von Bedeutung. Die Abfrage-Engine ermittelt, welche Prädikate selektiver sind, und führt die Abfrage entsprechend aus.

Informationen zum Konfigurieren zusammengesetzter Indizes finden Sie unter Manage indexing policies in Azure Cosmos DB.

Vektorindizes

Vektorindizes erhöhen die Effizienz beim Ausführen von Vektorsuchen mithilfe der -Systemfunktion. Vektorsuchen haben bei Verwendung eines Vektorindexes deutlich geringere Latenz, einen höheren Durchsatz und weniger RU-Verbrauch. Azure Cosmos DB für NoSQL unterstützt alle Vektoreinbettungen (Text, Bild, Multimodal usw.) mit bis zu 4.096 Dimensionen. Informationen zum Konfigurieren von Vektorindizes finden Sie in den Beispielen zur Vektorindizierungsrichtlinie.

  • -Vektorsuchabfragen:

    SELECT TOP 10 *
FROM c
ORDER BY VectorDistance(c.vector1, c.vector2)

  • Projektion der Ähnlichkeitsbewertung in Vektorsuchabfragen:

    SELECT TOP 10 c.name, VectorDistance(c.vector1, c.vector2) AS SimilarityScore
FROM c
ORDER BY VectorDistance(c.vector1, c.vector2)

  • Bereichsfilter für die Ähnlichkeitsbewertung

    SELECT TOP 10 *
FROM c
WHERE VectorDistance(c.vector1, c.vector2) > 0.8
ORDER BY VectorDistance(c.vector1, c.vector2)

Wichtig

Derzeit sind Vektorrichtlinien und Vektorindizes nach der Erstellung unveränderlich. Um Änderungen vorzunehmen, erstellen Sie eine neue Sammlung.

Indexnutzung

Es gibt fünf Möglichkeiten, wie die Abfrage-Engine Abfragefilter auswerten kann. Diese sind hier in absteigender Reihenfolge von der effizientesten zu der am wenigsten effizienten aufgelistet:

  • Indexsuche
  • Genauer Indexscan
  • Erweiterter Indexscan
  • Vollständiger Indexscan
  • Vollständige Überprüfung

Wenn Sie Eigenschaftenpfade indizieren, verwendet die Abfrage-Engine den Index automatisch so effizient wie möglich. Abgesehen von der Indizierung neuer Eigenschaftenpfade müssen Sie keine Konfigurationen durchführen, um die Verwendung des Index durch Abfragen zu optimieren. Die RU-Gebühr einer Abfrage setzt sich aus der RU-Gebühr für die Indexnutzung und der RU-Gebühr für das Laden von Elementen zusammen.

In der folgenden Tabelle sind die verschiedenen Verwendungsmöglichkeiten von Indizes in Azure Cosmos DB zusammengefasst:

Indexsuchtyp BESCHREIBUNG Allgemeine Beispiele RU-Gebühr für die Indexnutzung RU-Gebühr für das Laden von Elementen aus dem Transaktionsdatenspeicher
Indexsuche Lesen nur erforderlicher indizierter Werte und Laden nur übereinstimmender Elemente aus dem Transaktionsdatenspeicher Gleichheitsfilter, IN Konstant pro Gleichheitsfilter Erhöht sich basierend auf der Anzahl von Elementen in Abfrageergebnissen
Genauer Indexscan Binärsuche indizierter Werte und Laden nur übereinstimmender Elemente aus dem Transaktionsdatenspeicher Bereichsvergleiche (>, <, <=, oder >=), StartsWith Vergleichbar mit Indexsuche, erhöht sich leicht basierend auf der Kardinalität indizierter Eigenschaften Erhöht sich basierend auf der Anzahl von Elementen in Abfrageergebnissen
Erweiterter Indexscan Optimierte Suche (jedoch weniger effizient als Binärsuche) indizierter Werte und Laden nur übereinstimmender Elemente aus dem Transaktionsdatenspeicher StartsWith (ohne Berücksichtigung der Groß-/Kleinschreibung), StringEquals (ohne Berücksichtigung der Groß-/Kleinschreibung) Erhöht sich leicht basierend auf der Kardinalität indizierter Eigenschaften Erhöht sich basierend auf der Anzahl von Elementen in Abfrageergebnissen
Vollständiger Indexscan Lesen eines eindeutigen Satzes indizierter Werte und Laden nur übereinstimmender Elemente aus dem Transaktionsdatenspeicher Contains, EndsWith, RegexMatch, LIKE Erhöht sich linear basierend auf der Kardinalität indizierter Eigenschaften Erhöht sich basierend auf der Anzahl von Elementen in Abfrageergebnissen
Vollständige Überprüfung Laden aller Elemente aus dem Transaktionsdatenspeicher Oben, unten – Erhöht sich basierend auf der Anzahl von Elementen im Container

Beim Schreiben von Abfragen sollten Sie Filterprädikate verwenden, die den Index so effizient wie möglich nutzen. Wenn z. B. oder für Ihren Anwendungsfall geeignet ist, sollten Sie auswählen, da hiermit statt eines vollständigen Indexscans ein präziser Indexscan durchgeführt wird.

Details zur Indexnutzung

In diesem Abschnitt werden weitere Details zur Verwendung von Indizes für Abfragen behandelt. Diese Detailstufe ist nicht erforderlich, um zu erfahren, wie Sie mit Azure Cosmos DB anfangen, wird aber für neugierige Benutzer detailliert dokumentiert. Dazu das bereits zuvor in diesem Dokument verwendete Beispielelement genutzt:

Beispielelemente:

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

{
  "id": 2,
  "locations": [
    { "country": "Ireland", "city": "Dublin" }
  ],
  "headquarters": { "country": "Belgium", "employees": 200 },
  "exports": [
    { "city": "Moscow" },
    { "city": "Athens" },
    { "city": "London" }
  ]
}

Azure Cosmos DB verwendet einen invertierten Index. Der Index ordnet jeden JSON-Pfad dem Satz von Elementen zu, die diesen Wert enthalten. Die Element-ID-Zuordnung wird auf vielen verschiedenen Indexseiten für den Container dargestellt. Hier sehen Sie eine Beispielabbildung eines invertierten Index für einen Container, der die beiden Beispielelemente enthält:

`Path` Wert Liste der Element-IDs
/locations/0/country Deutschland 1
/locations/0/country Irland 2
/locations/0/city Berlin 1
/locations/0/city Dublin 2
/locations/1/country Frankreich 1
/locations/1/city Paris 1
/hauptsitz/land Belgien 1, 2
/headquarters/employees 200 2
/headquarters/employees 250 1

Der invertierte Index verfügt über zwei wichtige Attribute:

  • Werte werden für einen bestimmten Pfad in aufsteigender Reihenfolge sortiert. Daher kann die Abfrage-Engine problemlos über den Index bedienen.
  • Die Abfrage-Engine kann für einen bestimmten Pfad den eindeutigen Satz möglicher Werte durchsuchen, um die Indexseiten zu ermitteln, die Ergebnisse enthalten.

Die Abfrage-Engine kann den invertierten Index auf vier verschiedene Arten nutzen:

Indexsuche

Betrachten Sie die folgende Abfrage:

SELECT location
FROM location IN company.locations
WHERE location.country = 'France'

Der Abfrageprädikat (Filtern nach Elementen, bei denen irgendein Standort "Frankreich" als Land oder Region hat) würde dem in diesem Diagramm hervorgehobenen Pfad entsprechen.

Diagramm eines Traversals (Suche), das einem bestimmten Pfad innerhalb eines Baums folgt.

Da diese Abfrage einen Gleichheitsfilter aufweist, können nach dem Durchlaufen dieser Struktur die Indexseiten, die die Abfrageergebnisse enthalten, schnell ermittelt werden. In diesem Fall liest die Abfrage-Engine Indexseiten, die Element 1 enthalten. Eine Indexsuche ist die effizienteste Möglichkeit zur Verwendung des Indexes. Bei einer Indexsuche werden nur die erforderlichen Indexseiten gelesen und nur die Elemente in den Abfrageergebnissen geladen. Daher sind der Zeitaufwand und die RU-Gebühr für die Indexsuche äußerst niedrig und zwar unabhängig vom Gesamtdatenvolumen.

Genauer Indexscan

Betrachten Sie die folgende Abfrage:

SELECT *
FROM company
WHERE company.headquarters.employees > 200

Das Abfrageprädikat (Filtern nach Elementen mit mehr als 200 Mitarbeitern) kann mit einem präzisen Indexscan des Pfads ausgewertet werden. Bei einem präzisen Indexscan führt die Abfrage-Engine zuerst eine Binärsuche nach dem eindeutigen Satz möglicher Werte durch, um den Speicherort des Werts für den Pfad zu finden. Da die Werte für jeden Pfad in aufsteigender Reihenfolge sortiert sind, ist es für die Abfrage-Engine einfach, eine binäre Suche durchzuführen. Nachdem die Abfrage-Engine den Wert gefunden hat, beginnt sie mit dem Lesen aller verbleibenden Indexseiten (in aufsteigender Reihenfolge).

Da die Abfrage-Engine eine Binärsuche durchführen kann, um das Überprüfen unnötiger Indexseiten zu vermeiden, weisen präzise Indexscans in der Regel eine vergleichbare Latenz und ähnliche RU-Gebühren wie Indexsuchvorgänge auf.

Erweiterter Indexscan

Betrachten Sie die folgende Abfrage:

SELECT *
FROM company
WHERE STARTSWITH(company.headquarters.country, "United", true)

Das Abfrageprädikat (Filtern von Elementen, die eine Zentrale an einem Ort haben, der ohne Berücksichtigung der Groß- und Kleinschreibung mit "United" beginnt) kann durch einen erweiterten Indexscan des -Pfads ausgewertet werden. Vorgänge, die einen erweiterten Indexscan durchführen, verfügen über Optimierungen, die dazu beitragen können, das Scannen jeder Indexseite zu vermeiden. Diese Vorgänge sind jedoch etwas kostspieliger als die binäre Suche eines präzisen Indexscans.

Wenn z. B. ohne Beachtung der Groß-/Kleinschreibung ausgewertet wird, überprüft die Abfrage-Engine den Index auf verschiedene mögliche Kombinationen aus Groß- und Kleinbuchstaben. Durch diese Optimierung kann die Abfrage-Engine das Lesen der meisten Indexseiten vermeiden. Verschiedene Systemfunktionen weisen unterschiedliche Optimierungen auf, mit denen das Lesen jeder Indexseite vermieden werden kann. Daher werden diese im Allgemeinen als erweiterter Indexscan kategorisiert.

Vollständiger Indexscan

Betrachten Sie die folgende Abfrage:

SELECT *
FROM company
WHERE CONTAINS(company.headquarters.country, "United")

Das Abfrageprädikat (Filtern nach Elementen mit Hauptsitz an einem Standort, der „United“ enthält) kann mit einem Indexscan des Pfads ausgewertet werden. Im Gegensatz zu einem präzisen Indexscan wird bei einem vollständigen Indexscan immer der eindeutige Satz möglicher Werte überprüft, um die Indexseiten zu ermitteln, die Ergebnisse enthalten. In diesem Fall wird für den Index ausgeführt. Der Zeitaufwand und die RU-Gebühr für Indexscans steigen mit zunehmender Kardinalität des Pfads. Anders ausgedrückt: Je mehr mögliche eindeutige Werte von der Abfrage-Engine überprüft werden müssen, desto höher sind Latenz und RU-Gebühr für einen vollständigen Indexscan.

Sehen Sie sich beispielsweise die beiden Eigenschaften und an. Die Kardinalität von „town“ ist 5.000, die Kardinalität von ist 200. Im Folgenden finden Sie zwei Beispielabfragen, die jeweils über eine CONTAINS-Systemfunktion verfügen, die einen vollständigen Indexscan für die Eigenschaft durchführt. Die erste Abfrage verbraucht mehr RUs als die zweite Abfrage, da die Kardinalität von „town“ höher als die von ist.

SELECT *
FROM c
WHERE CONTAINS(c.town, "Red", false)

SELECT *
FROM c
WHERE CONTAINS(c.country, "States", false)

Vollständige Überprüfung

In einigen Fällen kann das Abfragemodul möglicherweise keinen Abfragefilter mithilfe des Indexes auswerten. In diesem Fall muss die Abfrage-Engine alle Elemente aus dem Transaktionsspeicher laden, um den Abfragefilter auszuwerten. Vollständige Überprüfungen verwenden nicht den Index und weisen eine RU-Gebühr auf, die linear mit der Gesamtdatengröße zunimmt. Glücklicherweise kommen Vorgänge, die vollständige Überprüfungen erfordern, nur selten vor.

Vektorsuchabfragen ohne definierten Vektorindex

Wenn Sie keine Vektorindexrichtlinie definieren und die Systemfunktion in einer Klausel verwenden, führt dies zu einer vollständigen Überprüfung und hat eine RU-Belastung höher, als wenn Sie eine Vektorindexrichtlinie definiert haben. Wenn Sie verwenden, während der boolesche Brute-Force-Wert auf true festgelegt ist und Sie keinen -Index für den Vektorpfad definiert haben, wird eine vollständige Überprüfung durchgeführt.

Abfragen mit komplexen Filterausdrücken

In den vorherigen Beispielen wurden nur Abfragen mit einfachen Filterausdrücken berücksichtigt (z. B. Abfragen mit nur einem Gleichheits- oder Bereichsfilter). In Wirklichkeit weisen die meisten Abfragen wesentlich komplexere Filterausdrücke auf.

Betrachten Sie die folgende Abfrage:

SELECT *
FROM company
WHERE company.headquarters.employees = 200 AND CONTAINS(company.headquarters.country, "United")

Zum Ausführen dieser Abfrage muss die Abfrage-Engine eine genaue Indexsuche für und einen vollständigen Indexscan für ausführen. Die Abfrage-Engine weist eine interne Heuristik auf, die für eine möglichst effiziente Auswertung des Abfragefilterausdrucks genutzt wird. In diesem Fall würde die Abfrage-Engine das Lesen unnötiger Indexseiten vermeiden, indem zuerst eine Indexsuche ausgeführt wird. Wenn beispielsweise nur 50 Elemente dem Gleichheitsfilter entsprechen, muss die Abfrage-Engine nur auf den Indexseiten auswerten, die diese 50 Elemente enthalten. Ein vollständiger Indexscan des gesamten Containers wäre nicht erforderlich.

Indexnutzung für skalare Aggregatfunktionen

Abfragen mit Aggregatfunktionen müssen ausschließlich auf dem Index basieren, um diesen zu verwenden.

In einigen Fällen kann der Index falsch positive Ergebnisse zurückgeben. Wenn Sie beispielsweise den Index auswerten , kann die Anzahl der Übereinstimmungen im Index die Anzahl der Abfrageergebnisse überschreiten. Die Abfrage-Engine lädt dann alle Indexergebnisse, wertet den Filter für die geladenen Elemente aus und gibt nur die richtigen Ergebnisse zurück.

Bei den meisten Abfragen hat das Laden falsch positiver Indexergebnisse keine spürbaren Auswirkungen auf die Indexauslastung.

Angenommen, beispielsweise liegt die folgende Abfrage vor:

SELECT *
FROM company
WHERE CONTAINS(company.headquarters.country, "United")

Die Systemfunktion gibt möglicherweise einige falsch positive Übereinstimmungen zurück, sodass das Abfragemodul überprüfen muss, ob jedes geladene Element dem Filterausdruck entspricht. In diesem Beispiel muss das Abfragemodul möglicherweise nur einige zusätzliche Elemente laden, sodass der Effekt auf die Indexauslastung und die RU-Belastung minimal ist.

Abfragen mit Aggregatfunktionen müssen jedoch ausschließlich auf dem Index basieren, um diesen zu verwenden. Betrachten Sie beispielsweise die folgende Abfrage mit einem -Aggregat:

SELECT COUNT(1)
FROM company
WHERE CONTAINS(company.headquarters.country, "United")

Wie im ersten Beispiel gibt die Systemfunktion möglicherweise einige False Positive-Übereinstimmungen zurück. Im Gegensatz zur -Abfrage kann die -Abfrage jedoch nicht den Filterausdruck für die geladenen Elemente auswerten, um alle Indexergebnisse zu überprüfen. Die -Abfrage muss ausschließlich auf dem Index basieren. Wenn also die Möglichkeit besteht, dass ein Filterausdruck falsch positive Übereinstimmungen zurückgibt, greift die Abfrage-Engine auf eine vollständige Überprüfung zurück.

Abfragen mit den folgenden Aggregatfunktionen müssen ausschließlich auf dem Index basieren, sodass die Auswertung einiger Systemfunktionen eine vollständige Überprüfung erfordert.

  • AVG
  • COUNT
  • MAX
  • MIN
  • SUMME

Nächste Schritte

  • Last updated on