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

  • Artykuł

DOTYCZY: Nosql Mongodb Cassandra Gremlin Tabeli

W tym artykule opisano sposób tłumaczenia żądań odczytu i zapisu na jednostki żądań oraz sposób optymalizacji kosztów tych żądań. Operacje odczytu obejmują odczyty punktów i zapytania. Operacje zapisu obejmują wstawianie, zastępowanie, usuwanie i operacje 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ądzać nimi, można traktować jednostkę żądania (RU) jako pojedynczą miarę dla zasobów wymaganych do wykonywania różnych operacji bazy danych w celu obsłużenia żądania.

Mierzenie opłaty za jednostki RU żą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ć przy użyciu Azure Portal lub sprawdzić odpowiedź wysłaną z usługi Azure Cosmos DB za pomocą 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.
  • Wykonywanie zapytań 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 poziomów spójności silnej lub powiązanej nieaktualności koszt jednostek ŻĄDANIA dowolnej operacji odczytu (odczyt punktu lub zapytania) jest dwukrotnie wyższy.

Odczyty punktów

Jedynym czynnikiem wpływającym na opłatę za jednostkę RU odczytanego punktu (oprócz użytego 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 jednego punktu odczytu
1 KB 1 RU
100 KB 10 jednostek RU

Ponieważ odczyty punktów (wyszukiwania klucz/wartość w identyfikatorze elementu i kluczu partycji) są najbardziej efektywnym 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 .NET SDK, zobacz odczytywanie elementu w usłudze Azure Cosmos DB dla NoSQL.

Zapytania

Jednostki żądań dla zapytań są zależne 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. Szczegóły. Usługa Azure Cosmos DB gwarantuje, że to samo zapytanie wykonywane na tych samych danych zawsze będzie używać tej samej liczby jednostek żądania, nawet w przypadku powtarzanych wykonań. Profil zapytania korzystający z metryk wykonywania zapytania daje dobry pomysł na to, jak są wydawane jednostki żądań.

W niektórych przypadkach może być widoczna sekwencja odpowiedzi 200 i 429, a zmienne jednostki żądań w stronicowanym wykonywaniu zapytań, jest to spowodowane tym, że 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. Każda opłata jest naliczana 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) zależą głównie od treści funkcji. Najprostszym sposobem, aby dowiedzieć się, ile czasu jest poświęcane na wykonanie zapytania w funkcji zdefiniowanej przez użytkownika i liczbę wykorzystanych jednostek RU, jest włączenie metryk zapytania. Jeśli używasz zestawu SDK platformy .NET, poniżej przedstawiono 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 kolokować 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, a w rezultacie obniża koszty. Jeśli kolokowanie 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ć aprowizację przepływności na poziomie bazy danych.

  • Mierzenie i dostrajanie mniejszej liczby jednostek żądań/sekundy

    Złożoność zapytania ma wpływ na liczbę jednostek żądania (RU) używanych dla 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 uznaje tylko dwa takie żądania przed ograniczeniem liczby kolejnych żądań. Aby uzyskać więcej informacji, zobacz artykuł jednostki żądania i kalkulator jednostek żądania.

Zapisywanie danych

Koszt jednostki RU pisania elementu zależy od:

Wstawianie elementu o rozmiarze 1 KB bez indeksowania kosztów około ok. 5,5 jednostek RU. Zastąpienie elementu kosztuje dwa razy opłatę wymaganą 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żna je traktować jako antywzór. W szczególności nie należy przechowywać zawartości binarnej ani dużych fragmentów tekstu, dla których nie trzeba wykonywać zapytań. Najlepszym rozwiązaniem jest umieszczenie tego rodzaju danych w 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 filtrowanych przez zapytania 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 operacji zbiorczych usługi Azure Cosmos DB , ponieważ jest ona przeznaczona do optymalizacji zużycia jednostek RU takich operacji. Opcjonalnie możesz również użyć 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: