Porady dotyczące wydajności dla zestawu Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2

• Java SDK wersja 4
• Asynchroniczny zestaw Java SDK w wersji 2
• Synchronizowanie zestawu Java SDK w wersji 2
• .NET SDK wersja 3
• .NET SDK wersja 2
• Zestaw SDK dla języka Python

Ważne

Nie jest to najnowszy zestaw Java SDK dla usługi Azure Cosmos DB! Należy uaktualnić projekt do zestawu Java SDK usługi Azure Cosmos DB w wersji 4 , a następnie przeczytać przewodnik porady dotyczące wydajności zestawu Java SDK usługi Azure Cosmos DB w wersji 4. Postępuj zgodnie z instrukcjami w przewodniku Migrate to Azure Cosmos DB Java SDK v4 (Migrowanie do zestawu Java SDK usługi Azure Cosmos DB w wersji 4 ) i przewodniku Reactor vs RxJava w celu uaktualnienia.

Te porady dotyczące wydajności dotyczą tylko zestawu Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2. Aby uzyskać więcej informacji, zobacz repozytorium Maven .

Ważne

29 lutego 2024 r. zestaw Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2.x zostanie wycofany; zestaw SDK i wszystkie aplikacje korzystające z zestawu SDK będą nadal działać; Usługa Azure Cosmos DB po prostu przestanie zapewniać dalszą konserwację i obsługę tego zestawu SDK. Zalecamy wykonanie powyższych instrukcji, aby przeprowadzić migrację do zestawu Java SDK usługi Azure Cosmos DB w wersji 4.

Azure Cosmos DB to szybka i elastyczna rozproszona baza danych, która bezproblemowo skaluje się z gwarantowanym opóźnieniem i 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 wykonanie pojedynczego wywołania API. Aby dowiedzieć się więcej, zobacz jak aprowizować przepływność kontenera lub jak aprowizować przepływność bazy danych. Jednak ze względu na to, że usługa Azure Cosmos DB jest dostępna za pośrednictwem wywołań sieciowych, można dokonać optymalizacji po stronie klienta, aby osiągnąć szczytową wydajność podczas korzystania z zestawu Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2.

Jeśli więc zadajesz pytanie "Jak mogę poprawić wydajność bazy danych?", rozważ następujące opcje:

Sieć

1. Tryb połączenia: Użyj funkcji DirectHttps

   Sposób, w jaki klient nawiązuje połączenie z usługą Azure Cosmos DB, ma ważne konsekwencje dla wydajności, zwłaszcza pod względem zaobserwowanego opóźnienia po stronie klienta. Dostępne jest jedno kluczowe ustawienie konfiguracji do konfigurowania ConnectionPolicy klienta — ConnectionMode. Dostępne tryby połączenia to:

   1. Brama (wartość domyślna)

   2. DirectHttps

      Tryb bramy jest obsługiwany na wszystkich platformach zestawu SDK i jest skonfigurowanym ustawieniem domyślnym. Jeśli aplikacja działa w sieci firmowej przy restrykcyjnych ograniczeniach zapory, Brama jest najlepszym wyborem, ponieważ korzysta z standardowego portu HTTPS i pojedynczego punktu końcowego. Kompromis wydajności polega jednak na tym, że tryb bramy oznacza dodatkowy przeskok sieciowy za każdym razem, gdy dane są odczytywane lub zapisywane w usłudze Azure Cosmos DB. W związku z tym tryb DirectHttps oferuje lepszą wydajność z powodu mniejszej liczby przeskoków sieciowych.

      Zestaw Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2 używa protokołu HTTPS jako protokołu transportowego. Protokół HTTPS używa protokołu TLS do początkowego uwierzytelniania i szyfrowania ruchu. W przypadku korzystania z zestawu Java SDK synchronizacji usługi Azure Cosmos DB w wersji 2 należy otworzyć tylko port HTTPS 443.

      Parametr "ConnectionMode" jest konfigurowany podczas tworzenia instancji "DocumentClient" z parametrem "ConnectionPolicy".

   Synchronizowanie zestawu Java SDK w wersji 2 (Maven com.microsoft.azure::azure-documentdb)

   public ConnectionPolicy getConnectionPolicy() {
     ConnectionPolicy policy = new ConnectionPolicy();
     policy.setConnectionMode(ConnectionMode.DirectHttps);
     policy.setMaxPoolSize(1000);
     return policy;
   }
   
   ConnectionPolicy connectionPolicy = new ConnectionPolicy();
   DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
   

   

2. Sortowanie klientów w tym samym regionie świadczenia usługi Azure pod kątem wydajności

   Jeśli to możliwe, umieść wszystkie aplikacje wywołujące usługę Azure Cosmos DB w tym samym regionie co baza danych usługi Azure Cosmos DB. Aby uzyskać przybliżone porównanie, wywołania usługi Azure Cosmos DB w tym samym regionie są kompletne w ciągu 1–2 ms, ale opóźnienie między zachodnim i wschodnim wybrzeżem STANÓW Zjednoczonych wynosi >50 ms. To opóźnienie może się różnić z zapytania na zapytanie w zależności od trasy, którą żądanie pokonuje od klienta do granicy centrum danych platformy Azure. Najmniejsze możliwe opóźnienie jest osiągane przez zapewnienie, że aplikacja wywołująca znajduje się w tym samym regionie świadczenia usługi Azure, co aprowizowany punkt końcowy usługi Azure Cosmos DB. Aby uzyskać listę dostępnych regionów, zobacz Regiony świadczenia usługi Azure.

   

Użycie zestawu SDK

1. Instalowanie najnowszego zestawu SDK

   Zestawy SDK usługi Azure Cosmos DB są stale ulepszane, aby zapewnić najlepszą wydajność. Aby określić najnowsze ulepszenia zestawu SDK, odwiedź stronę zestawu SDK usługi Azure Cosmos DB.

2. Używanie pojedynczego klienta usługi Azure Cosmos DB przez cały okres istnienia aplikacji

   Każde wystąpienie DocumentClient jest wątkowo bezpieczne i wykonuje wydajne zarządzanie połączeniami oraz buforowanie adresów podczas pracy w Trybie Bezpośrednim. Aby umożliwić wydajne zarządzanie połączeniami i lepszą wydajność przez klasę DocumentClient, zaleca się użycie pojedynczego wystąpienia klasy DocumentClient dla elementu AppDomain przez cały okres istnienia aplikacji.

3. Zwiększ wartość MaxPoolSize na hosta podczas korzystania z trybu bramy

   Żądania usługi Azure Cosmos DB są wysyłane za pośrednictwem protokołu HTTPS/REST w przypadku korzystania z trybu bramy i podlegają domyślnemu limitowi połączenia na nazwę hosta lub adres IP. Może być konieczne ustawienie parametru MaxPoolSize na wyższą wartość (200–1000), aby biblioteka kliencka mogła korzystać z wielu równoczesnych połączeń z usługą Azure Cosmos DB. W wersji 2 Java SDK do synchronizacji w usłudze Azure Cosmos DB, wartość domyślna parametru ConnectionPolicy.getMaxPoolSize wynosi 100. Użyj setMaxPoolSize, aby zmienić wartość.

4. Dostosowanie zapytań równoległych dla zbiorów partycjonowanych

   Zestaw Java SDK synchronizacji usługi Azure Cosmos DB w wersji 1.9.0 lub nowszej obsługuje zapytania równoległe, które umożliwiają równoległe wykonywanie zapytań dotyczących kolekcji partycjonowanej. Aby uzyskać więcej informacji, zobacz przykłady kodu związane z pracą z zestawami SDK. Zapytania równoległe zostały zaprojektowane w celu zwiększenia opóźnienia zapytań i przepływności w porównaniu z ich odpowiednikami seryjnymi.

   (a) Optymalizacja setMaxDegreeOfParallelism: Zapytania równoległe działają, wykonując zapytania do wielu partycji równolegle. Jednak dane z pojedynczej kolekcji partycjonowanej są pobierane szeregowo w odniesieniu do zapytania. Dlatego należy użyć setMaxDegreeOfParallelism , aby ustawić liczbę partycji, które mają maksymalną szansę osiągnięcia najbardziej wydajnego zapytania, pod warunkiem, że wszystkie inne warunki systemowe pozostają takie same. Jeśli nie znasz liczby partycji, możesz użyć funkcji setMaxDegreeOfParallelism, aby ustawić dużą liczbę, a system wybierze minimalną (liczbę partycji, podaną przez użytkownika dane wejściowe) jako maksymalny stopień równoległoś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 kolekcja partycjonowana jest w taki sposób, że wszystkie lub większość danych zwracanych przez zapytanie koncentruje się w kilku partycjach (lub jednej partycji w najgorszym przypadku), wydajność zapytania byłaby ograniczona przez te partycje.

   (b) Ustawienia setMaxBufferedItemCount: Zapytanie równoległe jest zaprojektowane tak, aby wstępnie pobierać wyniki, podczas gdy bieżąca partia wyników jest przetwarzana przez klienta. Wstępne pobieranie pomaga w ogólnym ulepszeniu wydajności zapytania, przez zmniejszenie jego latencji. setMaxBufferedItemCount ogranicza liczbę wstępnie pobranych wyników. Ustawiając parametr setMaxBufferedItemCount na oczekiwaną liczbę zwróconych wyników (lub wyższą liczbę), dzięki temu zapytanie może uzyskać maksymalną korzyść z pobierania wstępnego.

   Wstępne pobieranie działa tak samo, niezależnie od wartości MaxDegreeOfParallelism, i istnieje jeden bufor dla danych ze wszystkich partycji.

5. Implementowanie wycofywania w interwałach getRetryAfterInMilliseconds

   Podczas testowania wydajnościowego należy zwiększyć obciążenie, dopóki nie zostanie ograniczona niewielka liczba żądań. Jeśli aplikacja kliencka zostanie ograniczona, powinna zredukować swoje działania na czas interwału ponawiania prób określonego przez serwer. Przestrzeganie odstępu gwarantuje, że spędzasz minimalną ilość czasu na oczekiwanie między próbami ponowienia. Obsługa zasad ponawiania prób jest uwzględniona w wersji 1.8.0 lub nowszej zestawu SDK języka Java synchronizacji usługi Azure Cosmos DB. Aby uzyskać więcej informacji, zobacz getRetryAfterInMilliseconds.

6. Rozszerzanie obciążenia związanego z klientami

   Jeśli testujesz na wysokich poziomach przepływności (>50 000 RU/s), aplikacja kliencka może stać się wąskim gardłem spowodowanym ograniczeniem użycia procesora CPU lub sieci. Jeśli osiągniesz ten punkt, możesz kontynuować wypychanie konta usługi Azure Cosmos DB, skalując aplikacje klienckie na wielu serwerach.

7. Używanie adresowania opartego na nazwach

   Użyj adresowania opartego na nazwach, gdzie linki mają format dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, a nie SelfLinks (_self), które mają format dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> , aby uniknąć pobierania identyfikatorów ResourceId wszystkich zasobów używanych do konstruowania łącza. Ponadto, ponieważ te zasoby są tworzone ponownie (prawdopodobnie o tej samej nazwie), buforowanie tych zasobów może nie pomóc.

8. Dostosuj rozmiar strony dla zapytań/kanałów informacyjnych, aby poprawić wydajność

   Podczas wykonywania zbiorczego odczytu dokumentów przy użyciu funkcji źródła danych odczytu (na przykład readDocuments) lub podczas 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 1 MB, w zależności od tego, który limit zostanie osiągnięty jako pierwszy.

   Aby zmniejszyć liczbę zapytań sieciowych wymaganych do pobrania wszystkich odpowiednich wyników, można zwiększyć rozmiar strony przy użyciu nagłówka żądania x-ms-max-item-count do 1000. W przypadkach, gdy trzeba wyświetlić tylko kilka wyników, na przykład jeśli interfejs użytkownika lub interfejs API aplikacji zwróci tylko 10 wyników naraz, możesz również zmniejszyć rozmiar strony do 10, aby zmniejszyć przepływność zużywaną dla operacji odczytu i zapytań.

   Rozmiar strony można również ustawić przy użyciu metody setPageSize.

Zasady indeksowania

1. Wyklucz nieużywane ścieżki z indeksowania w celu przyspieszenia operacji zapisu

   Zasady indeksowania usługi Azure Cosmos DB umożliwiają określenie ścieżek dokumentów do uwzględnienia lub wykluczenia z indeksowania przy użyciu ścieżek indeksowania (setIncludedPaths i setExcludedPaths). Użycie ścieżek indeksowania może oferować lepszą wydajność zapisu i niższy magazyn indeksów w scenariuszach, w których wzorce zapytań są znane wcześniej, ponieważ koszty indeksowania są bezpośrednio skorelowane z liczbą indeksowanych unikatowych ścieżek. Na przykład poniższy kod pokazuje, jak wykluczyć całą sekcję (poddrzewo) dokumentów z indeksowania przy użyciu symbolu wieloznakowego "*".

   Synchronizowanie zestawu Java SDK w wersji 2 (Maven com.microsoft.azure::azure-documentdb)

   Index numberIndex = Index.Range(DataType.Number);
   numberIndex.set("precision", -1);
   indexes.add(numberIndex);
   includedPath.setIndexes(indexes);
   includedPaths.add(includedPath);
   indexingPolicy.setIncludedPaths(includedPaths);
   collectionDefinition.setIndexingPolicy(indexingPolicy);
   

   Aby uzyskać więcej informacji, zobacz Zasady indeksowania usługi Azure Cosmos DB.

Throughput

1. Mierzenie i dostrajanie do niższych jednostek żądań na sekundę

   Usługa Azure Cosmos DB oferuje bogaty zestaw operacji bazodanowych, w tym zapytania relacyjne i hierarchiczne z funkcjami zdefiniowanymi przez użytkownika, procedurami przechowywanymi i wyzwalaczami — wszystkie działają na dokumentach w kolekcji bazy danych. Koszt związany z każdą z tych operacji zależy od użycia CPU, operacji wejścia/wyjścia oraz pamięci wymaganej do wykonania operacji. Zamiast myśleć o zasobach sprzętowych i zarządzaniu nimi, możesz traktować jednostkę żądania (RU) jako pojedynczą miarę dla zasobów wymaganych do wykonywania różnych operacji bazy danych i obsługi żądania aplikacji.

   Przepustowość jest przydzielana na podstawie liczby jednostek żądań ustawionych dla każdego kontenera. Konsumpcja jednostek żądania jest oceniana jako prędkość na sekundę. Aplikacje, które przekraczają przydzieloną liczbę jednostek żądań dla kontenera, są ograniczone do chwili, gdy poziom szybkości spadnie poniżej przydzielonego poziomu dla kontenera. Jeśli aplikacja wymaga wyższego poziomu przepływności, możesz zwiększyć przepływność, aprowizując dodatkowe jednostki żądań.

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

   Aby zmierzyć obciążenie dowolnej operacji (tworzenie, aktualizowanie lub usuwanie), sprawdź nagłówek x-ms-request-charge (lub równoważną właściwość RequestCharge w elemencie ResourceResponse T< lub FeedResponse><T>, aby zmierzyć liczbę jednostek żądań używanych przez te operacje.

   Synchronizowanie zestawu Java SDK w wersji 2 (Maven com.microsoft.azure::azure-documentdb)

   ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);
   
   response.getRequestCharge();
   

   Opłata za żądanie zwrócona w tym nagłówku jest ułamkiem przydzielonej przepustowości. Jeśli na przykład masz przydzieloną wartość 2000 RU/s, a poprzednie zapytanie zwróci 1000 dokumentów po 1 KB każdy, 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 Request units and the request unit calculator (Jednostki żądań i kalkulator jednostek żądania).

2. Obsługa limitowania szybkości żądań/przekroczenie limitu żądań

   Gdy klient próbuje przekroczyć zarezerwowaną przepływność dla konta, nie ma spadku wydajności na serwerze i nie ma użycia pojemności przepływności poza poziomem zarezerwowanym. Serwer zakończy w sposób prewencyjny żądanie z RequestRateTooLarge (kod stanu HTTP 429) i zwróci nagłówek x-ms-retry-after-ms wskazujący czas, jaki użytkownik musi poczekać w milisekundach, przed ponownym wysłaniem żądania.

       HTTP Status 429,
       Status Line: RequestRateTooLarge
       x-ms-retry-after-ms :100
   

   Wszystkie zestawy SDK niejawnie przechwytują tę odpowiedź, respektują nagłówek retry-after określony przez serwer i ponawiają żądanie. Jeśli twoje konto nie jest używane współbieżnie przez wielu klientów, następne ponowienie próby powiedzie się.

   Jeśli masz więcej niż jednego klienta skumulowanie działań operujących konsekwentnie powyżej tempa żądań, domyślna liczba ponownych prób jest obecnie ustawiona na 9 wewnętrznie przez klienta, może nie wystarczyć; w takim przypadku klient zgłasza wyjątek DocumentClientException z kodem stanu 429 do aplikacji. Domyślną liczbę ponownych prób można zmienić przy użyciu polecenia setRetryOptions w wystąpieniu ConnectionPolicy . Domyślnie wyjątek DocumentClientException z kodem stanu 429 jest zwracany po skumulowanym czasie oczekiwania wynoszącym 30 sekund, jeśli żądanie nadal przekracza limit szybkości żądania. Dzieje się tak nawet wtedy, gdy bieżąca liczba ponownych prób jest mniejsza niż maksymalna liczba ponownych prób, może to być wartość domyślna 9 lub wartość zdefiniowana przez użytkownika.

   Chociaż automatyczne zachowanie ponawiania prób pomaga zwiększyć odporność i użyteczność dla większości aplikacji, może to być sprzeczne podczas wykonywania testów porównawczych wydajności, zwłaszcza podczas mierzenia opóźnienia. Obserwowane przez klienta opóźnienie wzrośnie, jeśli eksperyment osiągnie ograniczenie przepustowości serwera i spowoduje, że zestaw SDK klienta ponawia próbę w trybie dyskretnym. Aby uniknąć skoków opóźnień podczas eksperymentów wydajności, zmierz zasoby zwracane przez każdą operację i upewnij się, że żądania działają poniżej zarezerwowanej przepustowości. Aby uzyskać więcej informacji, zobacz Request units (Jednostki żądań).

3. Projektowanie mniejszych dokumentów dla większej przepustowości

   Opłata za żądanie (koszt przetwarzania żądań) danej operacji jest bezpośrednio skorelowana z rozmiarem dokumentu. Operacje na dużych dokumentach kosztują więcej niż operacje dla małych dokumentów.

Dalsze kroki

Aby dowiedzieć się więcej na temat projektowania aplikacji pod kątem skalowania i wysokiej wydajności, zobacz Partycjonowanie i skalowanie w usłudze Azure Cosmos DB.