Freigeben über

Tipps zur Abfrageleistung für Azure Cosmos DB-SDKs

GILT FÜR: NoSQL

Azure Cosmos DB ist eine schnelle und flexible verteilte Datenbank mit nahtloser Skalierung, garantierter Latenz und garantiertem Durchsatz. Die Skalierung Ihrer Datenbank mit Azure Cosmos DB erfordert weder aufwendige Änderungen an der Architektur noch das Schreiben von komplexem Code. Das Hoch- und Herunterskalieren ist so einfach wie einen einzigen API-Aufruf zu tätigen. Weitere Informationen finden Sie unter Bereitstellen von Container-Durchsatz oder Bereitstellen von Datenbank-Durchsatz.

Reduzierung von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Netzwerkanforderungen an das Azure Cosmos DB-Gateway fügen der Latenz des Abfragevorgangs hinzu. Es gibt zwei Möglichkeiten, diese Anforderung zu entfernen und die Latenz des Abfragevorgangs zu reduzieren:

Optimieren einzelner Partitionsabfragen mit Optimistischer Direkter Ausführung

Azure Cosmos DB NoSQL verfügt über eine Optimierung mit dem Namen „Optimistic Direct Execution (ODE)“, die die Effizienz bestimmter NoSQL-Abfragen verbessern kann. Insbesondere sind Abfragen, die keine Verteilung erfordern, solche, die auf einer einzigen physischen Partition ausgeführt werden können, sowie solche, bei denen die Antworten keine Paginierung erfordern. Bei Abfragen, die keine Verteilung erfordern, können bestimmte Prozesse, wie die clientseitige Erstellung von Abfrageplänen und die Umschreibung von Abfragen, sicher übersprungen werden, wodurch die Abfragelatenz und die Kosten für Request Units (RU) reduziert werden. Wenn Sie den Partitionsschlüssel in der Anforderung oder Abfrage selbst angeben (oder nur über eine physische Partition verfügen), und die Ergebnisse Ihrer Abfrage keine Paginierung erfordern, kann die ODE Ihre Abfragen verbessern.

Hinweis

ODE, das eine verbesserte Leistung für Abfragen bietet, die keine Verteilung erfordern, sollte nicht mit dem direkten Modus verwechselt werden. Dies ist ein Pfad zum Verbinden Ihrer Anwendung mit Back-End-Replikaten.

ODE ist ab sofort im .NET-SDK ab Version 3.38.0 verfügbar. Wenn Sie eine Abfrage ausführen und einen Partitionsschlüssel in der Anforderung oder Abfrage selbst angeben, oder Ihre Datenbank verfügt nur über eine physische Partition, kann die Abfrageausführung die Vorteile von ODE verwenden. Um ODE zu aktivieren, legen Sie in "QueryRequestOptions" auf "true" fest EnableOptimisticDirectExecution .

Einzelne Partitionsabfragen, die GROUP BY-, ORDER BY-, DISTINCT- und Aggregationsfunktionen (z. B. Summe, Mittelwert, Min und Max) enthalten, können von der Verwendung von ODE erheblich profitieren. In Szenarien, in denen die Abfrage auf mehrere Partitionen ausgerichtet ist oder dennoch eine Paginierung erfordert, ist die Latenz der Abfrageantwort und der RU-Kosten möglicherweise höher als ohne ODE. Daher sollten Sie bei Verwendung von ODE Folgendes ausführen:

  • Geben Sie den Partitionsschlüssel im Aufruf oder in der Abfrage selbst an.
  • Stellen Sie sicher, dass ihre Datengröße nicht zunimmt und die Partition aufgeteilt wurde.
  • Stellen Sie sicher, dass Ihre Abfrageergebnisse keine Paginierung erfordern, um die Vorteile der ODE in vollem Umfang zu nutzen.

Nachfolgend finden Sie einige Beispiele für einfache Abfragen mit einer einzelnen Partition, die von ODE profitieren können:

- SELECT * FROM r
- SELECT * FROM r WHERE r.pk == "value"
- SELECT * FROM r WHERE r.id > 5
- SELECT r.id FROM r JOIN id IN r.id
- SELECT TOP 5 r.id FROM r ORDER BY r.id
- SELECT * FROM r WHERE r.id > 5 OFFSET 5 LIMIT 3

Es kann vorkommen, dass einzelne Partitionsabfragen möglicherweise weiterhin eine Verteilung erfordern, wenn die Anzahl der Datenelemente im Laufe der Zeit zunimmt und Ihre Azure Cosmos DB-Datenbank die Partition aufteilt. Beispiele für Abfragen, bei denen dies auftreten könnte:

- SELECT Count(r.id) AS count_a FROM r
- SELECT DISTINCT r.id FROM r
- SELECT Max(r.a) as min_a FROM r
- SELECT Avg(r.a) as min_a FROM r
- SELECT Sum(r.a) as sum_a FROM r WHERE r.a > 0

Einige komplexe Abfragen können immer eine Verteilung erfordern, auch wenn sie auf eine einzelne Partition ausgerichtet sind. Beispiele für einfache Abfragen sind:

- SELECT Sum(id) as sum_id FROM r JOIN id IN r.id
- SELECT DISTINCT r.id FROM r GROUP BY r.id
- SELECT DISTINCT r.id, Sum(r.id) as sum_a FROM r GROUP BY r.id
- SELECT Count(1) FROM (SELECT DISTINCT r.id FROM root r)
- SELECT Avg(1) AS avg FROM root r

Es ist wichtig zu beachten, dass ODE möglicherweise nicht immer den Abfrageplan abruft und daher nicht in der Lage ist, nicht unterstützte Abfragen zu verbieten oder zu deaktivieren. Nach der Partitionsteilung sind solche Abfragen beispielsweise nicht mehr für ODE geeignet und werden daher nicht ausgeführt, da clientseitige Abfrageplanauswertung diese blockiert. Um Kompatibilitäts-/Dienstkontinuität zu gewährleisten, ist es wichtig sicherzustellen, dass nur Abfragen mit der ODE verwendet werden, die in Szenarien ohne die ODE vollständig unterstützt werden (d. h. sie werden ausgeführt und erzeugen das richtige Ergebnis im allgemeinen Fall mit mehreren Partitionen).

Hinweis

Die Verwendung von ODE kann dazu führen, dass ein neuer Typ von Fortsetzungstoken generiert wird. Ein solches Token wird von den älteren SDKs entwurfsbedingt nicht erkannt, und dies könnte zu der Ausnahme „Fehlerhaftes Fortsetzungstoken“ führen. Wenn Sie ein Szenario haben, in dem Token, die aus den neueren SDKs generiert werden, von einem älteren SDK verwendet werden, empfehlen wir einen zweistufigen Ansatz zum Upgrade:

  • Führen Sie ein Upgrade auf das neue SDK durch und deaktivieren Sie ODE, beides zusammen als Teil einer einzelnen Bereitstellung. Warten Sie, bis alle Knoten ein Upgrade durchführen.
  • Um ODE zu deaktivieren, setzen Sie EnableOptimisticDirectExecution in den QueryRequestOptions auf "false".
  • Als Teil der zweiten Bereitstellung aktivieren Sie ODE für alle Knoten.

Lokale Abfrageplangenerierung verwenden

Das SQL SDK enthält eine systemeigene ServiceInterop.dll , um Abfragen lokal zu analysieren und zu optimieren. ServiceInterop.dll wird nur auf der Windows x64-Plattform unterstützt. Bei den folgenden Anwendungstypen wird standardmäßig die 32-Bit-Hostverarbeitung verwendet. Um die Hostverarbeitung auf die 64-Bit-Verarbeitung umzustellen, führen Sie je nach Typ Ihrer Anwendung die folgenden Schritte aus:

  • Bei ausführbaren Anwendungen können Sie die Host-Verarbeitung ändern, indem Sie das Plattformziel im Fenster Projekteigenschaften auf der Registerkarte Erstellen auf x64 setzen.

  • Bei VSTest-basierten Testprojekten können Sie die Hostverarbeitung ändern, indem Sie in der Menüoption Visual Studio Test die Option >>Default Processor Architecture as X64 (Standardprozessorarchitektur als x64) auswählen.

  • Bei lokal bereitgestellten ASP.NET-Webanwendungen ändern Sie die Hostverarbeitung, indem Sie unter Extras>>> die Option 64-Bit-Version von IIS Express für Websites und Projekte verwenden aktivieren.

  • Für ASP.NET-Webanwendungen, die in Azure bereitgestellt werden, können Sie die Hostverarbeitung ändern, indem Sie im Azure-Portal unter Anwendungseinstellungen die 64-Bit-Plattform auswählen.

Hinweis

Standardmäßig ist bei neuen Visual Studio-Projekten Any CPU festgelegt. Es wird empfohlen, Ihr Projekt auf x64 festzulegen, damit es nicht zu x86 wechselt. Ein Projekt mit der Einstellung Beliebige CPU kann schnell zu x86 wechseln, wenn eine Abhängigkeit hinzugefügt wird, die nur bei x86 verfügbar ist.

ServiceInterop.dll muss sich im Ordner befinden, von dem die SDK-DLL ausgeführt wird. Dies sollte nur dann von Bedeutung sein, wenn Sie DLLs manuell kopieren oder über benutzerdefinierte Build-/Bereitstellungssysteme verfügen.

Einzelpartition-Abfragen verwenden

Für Abfragen, die auf einen Partitionsschlüssel abzielen, indem sie die PartitionKey-Eigenschaft in QueryRequestOptions festlegen und keine Aggregationen enthalten (einschließlich Distinct, DCount oder Group By). In diesem Beispiel wird das Partitionsschlüsselfeld von /state nach dem Wert Washington gefiltert.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle' AND c.state = 'Washington'"
{
    // ...
}

Optional können Sie den Partitionsschlüssel als Teil des Anforderungsoptionenobjekts bereitstellen.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
    // ...
}

Wichtig

Auf Clients, die ein Nicht-Windows-Betriebssystem ausführen, z. B. Linux und macOS, sollte der Partitionsschlüssel immer im Anforderungsoptionenobjekt angegeben werden.

Hinweis

Für partitionsübergreifende Abfragen muss das SDK alle vorhandenen Partitionen besuchen, um nach Ergebnissen zu suchen. Je mehr physische Partitionen der Container hat, desto langsamer sind sie tendenziell.

Vermeiden der unnötigen Neuerstellung des Iterators

Wenn alle Abfrageergebnisse von der aktuellen Komponente genutzt werden, müssen Sie den Iterator nicht mit der Fortsetzung für jede Seite neu erstellen. Ziehen Sie es immer vor, die Abfrage vollständig zu leeren, es sei denn, die Paginierung wird von einer anderen aufrufenden Komponente gesteuert:

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
    while (feedIterator.HasMoreResults) 
    {
        foreach(MyItem document in await feedIterator.ReadNextAsync())
        {
            // Iterate through documents
        }
    }
}

Optimieren des Parallelitätsgrads

Optimieren Sie bei Abfragen die Eigenschaft MaxConcurrency in QueryRequestOptions, um die besten Konfigurationen für Ihre Anwendung zu ermitteln, insbesondere, wenn Sie partitionsübergreifende Abfragen (ohne Filter für den Partitionsschlüsselwert) ausführen. MaxConcurrency steuert die maximale Anzahl von parallelen Aufgaben, d. h. das Maximum von Partitionen, die parallel besucht werden. Durch Festlegen des Werts auf -1 kann das SDK die optimale Parallelität festlegen.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxConcurrency = -1 }))
{
    // ...
}

Gehen wir davon aus, dass:

  • D = Maximale Anzahl paralleler Vorgänge (= Gesamtanzahl der Prozessoren auf dem Clientcomputer)
  • P = Vom Benutzer angegebene maximale Anzahl paralleler Aufgaben
  • N = Anzahl der Partitionen, auf die zur Beantwortung einer Abfrage zugegriffen werden muss

Im Folgenden finden Sie Auswirkungen darauf, wie sich die parallelen Abfragen für unterschiedliche Werte von P verhalten.

  • (P == 0) => Serieller Modus
  • (P == 1) => maximal eine Aufgabe
  • (P > 1) => minimale Anzahl (P, N) paralleler Aufgaben
  • (P < 1) => minimale Anzahl (N, D) paralleler Aufgaben

Seitengröße anpassen

Wenn Sie eine SQL-Abfrage stellen, werden die Ergebnisse bei einem zu großen Resultset segmentiert zurückgegeben.

Hinweis

Die MaxItemCount-Eigenschaft sollte nicht nur für die Paginierung verwendet werden. Ihr Hauptverwendungszweck ist die Verbesserung der Leistung von Abfragen durch Reduzierung der maximalen Anzahl von Elementen, die auf einer einzigen Seite zurückgegeben werden.

Sie können die Seitengröße auch mithilfe der verfügbaren Azure Cosmos DB-SDKs festlegen. Mit der MaxItemCount-Eigenschaft in QueryRequestOptions können Sie die maximale Anzahl von Elementen festlegen, die beim Enumerationsvorgang zurückgegeben werden. Wenn MaxItemCount dieser Wert auf -1 festgelegt ist, findet das SDK je nach Dokumentgröße automatisch den optimalen Wert. Beispiel:

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxItemCount = 1000}))
{
    // ...
}

Beim Ausführen einer Abfrage werden die resultierenden Daten in einem TCP-Paket gesendet. Wenn Sie einen zu niedrigen Wert für MaxItemCount angeben, ist die zum Senden der Daten im TCP-Paket erforderliche Anzahl der Roundtrips hoch, was sich auf die Leistung auswirkt. Wenn Sie also nicht sicher sind, welcher Wert für die MaxItemCount Eigenschaft festgelegt werden soll, sollten Sie ihn auf -1 festlegen und das SDK den Standardwert auswählen lassen.

Die Puffergröße optimieren

Parallele Abfrage ist für das Vorabfetch von Ergebnissen konzipiert, während der aktuelle Batch der Ergebnisse vom Client verarbeitet wird. Das Vorausladen hilft dabei, die Gesamtlatenz einer Abfrage zu verringern. Die MaxBufferedItemCount-Eigenschaft beschränkt QueryRequestOptions die Anzahl der vorab zurückgegebenen Ergebnisse. Legen Sie MaxBufferedItemCount die erwartete Anzahl der zurückgegebenen Ergebnisse (oder eine höhere Zahl) fest, damit die Abfrage den maximalen Vorteil beim Vorabruf erhalten kann. Wenn Sie diesen Wert auf -1 festlegen, bestimmt das System automatisch die Anzahl der zu pufferden Elemente.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxBufferedItemCount = -1}))
{
    // ...
}

Das Vorabfetching funktioniert unabhängig vom Grad der Parallelität auf die gleiche Weise, und es gibt einen einzelnen Puffer für die Daten aus allen Partitionen.

Nächste Schritte

Weitere Informationen über Leistung mit dem .NET SDK:

Abfrageplanaufrufe reduzieren

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Netzwerkanforderungen an das Azure Cosmos DB-Gateway fügen der Latenz des Abfragevorgangs hinzu.

Verwenden Sie das Zwischenspeichern von Abfrageplänen

Der Abfrageplan für eine Abfrage, die auf eine einzelne Partition abzielt, wird auf dem Client zwischengespeichert. Dadurch entfällt nach dem ersten Aufruf die Notwendigkeit, das Gateway abzufragen, um den Abfrageplan abzurufen. Der Schlüssel für den zwischengespeicherten Abfrageplan ist die SQL-Abfragezeichenfolge. Sie müssen sicherstellen, dass die Abfrage parametrisiert ist. Wenn dies nicht der Fall ist, ist die Abfrageplan-Cache-Suche häufig ein Cache-Fehlschlag, da die Abfragezeichenfolge bei Aufrufen wahrscheinlich nicht identisch ist. Das Zwischenspeichern von Abfrageplänen ist standardmäßig für Java SDK ab Version 4.20.0 sowie für Spring Data Azure Cosmos DB SDK ab Version 3.13.0 aktiviert.

Verwenden parametrisierter Abfragen für eine einzelne Partition

Bei parametrisierten Abfragen, die auf einen Partitionsschlüssel mit setPartitionKeyCosmosQueryRequestOptions beschränkt sind und keine Aggregationen enthalten (einschließlich Distinct, DCount oder Group By), kann der Abfrageplan vermieden werden:

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));

ArrayList<SqlParameter> paramList = new ArrayList<SqlParameter>();
paramList.add(new SqlParameter("@city", "Seattle"));
SqlQuerySpec querySpec = new SqlQuerySpec(
        "SELECT * FROM c WHERE c.city = @city",
        paramList);

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Hinweis

Für partitionsübergreifende Abfragen muss das SDK alle vorhandenen Partitionen besuchen, um nach Ergebnissen zu suchen. Je mehr physische Partitionen der Container hat, desto langsamer sind sie tendenziell.

Optimieren des Parallelitätsgrads

Bei parallelen Abfragen werden mehrere Partitionen parallel abgefragt. Die Daten eines individuell partitionierten Containers werden in Bezug auf die Abfrage aber seriell abgerufen. Verwenden Sie also setMaxDegreeOfParallelism in CosmosQueryRequestOptions, um den Wert auf die Anzahl der Partitionen festzulegen, über die Sie verfügen. Falls Ihnen die Anzahl von Partitionen nicht bekannt ist, können Sie setMaxDegreeOfParallelism auf einen hohen Wert festlegen. Das System wählt für den maximalen Grad an Parallelität dann den minimalen Wert aus (Anzahl von Partitionen, Benutzereingabe). Durch Festlegen des Werts auf -1 kann das SDK die optimale Parallelität festlegen.

Es ist wichtig zu beachten, dass parallele Abfragen die besten Vorteile erzielen, wenn die Daten gleichmäßig über alle Partitionen in Bezug auf die Abfrage verteilt werden. Wenn der partitionierte Container so partitioniert wird, dass alle oder die meisten von einer Abfrage zurückgegebenen Daten in einigen Partitionen (eine Partition im schlimmsten Fall) konzentriert sind, würde die Leistung der Abfrage beeinträchtigt.

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxDegreeOfParallelism(-1);

// Define the query

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Gehen wir davon aus, dass:

  • D = Maximale Anzahl paralleler Vorgänge (= Gesamtanzahl der Prozessoren auf dem Clientcomputer)
  • P = Vom Benutzer angegebene maximale Anzahl paralleler Aufgaben
  • N = Anzahl der Partitionen, auf die zur Beantwortung einer Abfrage zugegriffen werden muss

Im Folgenden finden Sie Auswirkungen darauf, wie sich die parallelen Abfragen für unterschiedliche Werte von P verhalten:

  • (P == 0) => Serieller Modus
  • (P == 1) => maximal eine Aufgabe
  • (P > 1) => minimale Anzahl (P, N) paralleler Aufgaben
  • (P == -1) => minimale Anzahl (N, D) paralleler Aufgaben

Seitengröße anpassen

Wenn Sie eine SQL-Abfrage stellen, werden die Ergebnisse bei einem zu großen Resultset segmentiert zurückgegeben. Ergebnisse werden standardmäßig in Blöcken mit je 100 Elementen oder 4 MB zurückgegeben (je nachdem, welcher Grenzwert zuerst erreicht wird). Wenn Sie die Seitengröße erhöhen, wird die Anzahl der erforderlichen Roundtrips reduziert und die Leistung für Abfragen erhöht, die mehr als 100 Elemente zurückgeben. Wenn Sie nicht sicher sind, welcher Wert festgelegt werden soll, ist 1.000 in der Regel eine gute Wahl. Die Arbeitsspeicherauslastung nimmt zu, wenn die Seitengröße zunimmt. Wenn ihre Workload also arbeitsspeicherempfindlich ist, sollten Sie einen niedrigeren Wert in Betracht ziehen.

Sie können den Parameter pageSize in iterableByPage() für die synchrone API und byPage() für die asynchrone API verwenden, um eine Seitengröße zu definieren:

//  Sync API
Iterable<FeedResponse<MyItem>> filteredItemsAsPages =
    container.queryItems(querySpec, options, MyItem.class).iterableByPage(continuationToken,pageSize);

for (FeedResponse<MyItem> page : filteredItemsAsPages) {
    for (MyItem item : page.getResults()) {
        //...
    }
}

//  Async API
Flux<FeedResponse<MyItem>> filteredItemsAsPages =
    asyncContainer.queryItems(querySpec, options, MyItem.class).byPage(continuationToken,pageSize);

filteredItemsAsPages.map(page -> {
    for (MyItem item : page.getResults()) {
        //...
    }
}).subscribe();

Die Puffergröße optimieren

Parallele Abfrage ist für das Vorabfetch von Ergebnissen konzipiert, während der aktuelle Batch der Ergebnisse vom Client verarbeitet wird. Das Vorabrufen hilft bei der allgemeinen Latenzverbesserung einer Abfrage. setMaxBufferedItemCount in CosmosQueryRequestOptions limitiert die Anzahl der voreingestellten Ergebnisse. Um das Vorabfetching zu maximieren, legen Sie den maxBufferedItemCount Wert auf eine höhere Zahl fest als die pageSize (HINWEIS: Dies kann auch zu einer hohen Speicherauslastung führen). Um das Vorausladen zu minimieren, setzen Sie den maxBufferedItemCount auf den Wert pageSize fest. Wenn Sie diesen Wert auf 0 festlegen, bestimmt das System automatisch die Anzahl der zu pufferden Elemente.

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxBufferedItemCount(-1);

// Define the query

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Das Vorabfetching funktioniert unabhängig vom Grad der Parallelität auf die gleiche Weise, und es gibt einen einzelnen Puffer für die Daten aus allen Partitionen.

Nächste Schritte

Weitere Informationen über Leistung mit dem Java-SDK:

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Netzwerkanforderungen an das Azure Cosmos DB-Gateway fügen der Latenz des Abfragevorgangs hinzu. Es gibt eine Möglichkeit, diese Anforderung zu entfernen und die Latenz des Abfragevorgangs für einzelne Partitionen zu verringern. Geben Sie für Einzelne Partitionsabfragen den Partitionsschlüsselwert für das Element an, und übergeben Sie ihn als partition_key Argument:

items = container.query_items(
        query="SELECT * FROM r where r.city = 'Seattle'",
        partition_key="Washington"
    )

Seitengröße anpassen

Wenn Sie eine SQL-Abfrage stellen, werden die Ergebnisse bei einem zu großen Resultset segmentiert zurückgegeben. Mit max_item_count können Sie die maximale Anzahl von Elementen festlegen, die beim Enumerationsvorgang zurückgegeben werden.

items = container.query_items(
        query="SELECT * FROM r where r.city = 'Seattle'",
        partition_key="Washington",
        max_item_count=1000
    )

Nächste Schritte

Weitere Informationen zur Verwendung des Python SDK für die API für NoSQL finden Sie hier:

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Netzwerkanforderungen an das Azure Cosmos DB-Gateway fügen der Latenz des Abfragevorgangs hinzu. Es gibt eine Möglichkeit, diese Anforderung zu entfernen und die Latenz des Abfragevorgangs für einzelne Partitionen zu verringern. Für Einzelpartitionsabfragen gibt es zwei Möglichkeiten, die Abfrage auf eine einzelne Partition zu beschränken.

Verwenden Sie einen parametrisierten Abfrageausdruck, und geben Sie den Partitionsschlüssel in der Abfrageanweisung an. Die Abfrage wird programmgesteuert als SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes' erstellt:

// find all items with same categoryId (partitionKey)
const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: "Bikes, Touring Bikes"
        }
    ]
};

// Get items 
const { resources } = await container.items.query(querySpec).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Alternativ dazu geben Sie partitionKey in FeedOptions ein, und übergeben Sie es als Argument:

const querySpec = {
    query: "select * from products p"
};

const { resources } = await container.items.query(querySpec, { partitionKey: "Bikes, Touring Bikes" }).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Seitengröße anpassen

Wenn Sie eine SQL-Abfrage stellen, werden die Ergebnisse bei einem zu großen Resultset segmentiert zurückgegeben. Mit maxItemCount können Sie die maximale Anzahl von Elementen festlegen, die beim Enumerationsvorgang zurückgegeben werden.

const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: items[2].categoryId
        }
    ]
};

const { resources } = await container.items.query(querySpec, { maxItemCount: 1000 }).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Erweiterte Abfragesteuerung

Für Cosmos DB JS SDK Version 4.3.0 und höher wurde das Flag enableQueryControl eingeführt, das eine bessere Kontrolle über die Ausführung von Abfragen ermöglicht und mehr Flexibilität bei der Verwaltung des Verbrauchs von Request Units (RU) bietet.

Standardmäßig ist enableQueryControl auf false festgelegt, und das SDK garantiert, dass jeder fetchNext-Aufruf maxItemCount Ergebnisse zurückliefert, vorausgesetzt, es existieren so viele Ergebnisse im Back-End. Um jedoch die garantierte Ergebnisanzahl zu erfüllen, kann das SDK Back-End-Partitionen mehrmals in einer einzelnen fetchNext Iteration abfragen. Dies kann manchmal zu unvorhersehbarer Latenz und RU-Abfluss ohne Benutzersteuerung führen, insbesondere wenn Ergebnisse über Partitionen verteilt werden.

Wenn enableQueryControl auf true gesetzt ist, fragt jeder fetchNext-Aufruf jetzt bis zu maxDegreeOfParallelism physische Partitionen ab. Wenn keine Ergebnisse gefunden oder Ergebnisse noch nicht bereitgestellt werden können, gibt das SDK leere Seiten zurück, anstatt alle Partitionen im Hintergrund zu durchsuchen. Auf diese Weise erhalten Benutzer eine bessere Kontrolle über die Abfrageausführung mit vorhersagbaren Latenz- und granularen RU-Verbrauchsdaten.

const options = {
  enableQueryControl: true, // Flag to enable new query pipeline.
  maxItemCount: 100,
  maxDegreeOfParallelism: 6
};

const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: items[2].categoryId
        }
    ]
};
const queryIterator = container.items.query(querySpec, options);
// use this iterator to fetch results.

Nächste Schritte

Weitere Informationen zur Verwendung des Node.js SDK für die API für NoSQL finden Sie hier:

  • Last updated on