Udostępnij za pośrednictwem

Optymalizacja kosztów żądań w usłudze Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL MongoDB Kasandra Gremlin Stół

W tym artykule opisano sposób tłumaczenia żądań odczytu i zapisu na jednostki żądań oraz optymalizowanie kosztów tych żądań. Operacje odczytu obejmują odczyty punktów i zapytania. Operacje zapisu obejmują operacje wstawiania, zastępowania, usuwania i upsert elementów.

Usługa Azure Cosmos DB oferuje bogaty zestaw operacji bazy danych, które działają na elementach w kontenerze. Koszt związany z każdą z tych operacji zależy od procesora, danych We/Wy i pamięci wymaganej do wykonania danej operacji. Zamiast myśleć o zasobach sprzętowych i zarządzaniu nimi, możesz traktować jednostkę żądania jako pojedynczą miarę dla zasobów wymaganych do wykonywania różnych operacji bazy danych w celu obsługi żądania.

Mierzenie opłaty za jednostkę żądania

Ważne jest, aby zmierzyć opłatę za jednostki RU żądań, aby zrozumieć ich rzeczywisty koszt, a także ocenić skuteczność optymalizacji. Ten koszt można pobrać za pomocą witryny Azure Portal lub sprawdzić odpowiedź wysłaną z powrotem z usługi Azure Cosmos DB za pośrednictwem jednego z zestawów SDK. Aby uzyskać szczegółowe instrukcje dotyczące tego, jak to osiągnąć, zobacz Znajdowanie opłat za jednostkę żądania w usłudze Azure Cosmos DB .

Odczytywanie danych: odczyty punktów i zapytania

Operacje odczytu w usłudze Azure Cosmos DB są zwykle uporządkowane od najszybszych/najbardziej wydajnych do wolniejszych/mniej wydajnych pod względem zużycia jednostek RU w następujący sposób:

  • Odczyty punktów (wyszukiwanie klucza/wartości dla pojedynczego identyfikatora elementu i klucza partycji).
  • Wykonywanie zapytań za pomocą klauzuli filtru w ramach pojedynczego klucza partycji.
  • Kwerenda bez klauzuli filtrowania równości lub zakresu dla dowolnej właściwości.
  • Wykonywanie zapytań bez filtrów.

Rola poziomu spójności

W przypadku używania silnych lub powiązanych poziomów spójności nieaktualności koszt jednostek ŻĄDANIA dowolnej operacji odczytu (odczyt punktu lub zapytania) jest dwukrotny.

Odczyty punktów

Jedynym czynnikiem wpływającym na obciążenie jednostek RU odczytu punktu (oprócz używanego poziomu spójności) jest rozmiar pobranego elementu. W poniższej tabeli przedstawiono koszt jednostek żądania odczytu punktów dla elementów o rozmiarze 1 KB i 100 KB.

Rozmiar elementu Koszt odczytu jednego punktu
1 KB 1 RU
100 KB 10 jednostek RU

Ponieważ odczyty punktów (odnośniki klucz/wartość w identyfikatorze elementu i kluczu partycji) są najbardziej wydajnym rodzajem odczytu, upewnij się, że identyfikator elementu ma znaczącą wartość, aby można było pobrać elementy z odczytem punktu (zamiast zapytania), gdy jest to możliwe.

Uwaga

W interfejsie API dla NoSQL odczyty punktów można wykonywać tylko przy użyciu interfejsu API REST lub zestawów SDK. Zapytania filtrujące identyfikator i klucz partycji jednego elementu nie są traktowane jako odczyt punktu. Aby zobaczyć przykład przy użyciu zestawu SDK platformy .NET, zobacz artykuł w usłudze Azure Cosmos DB for NoSQL.

Zapytania

Jednostki żądań dla zapytań zależą od wielu czynników. Na przykład liczba załadowanych/zwróconych elementów usługi Azure Cosmos DB, liczba wyszukiwań względem indeksu, czas kompilacji zapytania itp. Usługa Azure Cosmos DB gwarantuje, że to samo zapytanie wykonywane na tych samych danych zawsze będzie zużywać tę samą liczbę jednostek żądania, nawet przy powtarzanych wykonaniach. Profil zapytania używający metryk wykonywania zapytania zapewnia dobry pomysł na wykorzystanie jednostek żądania.

W niektórych przypadkach może zostać wyświetlona sekwencja odpowiedzi 200 i 429 oraz zmienne jednostki żądań w stronicowanym wykonaniu zapytań, ponieważ zapytania będą uruchamiane tak szybko, jak to możliwe na podstawie dostępnych jednostek RU. Może zostać wyświetlony podział wykonywania zapytania na wiele stron/rund między serwerem a klientem. Na przykład 10 000 elementów może zostać zwróconych jako wiele stron, z których każda jest obciążana na podstawie obliczeń wykonanych dla tej strony. Podczas sumowania na tych stronach należy uzyskać taką samą liczbę jednostek RU, jak w przypadku całego zapytania.

Metryki dotyczące rozwiązywania problemów z zapytaniami

Wydajność i przepływność zużywana przez zapytania (w tym funkcje zdefiniowane przez użytkownika) w większości zależą od treści funkcji. Najprostszym sposobem, aby dowiedzieć się, ile czasu jest poświęcane na wykonywanie zapytań w funkcji zdefiniowanej przez użytkownika i liczbę użytych jednostek RU, jest włączenie metryk zapytania. Jeśli używasz zestawu .NET SDK, oto przykładowe metryki zapytań zwracane przez zestaw SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Najlepsze rozwiązania dotyczące optymalizacji kosztów zapytań

Podczas optymalizowania zapytań pod kątem kosztów należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Kolokowanie wielu typów jednostek

    Spróbuj przenieść wiele typów jednostek w ramach jednej lub mniejszej liczby kontenerów. Ta metoda daje korzyści nie tylko z perspektywy cen, ale także dla wykonywania zapytań i transakcji. Zapytania są ograniczone do jednego kontenera; transakcje niepodzielne w wielu rekordach za pośrednictwem procedur składowanych/wyzwalaczy są ograniczone do klucza partycji w ramach jednego kontenera. Kolokowanie jednostek w tym samym kontenerze może zmniejszyć liczbę rund sieciowych, aby rozwiązać relacje między rekordami. Zwiększa więc kompleksową wydajność, umożliwia niepodzielne transakcje na wielu rekordach dla większego zestawu danych i w rezultacie obniża koszty. Jeśli przeniesienie wielu typów jednostek w ramach jednej lub mniejszej liczby kontenerów jest trudne w danym scenariuszu, zwykle dlatego, że migrujesz istniejącą aplikację i nie chcesz wprowadzać żadnych zmian w kodzie — należy rozważyć aprowizowanie przepływności na poziomie bazy danych.

  • Mierzenie i dostrajanie do niższych jednostek żądania/drugiego użycia

    Złożoność zapytania ma wpływ na liczbę jednostek żądania (RU) używanych na potrzeby operacji. Liczba predykatów, charakter predykatów, liczba funkcji zdefiniowanych przez użytkownika i rozmiar zestawu danych źródłowych. Wszystkie te czynniki wpływają na koszt operacji zapytań.

Usługa Azure Cosmos DB zapewnia przewidywalną wydajność pod względem przepływności i opóźnień przy użyciu modelu aprowizowanej przepływności. Aprowizowana przepływność jest reprezentowana pod względem jednostek żądań na sekundę lub jednostek RU/s. Jednostka żądania (RU) to logiczna abstrakcja zasobów obliczeniowych, takich jak procesor CPU, pamięć, operacje we/wy itp., które są wymagane do wykonania żądania. Aprowizowana przepływność (RU) jest przeznaczona dla kontenera lub bazy danych w celu zapewnienia przewidywalnej przepływności i opóźnień. Aprowizowana przepływność umożliwia usłudze Azure Cosmos DB zapewnienie przewidywalnej i spójnej wydajności, gwarantowanego małego opóźnienia i wysokiej dostępności w dowolnej skali. Jednostki żądań reprezentują znormalizowaną walutę, która upraszcza wnioskowanie o tylu zasobach, których potrzebuje aplikacja.

Opłata za żądanie zwrócona w nagłówku żądania wskazuje koszt danego zapytania. Jeśli na przykład zapytanie zwraca 1000 1 KB elementów, koszt operacji wynosi 1000. W związku z tym w ciągu jednej sekundy serwer honoruje tylko dwa takie żądania przed ograniczeniem liczby kolejnych żądań. Aby uzyskać więcej informacji, zobacz artykuł jednostki żądania i kalkulator jednostki żądania.

Zapisywanie danych

Koszt jednostki RU pisania elementu zależy od:

  • Rozmiar elementu.
  • Liczba właściwości objętych zasadami indeksowania i wymagana do indeksowania.

Wstawianie elementu o rozmiarze 1 KB bez indeksowania kosztów około ok. 5,5 jednostek RU. Zamiana elementu kosztuje dwa razy opłaty wymagane do wstawienia tego samego elementu.

Optymalizowanie zapisów

Najlepszym sposobem optymalizacji kosztów operacji zapisu jednostek RU jest odpowiednie ustawianie rozmiaru elementów i liczby właściwości, które są indeksowane.

  • Przechowywanie bardzo dużych elementów w usłudze Azure Cosmos DB powoduje wysokie opłaty za jednostki RU i może być uważane za antywzór. W szczególności nie należy przechowywać zawartości binarnej ani dużych fragmentów tekstu, na których nie trzeba wykonywać zapytań. Najlepszym rozwiązaniem jest umieszczenie tego rodzaju danych w usłudze Azure Blob Storage i zapisanie odwołania (lub linku) do obiektu blob w elemencie zapisywanym w usłudze Azure Cosmos DB.
  • Optymalizacja zasad indeksowania w celu indeksowania tylko właściwości filtru zapytań może mieć ogromną różnicę w jednostkach RU używanych przez operacje zapisu. Podczas tworzenia nowego kontenera domyślne indeksowanie zasad indeksowania każdego i każdej właściwości znalezionej w elementach. Chociaż jest to dobre ustawienie domyślne dla działań programistycznych, zdecydowanie zaleca się ponowne ocenianie i dostosowywanie zasad indeksowania podczas przechodzenia do środowiska produkcyjnego lub gdy obciążenie zaczyna odbierać znaczący ruch.

Podczas zbiorczego pozyskiwania danych zaleca się również użycie biblioteki funkcji wykonawczej zbiorczej usługi Azure Cosmos DB, ponieważ jest ona przeznaczona do optymalizacji zużycia jednostek RU takich operacji. Opcjonalnie możesz również użyć usługi Azure Data Factory , która jest oparta na tej samej bibliotece.

Następne kroki

Następnie możesz dowiedzieć się więcej na temat optymalizacji kosztów w usłudze Azure Cosmos DB, wykonując następujące artykuły: