Udostępnij za pośrednictwem

Rozwiązywanie problemów z zapytaniami podczas korzystania z usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

W tym artykule przedstawiono ogólne zalecane podejście do rozwiązywania problemów z zapytaniami w usłudze Azure Cosmos DB. Chociaż nie należy brać pod uwagę kroków opisanych w tym artykule pełnej ochrony przed potencjalnymi problemami z zapytaniami, uwzględniliśmy tutaj najbardziej typowe porady dotyczące wydajności. W tym artykule należy użyć jako miejsca początkowego do rozwiązywania problemów z powolnymi lub kosztownymi zapytaniami w usłudze Azure Cosmos DB for NoSQL. Można również używać dzienników diagnostycznych do identyfikowania zapytań, które są powolne lub zużywają znaczną ilość przepływności. Jeśli używasz interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB, użyj interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB — przewodnik rozwiązywania problemów z zapytaniami

Optymalizacje zapytań w usłudze Azure Cosmos DB są szeroko kategoryzowane w następujący sposób:

  • Optymalizacje, które zmniejszają opłatę za jednostkę żądania (RU) zapytania
  • Optymalizacje, które zmniejszają opóźnienie

Jeśli zmniejszysz opłatę za jednostki RU zapytania, zwykle również zmniejszysz opóźnienie.

Ten artykuł zawiera przykłady, które można utworzyć ponownie przy użyciu zestawu danych żywienia.

Typowe problemy z zestawem SDK

Przed przeczytaniem tego przewodnika warto rozważyć typowe problemy z zestawem SDK, które nie są związane z aparatem zapytań.

  • Postępuj zgodnie z poniższymi wskazówkami dotyczącymi wydajności zestawu SDK, aby uzyskać zapytanie.
  • Czasami w zapytaniach mogą być puste strony, nawet jeśli na kolejnej stronie znajdują się wyniki. Przyczyny tego mogą być następujące:
    • Zestaw SDK może wykonywać wiele wywołań sieciowych.
    • Pobieranie dokumentów przez zapytanie może zająć dużo czasu.
  • Wszystkie zapytania mają token kontynuacji, który umożliwi kontynuowanie zapytania. Pamiętaj, aby całkowicie opróżnić zapytanie. Dowiedz się więcej o obsłudze wielu stron wyników

Pobieranie metryk zapytania

Podczas optymalizowania zapytania w usłudze Azure Cosmos DB pierwszym krokiem jest zawsze uzyskanie metryk zapytania dla zapytania. Te metryki są również dostępne w witrynie Azure Portal. Po uruchomieniu zapytania w Eksploratorze danych metryki zapytania są widoczne obok karty Wyniki :

Pobieranie metryk zapytań

Po pobraniu metryk zapytania porównaj liczbę pobranych dokumentów z liczbą dokumentów wyjściowych dla zapytania. Użyj tego porównania, aby zidentyfikować odpowiednie sekcje do przejrzenia w tym artykule.

Liczba pobranych dokumentów to liczba dokumentów wymaganych do załadowania aparatu zapytań. Liczba dokumentów wyjściowych to liczba dokumentów, które były potrzebne do wykonania wyników zapytania. Jeśli liczba pobranych dokumentów jest znacznie większa niż liczba dokumentów wyjściowych, co najmniej jedna część zapytania, która nie może użyć indeksu i musi wykonać skanowanie.

Zapoznaj się z poniższymi sekcjami, aby zrozumieć odpowiednie optymalizacje zapytań dla danego scenariusza.

Opłata za jednostkę ŻĄDANIA zapytania jest zbyt wysoka

Liczba pobranych dokumentów jest znacznie wyższa niż liczba dokumentów wyjściowych


Liczba pobranych dokumentów jest w przybliżeniu równa liczbie dokumentów wyjściowych


Opłaty za jednostki RU zapytania są akceptowalne, ale opóźnienie jest nadal zbyt wysokie

Zapytania, w których liczba pobranych dokumentów przekracza liczbę dokumentów wyjściowych

Liczba pobranych dokumentów to liczba dokumentów wymaganych do załadowania aparatu zapytań. Liczba dokumentów wyjściowych to liczba dokumentów zwracanych przez zapytanie. Jeśli liczba pobranych dokumentów jest znacznie większa niż liczba dokumentów wyjściowych, co najmniej jedna część zapytania, która nie może użyć indeksu i musi wykonać skanowanie.

Oto przykład zapytania skanowania, które nie zostało całkowicie obsłużone przez indeks:

Zapytanie:

SELECT VALUE c.description
FROM c
WHERE UPPER(c.description) = "BABYFOOD, DESSERT, FRUIT DESSERT, WITHOUT ASCORBIC ACID, JUNIOR"

Metryki zapytań:

Retrieved Document Count                 :          60,951
Retrieved Document Size                  :     399,998,938 bytes
Output Document Count                    :               7
Output Document Size                     :             510 bytes
Index Utilization                        :            0.00 %
Total Query Execution Time               :        4,500.34 milliseconds
  Query Preparation Times
    Query Compilation Time               :            0.09 milliseconds
    Logical Plan Build Time              :            0.05 milliseconds
    Physical Plan Build Time             :            0.04 milliseconds
    Query Optimization Time              :            0.01 milliseconds
  Index Lookup Time                      :            0.01 milliseconds
  Document Load Time                     :        4,177.66 milliseconds
  Runtime Execution Times
    Query Engine Times                   :          322.16 milliseconds
    System Function Execution Time       :           85.74 milliseconds
    User-defined Function Execution Time :            0.00 milliseconds
  Document Write Time                    :            0.01 milliseconds
Client Side Metrics
  Retry Count                            :               0
  Request Charge                         :        4,059.95 RUs

Liczba pobranych dokumentów (60 951) jest znacznie większa niż liczba dokumentów wyjściowych (7), co oznacza, że to zapytanie spowodowało skanowanie dokumentu. W takim przypadku funkcja systemowa UPPER() nie używa indeksu.

Uwzględnianie niezbędnych ścieżek w zasadach indeksowania

Zasady indeksowania powinny obejmować wszystkie właściwości zawarte w WHERE klauzulach, ORDER BY klauzulach, JOINi większości funkcji systemowych. Żądane ścieżki określone w zasadach indeksowania powinny być zgodne z właściwościami w dokumentach JSON.

Uwaga

Właściwości zasad indeksowania usługi Azure Cosmos DB są wrażliwe na wielkość liter

Jeśli uruchomisz następujące proste zapytanie dotyczące zestawu danych żywienia , zobaczysz znacznie niższą opłatę za jednostkę RU, gdy właściwość w WHERE klauzuli jest indeksowana:

Oryginalne

Zapytanie:

SELECT *
FROM c
WHERE c.description = "Malabar spinach, cooked"

Zasady indeksowania:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/description/*"
        }
    ]
}

Opłata za jednostki RU: 409,51 RU

Optymalizacja

Zaktualizowane zasady indeksowania:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": []
}

Opłata za jednostki RU: 2,98 RU

Właściwości można dodawać do zasad indeksowania w dowolnym momencie bez wpływu na dostępność zapisu ani odczytu. Możesz śledzić postęp transformacji indeksu.

Informacje o funkcjach systemowych korzystających z indeksu

Większość funkcji systemowych używa indeksów. Oto lista typowych funkcji ciągów korzystających z indeksów:

  • StartsWith
  • Contains
  • RegexMatch
  • Left
  • Podciąg — ale tylko wtedy, gdy pierwsza num_expr wynosi 0

Poniżej przedstawiono niektóre typowe funkcje systemowe, które nie korzystają z indeksu i muszą załadować każdy dokument, gdy jest używany w klauzuli WHERE :

Funkcja systemowa Pomysły na optymalizację
Górny/dolny Zamiast używać funkcji systemowej do normalizacji danych dla porównań, normalizuj wielkość liter po wstawieniu. Zapytanie, takie jak SELECT * FROM c WHERE UPPER(c.name) = 'BOB' , staje SELECT * FROM c WHERE c.name = 'BOB'się .
GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks Oblicz bieżący czas przed wykonaniem zapytania i użyj tej wartości ciągu w klauzuli WHERE .
Funkcje matematyczne (nie agregujące) Jeśli musisz obliczyć wartość często w zapytaniu, rozważ zapisanie wartości jako właściwości w dokumencie JSON.

Te funkcje systemowe mogą używać indeksów, z wyjątkiem sytuacji, gdy są używane w zapytaniach z agregacjami:

Funkcja systemowa Pomysły na optymalizację
Funkcje systemu przestrzennego Przechowywanie wyniku zapytania w widoku zmaterializowanym w czasie rzeczywistym

W przypadku użycia w klauzuli SELECT nieefektywne funkcje systemowe nie będą wpływać na sposób używania indeksów przez zapytania.

Ulepszanie wykonywania funkcji systemowej ciągów

W przypadku niektórych funkcji systemowych korzystających z indeksów można ulepszyć wykonywanie zapytań, dodając klauzulę ORDER BY do zapytania.

Dokładniej rzecz biorąc, każda funkcja systemowa, której opłata za jednostkę RU zwiększa się w miarę wzrostu kardynalności właściwości, może korzystać z posiadania ORDER BY w zapytaniu. Te zapytania wykonują skanowanie indeksu, dzięki czemu posortowane wyniki zapytania mogą zwiększyć wydajność zapytania.

Ta optymalizacja może poprawić wykonywanie następujących funkcji systemowych:

  • StartsWith (gdzie bez uwzględniania wielkości liter = true)
  • StringEquals (gdzie bez uwzględniania wielkości liter = true)
  • Contains
  • RegexMatch
  • EndsWith

Rozważmy na przykład poniższe zapytanie za pomocą polecenia CONTAINS. CONTAINS Użyje indeksów, ale czasami nawet po dodaniu odpowiedniego indeksu podczas uruchamiania poniższego zapytania nadal może wystąpić bardzo wysokie obciążenie jednostek RU.

Oryginalne zapytanie:

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

Możesz ulepszyć wykonywanie zapytań, dodając :ORDER BY

SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
ORDER BY c.town

Ta sama optymalizacja może pomóc w zapytaniach z dodatkowymi filtrami. W takim przypadku najlepiej również dodać właściwości z filtrami równości do klauzuli ORDER BY .

Oryginalne zapytanie:

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")

Wykonywanie zapytań można poprawić, dodając ORDER BY indeks złożony (c.name, c.town):

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
ORDER BY c.name, c.town

Informacje o tym, które zapytania zagregowane używają indeksu

W większości przypadków zagregowane funkcje systemowe w usłudze Azure Cosmos DB będą używać indeksu. Jednak w zależności od filtrów lub dodatkowych klauzul w zagregowanym zapytaniu aparat zapytań może być wymagany do załadowania dużej liczby dokumentów. Zazwyczaj aparat zapytań najpierw zastosuje filtry równości i zakresu. Po zastosowaniu tych filtrów aparat zapytań może ocenić dodatkowe filtry i uciekać się do ładowania pozostałych dokumentów w celu obliczenia agregacji, jeśli jest to konieczne.

Na przykład, biorąc pod uwagę te dwa przykładowe zapytania, zapytanie z filtrem równości i CONTAINS funkcji systemu będzie ogólnie bardziej wydajne niż zapytanie z tylko filtrem CONTAINS funkcji systemu. Wynika to z faktu, że filtr równości jest stosowany jako pierwszy i używa indeksu przed załadowaniem dokumentów do droższego CONTAINS filtru.

Zapytanie tylko z filtrem CONTAINS — wyższe opłaty za jednostki RU:

SELECT COUNT(1)
FROM c
WHERE CONTAINS(c.description, "spinach")

Zapytanie z filtrem równości i CONTAINS filtrem — niższe opłaty za jednostki RU:

SELECT AVG(c._ts)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats" AND CONTAINS(c.description, "spinach")

Oto dodatkowe przykłady zagregowanych zapytań, które nie będą w pełni korzystać z indeksu:

Zapytania z funkcjami systemowymi, które nie korzystają z indeksu

Aby sprawdzić, czy używa indeksu, należy odwołać się do strony odpowiedniej funkcji systemowej.

SELECT MAX(c._ts)
FROM c
WHERE CONTAINS(c.description, "spinach")

Agregowanie zapytań przy użyciu funkcji zdefiniowanych przez użytkownika (UDF)

SELECT AVG(c._ts)
FROM c
WHERE udf.MyUDF("Sausages and Luncheon Meats")

Zapytania z grupą WEDŁUG

Opłaty za jednostki RU dla zapytań GROUP BY wzrosną wraz ze wzrostem kardynalności właściwości w klauzuli GROUP BY . Na przykład w poniższym zapytaniu opłaty za jednostki RU zapytania wzrosną wraz ze wzrostem liczby unikatowych opisów.

Opłaty za jednostkę RU funkcji agregującej z klauzulą GROUP BY będą wyższe niż opłaty za jednostkę RU samej funkcji agregującej. W tym przykładzie aparat zapytań musi załadować każdy dokument zgodny z filtrem c.foodGroup = "Sausages and Luncheon Meats" , aby opłata za jednostkę ŻĄDANIA miała być wysoka.

SELECT COUNT(1)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats"
GROUP BY c.description

Jeśli planujesz często uruchamiać te same zagregowane zapytania, tworzenie zmaterializowanego widoku w czasie rzeczywistym przy użyciu źródła zmian usługi Azure Cosmos DB może być bardziej wydajne niż uruchamianie poszczególnych zapytań.

Optymalizowanie zapytań, które mają zarówno filtr, jak i klauzulę ORDER BY

Chociaż zapytania, które mają filtr i klauzulę ORDER BY , zwykle używają indeksu zakresu, będą bardziej wydajne, jeśli będą one obsługiwane z indeksu złożonego. Oprócz modyfikowania zasad indeksowania należy dodać wszystkie właściwości w indeksie złożonym do klauzuli ORDER BY . Ta zmiana zapytania zapewni, że będzie ono używało indeksu złożonego. Możesz zaobserwować wpływ, uruchamiając zapytanie dotyczące zestawu danych żywienia :

Oryginalne

Zapytanie:

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c._ts ASC

Zasady indeksowania:

{

        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[]
}

Opłata za jednostki RU: 44,28 jednostek RU

Optymalizacja

Zaktualizowane zapytanie (zawiera obie właściwości klauzuli ORDER BY ):

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c.foodGroup, c._ts ASC

Zaktualizowane zasady indeksowania:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
        },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
    }

Opłata za jednostki RU: 8,86 jednostek RU

Optymalizowanie wyrażeń JOIN przy użyciu podzapytania

Podzapytania wielu wartości mogą optymalizować JOIN wyrażenia, wypychając predykaty po każdym wyrażeniu select-many, a nie po wszystkich sprzężeniach krzyżowych w klauzuli WHERE .

Rozważ następujące zapytanie:

SELECT Count(1) AS Count
FROM c
JOIN t IN c.tags
JOIN n IN c.nutrients
JOIN s IN c.servings
WHERE t.name = 'infant formula' AND (n.nutritionValue > 0
AND n.nutritionValue < 10) AND s.amount > 1

Opłata za jednostkę RU: 167,62 jednostki RU

W przypadku tego zapytania indeks będzie zgodny z dowolnym dokumentem, który ma tag o nazwie infant formula, nutritionValue większej niż 0 i amount większej niż 1. Wyrażenie JOIN w tym miejscu wykona krzyżowy produkt wszystkich elementów tagów, składników odżywczych i obsługujących tablice dla każdego zgodnego dokumentu przed zastosowaniem dowolnego filtru. Klauzula WHERE będzie następnie stosować predykat filtru dla każdej <c, t, n, s> krotki.

Jeśli na przykład pasujący dokument zawiera 10 elementów w każdej z trzech tablic, zostanie ona rozwinięta do 1 x 10 x 10 x 10 (czyli 10000) krotek. Użycie podzapytania może pomóc w odfiltrowyniu sprzężonych elementów tablicy przed dołączeniem do następnego wyrażenia.

To zapytanie jest równoważne poprzedniemu, ale używa podzapytania:

SELECT Count(1) AS Count
FROM c
JOIN (SELECT VALUE t FROM t IN c.tags WHERE t.name = 'infant formula')
JOIN (SELECT VALUE n FROM n IN c.nutrients WHERE n.nutritionValue > 0 AND n.nutritionValue < 10)
JOIN (SELECT VALUE s FROM s IN c.servings WHERE s.amount > 1)

Opłata za jednostki RU: 22,17 jednostek RU

Załóżmy, że tylko jeden element w tablicy tagów jest zgodny z filtrem i że istnieje pięć elementów dla składników odżywczych i tablic obsługujących. Wyrażenia JOIN zostaną rozwinięte do 1 x 1 x 5 x 5 = 25 elementów, w przeciwieństwie do 1000 elementów w pierwszym zapytaniu.

Zapytania, w których liczba pobranych dokumentów jest równa liczbie dokumentów wyjściowych

Jeśli liczba pobranych dokumentów jest w przybliżeniu równa liczbie dokumentów wyjściowych, oznacza to, że aparat zapytań nie musiał skanować wielu niepotrzebnych dokumentów. W przypadku wielu zapytań, takich jak te, które używają słowa kluczowego TOP , liczba pobranych dokumentów może przekroczyć liczbę dokumentów wyjściowych o 1. Nie należy się tym martwić.

Minimalizowanie liczby zapytań między partycjami

Usługa Azure Cosmos DB używa partycjonowania do skalowania poszczególnych kontenerów w miarę zwiększania się zapotrzebowania na jednostkę żądania i magazyn danych. Każda partycja fizyczna ma oddzielny i niezależny indeks. Jeśli zapytanie ma filtr równości zgodny z kluczem partycji kontenera, należy sprawdzić tylko indeks odpowiedniej partycji. Ta optymalizacja zmniejsza łączną liczbę jednostek RU, których wymaga zapytanie.

Jeśli masz dużą liczbę aprowizowanych jednostek RU (ponad 30 000) lub dużą ilość przechowywanych danych (więcej niż około 100 GB), prawdopodobnie masz wystarczająco duży kontener, aby zobaczyć znaczną redukcję opłat za jednostki RU zapytań.

Jeśli na przykład utworzysz kontener z kluczem partycji foodGroup, następujące zapytania będą musiały sprawdzić tylko jedną partycję fizyczną:

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"

Zapytania, które mają IN filtr z kluczem partycji, będą sprawdzać tylko odpowiednie partycje fizyczne i nie będą "fan-out":

SELECT *
FROM c
WHERE c.foodGroup IN("Soups, Sauces, and Gravies", "Vegetables and Vegetable Products") and c.description = "Mushroom, oyster, raw"

Zapytania, które mają filtry zakresu dla klucza partycji lub które nie mają żadnych filtrów w kluczu partycji, będą musiały "fan-out" i sprawdzić indeks każdej partycji fizycznej pod kątem wyników:

SELECT *
FROM c
WHERE c.description = "Mushroom, oyster, raw"

SELECT *
FROM c
WHERE c.foodGroup > "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"

Optymalizowanie zapytań z filtrami dla wielu właściwości

Chociaż zapytania z filtrami dla wielu właściwości zwykle używają indeksu zakresu, będą bardziej wydajne, jeśli będą one obsługiwane z indeksu złożonego. W przypadku małych ilości danych ta optymalizacja nie będzie miała znaczącego wpływu. Może być jednak przydatna w przypadku dużych ilości danych. Można zoptymalizować tylko jeden filtr, który nie jest filtrem równości, na indeks złożony. Jeśli zapytanie ma wiele filtrów innych niż filtr równości, wybierz jeden z nich, który będzie używać indeksu złożonego. Pozostałe będą nadal korzystać z indeksów zakresu. Filtr bez równości musi być zdefiniowany jako ostatni w indeksie złożonym. Dowiedz się więcej o indeksach złożonych.

Oto kilka przykładów zapytań, które można zoptymalizować za pomocą indeksu złożonego:

SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts = 1575503264

SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts > 1575503264

Oto odpowiedni indeks złożony:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
                },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
}

Optymalizacje, które zmniejszają opóźnienie zapytań

W wielu przypadkach koszt w jednostkach RU może być akceptowalny, gdy opóźnienie zapytania jest nadal zbyt duże. W poniższych sekcjach przedstawiono omówienie wskazówek dotyczących zmniejszenia opóźnienia zapytań. Jeśli uruchamiasz to samo zapytanie wiele razy względem tego samego zestawu danych, zwykle koszt w jednostkach RU będzie taki sam. Jednak opóźnienie zapytań może się różnić między ich wykonaniami.

Poprawianie odległości

Zapytania uruchamiane z innego regionu niż konto usługi Azure Cosmos DB będą miały większe opóźnienie niż gdyby były uruchamiane w tym samym regionie. Jeśli na przykład uruchamiasz kod na komputerze stacjonarnym, możesz oczekiwać opóźnienia większego o co najmniej dziesiątki lub setki milisekund niż gdyby zapytanie pochodziło z maszyny wirtualnej w tym samym regionie świadczenia platformy Azure co usługa Azure Cosmos DB. Dane w usłudze Azure Cosmos DB można łatwo dystrybuować globalnie, aby zapewnić zbliżenie danych do aplikacji.

Zwiększanie aprowizowanej przepływności

W usłudze Azure Cosmos DB aprowizowana przepływność jest mierzona w jednostkach żądań (RU). Załóżmy, że masz zapytanie, które zużywa 5 jednostek RU przepływności. Jeśli na przykład aprowizujesz 1000 jednostek RU, możesz uruchomić to zapytanie 200 razy na sekundę. Jeśli podjęto próbę uruchomienia zapytania, gdy nie było wystarczającej przepływności, usługa Azure Cosmos DB zwróci błąd HTTP 429. Każdy z bieżących zestawów SDK interfejsu API dla noSQL automatycznie ponowi próbę tego zapytania po odczekaniu krótkiego czasu. Wykonywanie ograniczonych żądań trwa dłużej, więc zwiększenie aprowizowanej przepływności może skrócić opóźnienie zapytań. Łączna liczba żądań ograniczonych można obserwować w bloku Metryki w witrynie Azure Portal.

Zwiększ wartość MaxConcurrency

Zapytania równoległe działają równolegle, wykonując zapytania o wiele partycji. Jednak dane z pojedynczej kolekcji partycjonowanej są pobierane szeregowo w odniesieniu do zapytania. Dlatego jeśli ustawisz wartość MaxConcurrency na liczbę partycji, masz największe szanse na osiągnięcie najbardziej wydajnego zapytania, pod warunkiem, że wszystkie inne warunki systemowe pozostaną takie same. Jeśli nie znasz liczby partycji, możesz ustawić parametr MaxConcurrency (lub MaxDegreesOfParallelism w starszych wersjach zestawu SDK) na dużą liczbę. System wybierze minimalną (liczbę partycji, dane wejściowe podane przez użytkownika) jako maksymalny stopień równoległości.

Zwiększ wartość MaxBufferedItemCount

Zapytania są przeznaczone do wstępnego pobierania wyników, gdy bieżąca partia wyników jest przetwarzana przez klienta. Wstępne pobieranie pomaga poprawić ogólne opóźnienie zapytania. Ustawienie parametru MaxBufferedItemCount ogranicza liczbę wstępnie pobranych wyników. Jeśli ustawisz tę wartość na oczekiwaną liczbę zwróconych wyników (lub większą liczbę), zapytanie może uzyskać największą korzyść z pobierania wstępnego. Jeśli ustawisz tę wartość na -1, system automatycznie określi liczbę elementów do buforowania.

Następne kroki

Zapoznaj się z następującymi artykułami, aby uzyskać informacje na temat mierzenia jednostek RU na zapytanie, uzyskiwania statystyk wykonywania w celu dostosowania zapytań i nie tylko: