Tipps zur Abfrageleistung für Azure Cosmos DB-SDKs

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Dies stellt im Allgemeinen eine Netzwerkanforderung an das Azure Cosmos DB-Gateway dar, wodurch die Latenz des Abfragevorgangs erhöht wird. Es gibt zwei Möglichkeiten, diese Anforderung zu entfernen und die Latenz des Abfragevorgangs zu reduzieren:

Optimieren einzelner Partitionsabfragen mit Optimistic Direct Execution

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 Abfragen, die keine Verteilung erfordern, umfassen diejenigen, die auf einer einzelnen physischen Partition ausgeführt werden können oder über Antworten verfügen, die keine Paginierung erfordern. Abfragen, die keine Verteilung erfordern, können einige Prozesse überspringen, z. B. die clientseitige Abfrageplangenerierung und das Neuschreiben von Abfragen, wodurch die Abfragelatenz und die RU-Kosten 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.

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 nur über eine physische Partition verfügt, kann Ihre Abfrageausführung die Vorteile der ODE nutzen. Um ODE zu aktivieren, legen Sie „EnableOptimisticDirectExecution“ in „QueryRequestOptions“ auf „true“ fest.

Einzelpartitionsabfragen mit GROUP BY-, ORDER BY-, DISTINCT- und Aggregationsfunktionen (wie Summe, Mittel, Min und Max) können von der Verwendung der ODE erheblich profitieren. In Szenarien, in denen die Abfrage jedoch auf mehrere Partitionen abzielt oder weiterhin eine Paginierung erfordert, können die Latenz der Abfrageantwort und die RU-Kosten höher sein als ohne die ODE. Daher empfehlen wir bei der Verwendung der ODE Folgendes:

• 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.

Im Folgenden finden Sie einige Beispiele für einfache Abfragen mit einer einzelnen Partition, die von der 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 Fälle geben, in denen Abfragen mit einer einzelnen Partition 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 die ODE möglicherweise nicht immer den Abfrageplan abruft und infolgedessen nicht in der Lage ist, nicht unterstützte Abfragen nicht zuzulassen oder zu deaktivieren. Beispielsweise sind solche Abfragen nach der Partitionsaufteilung nicht mehr für die ODE geeignet und werden daher nicht ausgeführt, da die 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).

Nutzung der lokalen Abfrageplangenerierung

Das SQL SDK enthält die native Datei „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 Test>Testeinstellungen>Default Processor Architecture as X64 (Standardprozessorarchitektur als x64) auswählen.

• Bei lokal bereitgestellten ASP.NET-Webanwendungen ändern Sie die Hostverarbeitung, indem Sie unter Extras>Optionen>Projekte und Projektmappen>Webprojekte 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.

Verwenden von Abfragen mit nur einer Partition

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

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

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        PartitionKey = new PartitionKey("Washington")
    }).AsDocumentQuery();

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

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        PartitionKey = new PartitionKey("Washington")
    }).AsDocumentQuery();
while (query.HasMoreResults) 
{
    foreach(Document document in await queryable.ExecuteNextAsync())
    {
        // Iterate through documents
    }
}

Optimieren des Parallelitätsgrades

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

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        MaxDegreeOfParallelism = -1, 
        EnableCrossPartitionQuery = true 
    }).AsDocumentQuery();

Annahme:

• D = Standardwert, maximale Anzahl paralleler Aufgaben (= Gesamtzahl 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

Es folgen die Auswirkungen auf das Verhalten der parallelen Abfragen bei unterschiedlichen Werten für P.

• (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

Optimieren der Seitengröße

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

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

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", 
    new FeedOptions { 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 nicht sicher sind, welchen Wert Sie für die MaxItemCount-Eigenschaft festlegen sollen, empfiehlt es sich, den Wert auf „-1“ festzulegen und den Standardwert vom SDK auswählen zu lassen.

Die Puffergröße optimieren

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

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", 
    new FeedOptions { MaxBufferedItemCount = -1 });

Das vorherige Abrufen funktioniert unabhängig vom Parallelitätsgrad, und es ist nur ein Puffer für die Daten aller Partitionen vorhanden.

Nächste Schritte

Weitere Informationen über Leistung mit dem .NET SDK:

• Bewährte Methoden für Azure Cosmos DB .NET SDK
• Leistungstipps für das Azure Cosmos DB .NET V3 SDK
• Leistungstipps für das Azure Cosmos DB .NET V2 SDK

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Dies stellt im Allgemeinen eine Netzwerkanforderung an das Azure Cosmos DB-Gateway dar, wodurch die Latenz des Abfragevorgangs erhöht wird.

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 Ihre Abfrage parametrisiert ist. Wenn dies nicht der Fall ist, resultiert die Cachesuche des Abfrageplans häufig in einem Cachefehler, da es unwahrscheinlich ist, dass die Abfragezeichenfolge der einzelnen Aufrufe 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 mit setPartitionKey in CosmosQueryRequestOptions auf einen Partitionsschlüssel festgelegt sind und keine Aggregationen enthalten (einschließlich Distinct, DCount, 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);

Optimieren des Parallelitätsgrades

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). Wenn Sie den Wert auf -1 festlegen, kann das SDK die optimale Parallelität automatisch festlegen.

Es ist wichtig zu beachten, dass sich für parallele Abfragen die größten Vorteile ergeben, wenn die Daten in Bezug auf die Abfrage gleichmäßig auf alle Partitionen verteilt werden. Wenn der partitionierte Container so partitioniert ist, dass sich alle Daten bzw. die meisten Daten, die von einer Abfrage zurückgegeben werden, auf einigen wenigen Partitionen befinden (schlimmstenfalls nur auf einer Partition), kann dies die Leistung beeinträchtigen.

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

Annahme:

• D = Standardwert, maximale Anzahl paralleler Aufgaben (= Gesamtzahl 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

Es folgen die Auswirkungen auf das Verhalten der parallelen Abfragen bei unterschiedlichen Werten für P.

• (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

Optimieren der Seitengröße

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). Das Erhöhen der Seitengröße reduziert die Anzahl der erforderlichen Roundtrips und steigert die Leistung für Abfragen, 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. Der Arbeitsspeicherverbrauch steigt, wenn die Seitengröße zunimmt. Wenn Ihre Workload sehr viel Arbeitsspeicher benötigt, sollten Sie also 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 Abfragen sind so konzipiert, dass Ergebnisse vorab abgerufen werden, während der Client den aktuellen Batch der Ergebnisse verarbeitet. Diese Art des Abrufs führt zu einer Verbesserung der Latenz einer Abfrage. setMaxBufferedItemCount in CosmosQueryRequestOptions begrenzt die Anzahl vorab abgerufener Ergebnisse. Um die Vorababrufe zu maximieren, legen Sie die maxBufferedItemCount auf eine höhere Zahl als pageSize fest (HINWEIS: Dies kann auch zu einer hohen Arbeitsspeichernutzung führen). Um das Vorababrufen zu minimieren, legen Sie die maxBufferedItemCount gleich der pageSize fest. Wenn Sie diesen Wert auf „0“ festlegen, kann das System die Anzahl der zu puffernden Elemente automatisch festlegen.

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 vorherige Abrufen funktioniert unabhängig vom Parallelitätsgrad, und es ist nur ein Puffer für die Daten aller Partitionen vorhanden.

Nächste Schritte

Weitere Informationen über Leistung mit dem Java-SDK:

• Bewährte Methoden für Azure Cosmos DB Java V4 SDK
• Leistungstipps für das Azure Cosmos DB Java V4 SDK

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Dies stellt im Allgemeinen eine Netzwerkanforderung an das Azure Cosmos DB-Gateway dar, wodurch die Latenz des Abfragevorgangs erhöht wird. Es gibt eine Möglichkeit, diese Anforderung zu entfernen und die Latenz des Abfragevorgangs für einzelne Partitionen zu verringern. Geben Sie für Einzelpartitionsabfragen 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"
    )

Optimieren der Seitengröße

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:

• Azure Cosmos DB Python-SDK für die NoSQL-API
• Schnellstart: Azure Cosmos DB for NoSQL-Clientbibliothek für Python

Reduzieren von Abfrageplanaufrufen

Zum Ausführen einer Abfrage muss ein Abfrageplan erstellt werden. Dies stellt im Allgemeinen eine Netzwerkanforderung an das Azure Cosmos DB-Gateway dar, wodurch die Latenz des Abfragevorgangs erhöht wird. 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üssels in der Abfrageanweisung an. Die Abfrage wird programmgesteuert als SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes' zusammengesetzt:

// 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}`);
}

Optimieren der Seitengröße

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

Nächste Schritte

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

• Azure Cosmos DB Node.js-SDK für die NoSQL-API
• Schnellstart: Azure Cosmos DB for NoSQL-Clientbibliothek für Node.js