Share via

Porady dotyczące wydajności zapytań dla zestawów SDK usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

Usługa Azure Cosmos DB to szybka, elastyczna rozproszona baza danych, która bezproblemowo skaluje się z gwarantowanymi opóźnieniami i poziomami przepływności. Nie musisz wprowadzać istotnych zmian architektury ani pisać złożonego kodu w celu skalowania bazy danych za pomocą usługi Azure Cosmos DB. Skalowanie w górę i w dół jest tak proste, jak tworzenie pojedynczego wywołania interfejsu API. Aby dowiedzieć się więcej, zobacz Aprowizowanie przepływności kontenera lub aprowizowanie przepływności bazy danych.

Zmniejsz liczbę wywołań planu zapytania

Aby wykonać zapytanie, należy skompilować plan zapytania. Ogólnie rzecz biorąc, reprezentuje żądanie sieciowe do bramy usługi Azure Cosmos DB, co zwiększa opóźnienie operacji zapytania. Istnieją dwa sposoby usunięcia tego żądania i zmniejszenia opóźnienia operacji zapytania:

Optymalizowanie zapytań z jedną partycją przy użyciu optymistycznego bezpośredniego wykonywania

Usługa Azure Cosmos DB NoSQL ma optymalizację o nazwie Optymistyczne bezpośrednie wykonywanie (ODE), co może zwiększyć wydajność niektórych zapytań NoSQL. W szczególności zapytania, które nie wymagają dystrybucji, obejmują te, które można wykonać na jednej partycji fizycznej lub które mają odpowiedzi, które nie wymagają stronicowania. Zapytania, które nie wymagają dystrybucji, mogą bezpiecznie pominąć niektóre procesy, takie jak generowanie planu zapytań po stronie klienta i ponowne zapisywanie zapytań, co zmniejsza opóźnienie zapytań i koszt jednostek RU. Jeśli określisz klucz partycji w żądaniu lub zapytaniu (lub masz tylko jedną partycję fizyczną), a wyniki zapytania nie wymagają stronicowania, funkcja ODE może poprawić zapytania.

Uwaga

Optymistyczne bezpośrednie wykonywanie (ODE), które zapewnia lepszą wydajność zapytań, które nie wymagają dystrybucji, nie należy mylić z trybem bezpośrednim, który jest ścieżką do łączenia aplikacji z replikami zaplecza.

Funkcja ODE jest teraz dostępna i domyślnie włączona w zestawie .NET SDK w wersji 3.38.0 lub nowszej. Po wykonaniu zapytania i określeniu klucza partycji w żądaniu lub zapytaniu baza danych ma tylko jedną partycję fizyczną, wykonanie zapytania może wykorzystać zalety funkcji ODE. Aby wyłączyć funkcję ODE, w poleceniu QueryRequestOptions ustaw wartość EnableOptimisticDirectExecution na false.

Zapytania o pojedynczą partycję, które zawierają funkcje GROUP BY, ORDER BY, DISTINCT i agregacji (takie jak suma, średnia, minimalna i maksymalna) mogą znacznie korzystać z funkcji ODE. Jednak w scenariuszach, w których zapytanie jest przeznaczone dla wielu partycji lub nadal wymaga stronicowania, opóźnienie odpowiedzi zapytania i koszt jednostek ŻĄDANIA może być wyższy niż bez użycia funkcji ODE. W związku z tym w przypadku używania funkcji ODE zalecamy:

  • Określ klucz partycji w wywołaniu lub zapytaniu.
  • Upewnij się, że rozmiar danych nie został rozrosty i spowodował podzielenie partycji.
  • Upewnij się, że wyniki zapytania nie wymagają stronicowania, aby uzyskać pełną korzyść z funkcji ODE.

Oto kilka przykładów prostych zapytań z jedną partycją, które mogą korzystać z funkcji ODE:

- 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

Mogą wystąpić przypadki, w których zapytania z jedną partycją mogą nadal wymagać dystrybucji, jeśli liczba elementów danych rośnie wraz z upływem czasu, a baza danych usługi Azure Cosmos DB dzieli partycję. Przykłady zapytań, w których może się to zdarzyć, to:

- 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

Niektóre złożone zapytania mogą zawsze wymagać dystrybucji, nawet jeśli jest przeznaczona dla pojedynczej partycji. Przykłady takich zapytań to:

- 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

Należy pamiętać, że funkcja ODE może nie zawsze pobierać plan zapytania i w związku z tym nie może uniemożliwić ani wyłączyć nieobsługiwanych zapytań. Na przykład po podzieleniu partycji takie zapytania nie kwalifikują się już do odE i dlatego nie będą uruchamiane, ponieważ ocena planu zapytania po stronie klienta zablokuje te zapytania. Aby zapewnić zgodność/ciągłość usługi, niezwykle ważne jest zapewnienie, że z odE są używane tylko zapytania, które są w pełni obsługiwane w scenariuszach bez funkcji ODE (czyli wykonują i generują prawidłowy wynik w ogólnym przypadku z wieloma partycjami).

Uwaga

Użycie funkcji ODE może potencjalnie spowodować wygenerowanie nowego typu tokenu kontynuacji. Taki token nie jest rozpoznawany przez starsze zestawy SDK zgodnie z projektem i może to spowodować źle sformułowany wyjątek tokenu kontynuacji. Jeśli masz scenariusz, w którym tokeny generowane na podstawie nowszych zestawów SDK są używane przez starszy zestaw SDK, zalecamy wykonanie 2-krokowego podejścia do uaktualnienia:

  • Uaktualnij do nowego zestawu SDK i wyłącz funkcję ODE, zarówno razem, jak i w ramach pojedynczego wdrożenia. Poczekaj na uaktualnienie wszystkich węzłów.
    • Aby wyłączyć funkcję ODE, w poleceniu QueryRequestOptions ustaw wartość False EnableOptimisticDirectExecution.
  • Włącz funkcję ODE w ramach drugiego wdrożenia dla wszystkich węzłów.

Używanie lokalnego generowania planu zapytań

Zestaw SQL SDK zawiera natywną ServiceInterop.dll do analizowania i optymalizowania zapytań lokalnie. ServiceInterop.dll jest obsługiwana tylko na platformie Windows x64 . Następujące typy aplikacji domyślnie używają przetwarzania 32-bitowego hosta. Aby zmienić przetwarzanie hosta na przetwarzanie 64-bitowe, wykonaj następujące kroki na podstawie typu aplikacji:

  • W przypadku aplikacji wykonywalnych można zmienić przetwarzanie hosta, ustawiając element docelowy platformy na x64 w oknie Właściwości projektu na karcie Kompilacja .

  • W przypadku projektów testowych opartych na programie VSTest możesz zmienić przetwarzanie hosta, wybierając pozycję Test testowy>Ustawienia> Default Architektura procesora jako X64 w menu Test programu Visual Studio.

  • W przypadku lokalnie wdrożonych ASP.NET aplikacji internetowych można zmienić przetwarzanie hostów, wybierając pozycję Użyj 64-bitowej wersji programu IIS Express dla witryn sieci Web i projektów w obszarze Narzędzia>Opcje>projektów i rozwiązań>projektów sieci Web.

  • W przypadku ASP.NET aplikacji internetowych wdrożonych na platformie Azure można zmienić przetwarzanie hostów, wybierając 64-bitową platformę w obszarze Ustawienia aplikacji w witrynie Azure Portal.

Uwaga

Domyślnie nowe projekty programu Visual Studio są ustawione na dowolne procesory CPU. Zalecamy ustawienie projektu na x64 , aby nie przełączał się na x86. Projekt ustawiony na Dowolny procesor CPU może łatwo przełączyć się na x86 , jeśli zostanie dodana zależność tylko x86.
ServiceInterop.dll musi znajdować się w folderze, z którego jest wykonywana biblioteka DLL zestawu SDK. Powinno to być problemem tylko wtedy, gdy ręcznie skopiujesz biblioteki DLL lub masz niestandardowe systemy kompilacji/wdrażania.

Używanie zapytań z jedną partycją

W przypadku zapytań przeznaczonych dla klucza partycji przez ustawienie właściwości PartitionKey w QueryRequestOptions obiekcie i nie zawierają żadnych agregacji (w tym Distinct, DCount, Group By). W tym przykładzie pole klucza partycji jest /state filtrowane według wartości Washington.

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

Opcjonalnie możesz podać klucz partycji jako część obiektu opcji żądania.

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

Uwaga

Zapytania obejmujące wiele partycji wymagają, aby zestaw SDK odwiedził wszystkie istniejące partycje w celu sprawdzenia wyników. Im więcej partycji fizycznych kontener ma, tym wolniej mogą być.

Unikaj ponownego tworzenia iteratora niepotrzebnie

Gdy wszystkie wyniki zapytania są używane przez bieżący składnik, nie musisz ponownie tworzyć iteratora z kontynuacją dla każdej strony. Zawsze preferuj opróżnianie zapytania w pełni, chyba że stronicowanie jest kontrolowane przez inny składnik wywołujący:

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

Dostrajanie stopnia równoległości

W przypadku zapytań dostosuj właściwość MaxConcurrency , QueryRequestOptions aby zidentyfikować najlepsze konfiguracje aplikacji, zwłaszcza jeśli wykonujesz zapytania obejmujące wiele partycji (bez filtru dla wartości klucza partycji). MaxConcurrency steruje maksymalną liczbą zadań równoległych, czyli maksymalną liczbę partycji do odwiedzenia równolegle. Ustawienie wartości na -1 pozwoli zestawowi SDK zdecydować o optymalnej współbieżności.

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

Załóżmy, że

  • D = Domyślna maksymalna liczba zadań równoległych (= całkowita liczba procesorów na maszynie klienckiej)
  • P = określona przez użytkownika maksymalna liczba zadań równoległych
  • N = liczba partycji, które należy odwiedzić w celu udzielenia odpowiedzi na zapytanie

Poniżej przedstawiono konsekwencje działania zapytań równoległych dla różnych wartości P.

  • (P == 0) => tryb seryjny
  • (P == 1) => Maksymalnie jedno zadanie
  • (P > 1) => Minimalne (P, N) zadania równoległe
  • (P < 1) => Minimalne (N, D) zadania równoległe

Dostrajanie rozmiaru strony

W przypadku wystawiania zapytania SQL wyniki są zwracane w sposób segmentowany, jeśli zestaw wyników jest zbyt duży.

Uwaga

Właściwość MaxItemCount nie powinna być używana tylko do stronicowania. Jej głównym zastosowaniem jest zwiększenie wydajności zapytań przez zmniejszenie maksymalnej liczby elementów zwracanych na jednej stronie.

Rozmiar strony można również ustawić przy użyciu dostępnych zestawów SDK usługi Azure Cosmos DB. Właściwość MaxItemCount w programie QueryRequestOptions umożliwia ustawienie maksymalnej liczby elementów, które mają być zwracane w operacji wyliczenia. Gdy MaxItemCount jest ustawiona wartość -1, zestaw SDK automatycznie znajdzie optymalną wartość w zależności od rozmiaru dokumentu. Na przykład:

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

Po wykonaniu zapytania wynikowe dane są wysyłane w pakiecie TCP. Jeśli określisz zbyt małą wartość parametru MaxItemCount, liczba podróży wymaganych do wysłania danych w pakiecie TCP jest wysoka, co wpływa na wydajność. Jeśli więc nie masz pewności, jaka wartość ma być ustawiona dla MaxItemCount właściwości, najlepiej ustawić ją na -1 i pozwolić zestawowi SDK wybrać wartość domyślną.

Dostrajanie rozmiaru buforu

Zapytanie równoległe jest przeznaczone do wstępnego pobierania wyników, gdy bieżąca partia wyników jest przetwarzana przez klienta. To wstępne pobieranie pomaga poprawić ogólne opóźnienie zapytania. Właściwość MaxBufferedItemCount ogranicza QueryRequestOptions liczbę wstępnie pobranych wyników. Ustaw MaxBufferedItemCount oczekiwaną liczbę zwróconych wyników (lub większą liczbę), aby umożliwić zapytaniu uzyskanie maksymalnej korzyści z pobierania wstępnego. Jeśli ustawisz tę wartość na -1, system automatycznie określi liczbę elementów do buforowania.

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

Wstępne pobieranie działa w taki sam sposób, niezależnie od stopnia równoległości, i istnieje pojedynczy bufor dla danych ze wszystkich partycji.

Następne kroki

Aby dowiedzieć się więcej o wydajności przy użyciu zestawu .NET SDK:

Zmniejsz liczbę wywołań planu zapytania

Aby wykonać zapytanie, należy skompilować plan zapytania. Ogólnie rzecz biorąc, reprezentuje żądanie sieciowe do bramy usługi Azure Cosmos DB, co zwiększa opóźnienie operacji zapytania.

Używanie buforowania planu zapytania

Plan zapytania dla zapytania o zakresie pojedynczej partycji jest buforowany na kliencie. Eliminuje to konieczność wywołania bramy w celu pobrania planu zapytania po pierwszym wywołaniu. Kluczem dla buforowanego planu zapytania jest ciąg zapytania SQL. Musisz upewnić się, że zapytanie jest sparametryzowane. Jeśli nie, wyszukiwanie pamięci podręcznej planu zapytania często będzie chybić w pamięci podręcznej, ponieważ ciąg zapytania jest mało prawdopodobne, aby był identyczny w wywołaniach. Buforowanie planu zapytań jest domyślnie włączone dla zestawu Java SDK w wersji 4.20.0 lub nowszej oraz dla zestawu Sdk usługi Spring Data usługi Azure Cosmos DB w wersji 3.13.0 lub nowszej.

Używanie sparametryzowanych zapytań o pojedynczą partycję

W przypadku zapytań sparametryzowanych, które są ograniczone do klucza partycji z parametrem setPartitionKey w CosmosQueryRequestOptions systemie i nie zawierają żadnych agregacji (w tym distinct, DCount, Group By), można uniknąć planu zapytania:

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

Uwaga

Zapytania obejmujące wiele partycji wymagają, aby zestaw SDK odwiedził wszystkie istniejące partycje w celu sprawdzenia wyników. Im więcej partycji fizycznych kontener ma, może to być potencjalnie spowolnione.

Dostrajanie stopnia równoległości

Zapytania równoległe działają równolegle, wykonując zapytania o wiele partycji. Jednak dane z pojedynczego partycjonowanego kontenera są pobierane szeregowo w odniesieniu do zapytania. Dlatego użyj polecenia setMaxDegreeOfParallelism w CosmosQueryRequestOptions poleceniu , aby ustawić wartość na liczbę posiadanych partycji. Jeśli nie znasz liczby partycji, możesz użyć setMaxDegreeOfParallelism polecenia , aby ustawić dużą liczbę, a system wybierze minimalną (liczbę partycji, dane wejściowe podane przez użytkownika) jako maksymalny stopień równoległości. Ustawienie wartości na -1 pozwoli zestawowi SDK zdecydować o optymalnej współbieżności.

Należy pamiętać, że zapytania równoległe dają najlepsze korzyści, jeśli dane są równomiernie dystrybuowane we wszystkich partycjach w odniesieniu do zapytania. Jeśli partycjonowany kontener jest partycjonowany w taki sposób, że wszystkie lub większość danych zwracanych przez zapytanie koncentruje się w kilku partycjach (jedna partycja w najgorszym przypadku), wydajność zapytania byłaby obniżona.

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

Załóżmy, że

  • D = Domyślna maksymalna liczba zadań równoległych (= całkowita liczba procesorów na maszynie klienckiej)
  • P = określona przez użytkownika maksymalna liczba zadań równoległych
  • N = liczba partycji, które należy odwiedzić w celu udzielenia odpowiedzi na zapytanie

Poniżej przedstawiono konsekwencje działania zapytań równoległych dla różnych wartości P.

  • (P == 0) => tryb seryjny
  • (P == 1) => Maksymalnie jedno zadanie
  • (P > 1) => Minimalne (P, N) zadania równoległe
  • (P == -1) => Minimalne (N, D) zadania równoległe

Dostrajanie rozmiaru strony

W przypadku wystawiania zapytania SQL wyniki są zwracane w sposób segmentowany, jeśli zestaw wyników jest zbyt duży. Domyślnie wyniki są zwracane we fragmentach 100 elementów lub 4 MB, w zależności od tego, który limit zostanie osiągnięty jako pierwszy. Zwiększenie rozmiaru strony spowoduje zmniejszenie liczby wymaganych rund i zwiększenie wydajności zapytań, które zwracają więcej niż 100 elementów. Jeśli nie masz pewności, jaka wartość ma być ustawiona, zazwyczaj dobrym wyborem jest 1000. Zużycie pamięci zwiększa się wraz ze wzrostem rozmiaru strony, więc jeśli obciążenie jest wrażliwe na pamięć, rozważ niższą wartość.

Możesz użyć parametru w pliku iterableByPage() na potrzeby interfejsu pageSize API synchronizacji i byPage() interfejsu API asynchronicznego, aby zdefiniować rozmiar strony:

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

Dostrajanie rozmiaru buforu

Zapytanie równoległe jest przeznaczone do wstępnego pobierania wyników, gdy bieżąca partia wyników jest przetwarzana przez klienta. Pobieranie wstępne pomaga w ogólnym ulepszaniu opóźnienia zapytania. setMaxBufferedItemCount w CosmosQueryRequestOptions ogranicza liczbę wstępnie pobranych wyników. Aby zmaksymalizować pobieranie wstępne, ustaw maxBufferedItemCount wartość na wyższą liczbę niż pageSize (UWAGA: może to również spowodować wysokie zużycie pamięci). Aby zminimalizować pobieranie wstępne, ustaw wartość równą maxBufferedItemCountpageSize. Jeśli ustawisz tę wartość na 0, system automatycznie określi liczbę elementów do buforowania.

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

Wstępne pobieranie działa w taki sam sposób, niezależnie od stopnia równoległości, i istnieje pojedynczy bufor dla danych ze wszystkich partycji.

Następne kroki

Aby dowiedzieć się więcej na temat wydajności przy użyciu zestawu JAVA SDK:

Zmniejsz liczbę wywołań planu zapytania

Aby wykonać zapytanie, należy skompilować plan zapytania. Ogólnie rzecz biorąc, reprezentuje żądanie sieciowe do bramy usługi Azure Cosmos DB, co zwiększa opóźnienie operacji zapytania. Istnieje sposób usunięcia tego żądania i zmniejszenia opóźnienia operacji zapytania pojedynczej partycji. W przypadku zapytań o pojedynczą partycję określ wartość klucza partycji dla elementu i przekaż ją jako argument partition_key :

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

Dostrajanie rozmiaru strony

W przypadku wystawiania zapytania SQL wyniki są zwracane w sposób segmentowany, jeśli zestaw wyników jest zbyt duży. Max_item_count umożliwia ustawienie maksymalnej liczby elementów do zwrócenia w operacji wyliczania.

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

Następne kroki

Aby dowiedzieć się więcej na temat używania zestawu SDK języka Python dla interfejsu API dla noSQL:

Zmniejsz liczbę wywołań planu zapytania

Aby wykonać zapytanie, należy skompilować plan zapytania. Ogólnie rzecz biorąc, reprezentuje żądanie sieciowe do bramy usługi Azure Cosmos DB, co zwiększa opóźnienie operacji zapytania. Istnieje sposób usunięcia tego żądania i zmniejszenia opóźnienia operacji zapytania pojedynczej partycji. W przypadku zapytań z jedną partycją można określić zakres zapytania do jednej partycji na dwa sposoby.

Używanie sparametryzowanego wyrażenia zapytania i określanie klucza partycji w instrukcji zapytania. Zapytanie jest komponowane programowo z elementem SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes':

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

Możesz też określić klucz partycji w FeedOptions pliku i przekazać go jako 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}`);
}

Dostrajanie rozmiaru strony

W przypadku wystawiania zapytania SQL wyniki są zwracane w sposób segmentowany, jeśli zestaw wyników jest zbyt duży. Parametr maxItemCount umożliwia ustawienie maksymalnej liczby elementów, które mają być zwracane w operacji wyliczania.

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

Następne kroki

Aby dowiedzieć się więcej na temat korzystania z zestawu SDK Node.js dla interfejsu API dla noSQL: