Udostępnij za pośrednictwem

Optymalizacja zaaprowizowanej przepływności w usłudze Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL MongoDB Kasandra Gremlin Stół

Oferując model aprowizowanej przepływności, usługa Azure Cosmos DB oferuje przewidywalną wydajność w dowolnej skali. Rezerwowanie lub aprowizowanie przepływności z wyprzedzeniem eliminuje "hałaśliwy wpływ sąsiada" na wydajność. Określasz dokładną ilość potrzebnej przepływności, a usługa Azure Cosmos DB gwarantuje skonfigurowaną przepływność, wspieraną przez umowę SLA.

Możesz zacząć od minimalnej przepływności wynoszącej 400 RU/s i skalować w górę do dziesiątek milionów żądań na sekundę lub nawet więcej. Każde żądanie dotyczące kontenera lub bazy danych usługi Azure Cosmos DB, takie jak żądanie odczytu, żądanie zapisu, żądanie zapytania, procedury składowane mają odpowiedni koszt odejmowany od aprowizowanej przepływności. Jeśli aprowizujesz 400 RU/s i wydasz zapytanie, które kosztuje 40 jednostek RU, możesz wydać 10 takich zapytań na sekundę. Każde żądanie wykraczające poza limit szybkości i należy ponowić próbę żądania. Jeśli używasz sterowników klienta, obsługują one logikę automatycznego ponawiania prób.

Przepływność można aprowizować dla baz danych lub kontenerów, a każda strategia może ułatwić oszczędzanie kosztów w zależności od scenariusza.

Optymalizowanie przez aprowizowanie przepływności na różnych poziomach

  • Jeśli aprowizujesz przepływność w bazie danych, wszystkie kontenery, na przykład kolekcje/tabele/grafy w tej bazie danych, mogą współdzielić przepływność na podstawie obciążenia. Przepływność zarezerwowana na poziomie bazy danych jest współdzielona nierównomiernie w zależności od obciążenia określonego zestawu kontenerów.

  • Jeśli aprowizujesz przepływność w kontenerze, gwarantowana jest przepływność dla tego kontenera, wspierana przez umowę SLA. Wybór klucza partycji logicznej ma kluczowe znaczenie dla równomiernego rozkładu obciążenia we wszystkich partycjach logicznych kontenera. Aby uzyskać więcej informacji, zobacz Artykuły dotyczące partycjonowania i skalowania w poziomie.

Poniżej przedstawiono pewne wskazówki dotyczące podejmowania decyzji o strategii aprowizowanej przepływności:

Rozważ aprowizowanie przepływności w bazie danych usługi Azure Cosmos DB (zawierającej zestaw kontenerów), jeśli:

  1. Masz kilkadziesiąt kontenerów usługi Azure Cosmos DB i chcesz współdzielić przepływność między niektórymi lub wszystkimi kontenerami.

  2. Przeprowadzasz migrację z pojedynczej dzierżawy bazy danych przeznaczonej do uruchamiania na maszynach wirtualnych hostowanych w usłudze IaaS lub lokalnie, na przykład z bazami danych NoSQL lub relacyjnymi bazami danych do usługi Azure Cosmos DB. Jeśli masz wiele kolekcji/tabel/wykresów i nie chcesz wprowadzać żadnych zmian w modelu danych. Pamiętaj, że może być konieczne naruszenie niektórych korzyści oferowanych przez usługę Azure Cosmos DB, jeśli nie aktualizujesz modelu danych podczas migracji z lokalnej bazy danych. Zaleca się, aby zawsze ponownie ocenić model danych, aby uzyskać najwięcej pod względem wydajności, a także zoptymalizować pod kątem kosztów.

  3. Chcesz wychwycić nieplanowane skoki obciążeń dzięki przepływności w puli na poziomie bazy danych, co może skutkować nieoczekiwanym wzrostem obciążenia.

  4. Zamiast ustawiać określoną przepływność dla poszczególnych kontenerów, dbasz o uzyskanie zagregowanej przepływności w zestawie kontenerów w bazie danych.

Rozważ aprowizowanie przepływności dla pojedynczego kontenera, jeśli:

  1. Masz kilka kontenerów usługi Azure Cosmos DB. Ponieważ usługa Azure Cosmos DB jest niezależna od schematu, kontener może zawierać elementy, które mają schematy heterogeniczne i nie wymagają od klientów tworzenia wielu typów kontenerów, po jednym dla każdej jednostki. Zawsze jest to opcja, aby rozważyć, czy grupowanie oddzielnych powiedzieć 10-20 kontenerów w jednym kontenerze ma sens. Przy minimalnym 400 jednostkach RU dla kontenerów łączenie wszystkich kontenerów 10–20 z jednym może być bardziej ekonomiczne.

  2. Chcesz kontrolować przepływność dla określonego kontenera i uzyskać gwarantowaną przepływność dla danego kontenera wspieranego przez umowę SLA.

Rozważ użycie hybrydowej powyższych dwóch strategii:

  1. Jak wspomniano wcześniej, usługa Azure Cosmos DB umożliwia mieszanie i dopasowywanie powyższych dwóch strategii, dzięki czemu można teraz mieć pewne kontenery w bazie danych Usługi Azure Cosmos DB, które mogą współużytkować przepływność aprowizowaną w bazie danych, a także niektóre kontenery w ramach tej samej bazy danych, które mogą mieć dedykowane ilości aprowizowanej przepływności.

  2. Powyższe strategie można zastosować, aby utworzyć konfigurację hybrydową, w której masz aprowizowaną przepływność na poziomie bazy danych, a niektóre kontenery mają dedykowaną przepływność.

Jak pokazano w poniższej tabeli, w zależności od wybranego interfejsu API można aprowizować przepływność w różnych stopniach szczegółowości.

interfejs API W przypadku udostępnionej przepływności skonfiguruj W przypadku dedykowanej przepływności skonfiguruj
Interfejs API dla noSQL baza danych Kontener
Interfejs API usługi Azure Cosmos DB dla bazy danych MongoDB baza danych Kolekcja
Interfejs API dla bazy danych Cassandra Przestrzeń kluczy Table
Interfejs API dla języka Gremlin Konto bazy danych Wykres
Interfejs API dla tabeli Konto bazy danych Table

Aprowizowanie przepływności na różnych poziomach pozwala zoptymalizować koszty na podstawie cech obciążenia. Jak wspomniano wcześniej, można programowo i w dowolnym momencie zwiększyć lub zmniejszyć aprowizowaną przepływność dla pojedynczych kontenerów lub zbiorczo w zestawie kontenerów. Elastycznie skalując przepływność w miarę zmian obciążenia, płacisz tylko za skonfigurowaną przepływność. Jeśli kontener lub zestaw kontenerów są dystrybuowane w wielu regionach, wówczas przepływność skonfigurowana w kontenerze lub zestawie kontenerów ma gwarancję udostępnienia we wszystkich regionach.

Optymalizacja w przypadku ograniczania szybkości żądań

W przypadku obciążeń, które nie są wrażliwe na opóźnienia, możesz aprowizować mniejszą przepływność i zezwolić aplikacji na ograniczanie szybkości, gdy rzeczywista przepływność przekracza aprowizowaną przepływność. Serwer z góry zakończy żądanie RequestRateTooLarge (kod stanu HTTP 429) i zwróci x-ms-retry-after-ms nagłówek wskazujący czas (w milisekundach), że użytkownik musi czekać przed ponowieniu próby żądania.

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

Logika ponawiania prób w zestawach SDK

Natywne zestawy SDK (.NET/.NET Core, Java, Node.js i Python) niejawnie przechwytują tę odpowiedź, przestrzegają nagłówka ponawiania próby określonego przez serwer i ponów próbę żądania. Jeśli twoje konto nie będzie dostępne współbieżnie przez wielu klientów, następne ponowienie próby powiedzie się.

Jeśli masz więcej niż jednego klienta skumulowanie operacyjnego powyżej szybkości żądań, domyślna liczba ponownych prób, która jest obecnie ustawiona na 9, może nie być wystarczająca. W takich przypadkach klient zgłasza RequestRateTooLargeException kod stanu 429 do aplikacji. Domyślną liczbę ponownych prób można zmienić, ustawiając wartość RetryOptions w wystąpieniu ConnectionPolicy. Domyślnie RequestRateTooLargeException kod stanu 429 jest zwracany po skumulowanym czasie oczekiwania wynoszącym 30 sekund, jeśli żądanie nadal działa powyżej 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.

Wartość MaxRetryAttemptsOnThrottledRequests jest ustawiona na 3, więc w tym przypadku, jeśli operacja żądania jest ograniczona przez przekroczenie zarezerwowanej przepływności dla kontenera, operacja żądania ponawia próbę trzy razy przed zgłoszeniem wyjątku do aplikacji. Wartość MaxRetryWaitTimeInSeconds jest ustawiona na 60, więc w tym przypadku jeśli skumulowany czas oczekiwania ponawiania prób w sekundach od pierwszego żądania przekracza 60 sekund, zgłaszany jest wyjątek.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Strategia partycjonowania i koszty przepływności aprowizowanej

Dobra strategia partycjonowania jest ważna w celu optymalizacji kosztów w usłudze Azure Cosmos DB. Upewnij się, że nie ma niesymetryczności partycji, które są widoczne za pośrednictwem metryk magazynu. Upewnij się, że nie ma niesymetryczności przepływności dla partycji, która jest uwidoczniona za pomocą metryk przepływności. Upewnij się, że nie ma niesymetryczności dla określonych kluczy partycji. Klucze dominujące w magazynie są udostępniane za pośrednictwem metryk, ale klucz jest zależny od wzorca dostępu do aplikacji. Najlepiej jest myśleć o odpowiednim kluczu partycji logicznej. Oczekuje się, że dobry klucz partycji ma następujące cechy:

  • Wybierz klucz partycji, który równomiernie rozkłada obciążenie na wszystkie partycje, a nawet w czasie. Innymi słowy, nie należy mieć kluczy do większości danych i niektórych kluczy z mniej lub bez danych.

  • Wybierz klucz partycji, który umożliwia równomierne rozłożenie wzorców dostępu na partycje logiczne. Obciążenie jest dość równomierne we wszystkich kluczach. Innymi słowy, większość obciążenia nie powinna być skoncentrowana na kilku określonych kluczach.

  • Wybierz klucz partycji, który ma szeroki zakres wartości.

Podstawowym pomysłem jest rozłożenie danych i działań w kontenerze w zestawie partycji logicznych, dzięki czemu zasoby magazynu danych i przepływności mogą być dystrybuowane między partycjami logicznymi. Kandydaci do kluczy partycji mogą zawierać właściwości, które są często wyświetlane jako filtr w zapytaniach. Zapytania mogą być efektywnie kierowane przez dołączenie klucza partycji do predykatu filtru. Dzięki takiej strategii partycjonowania optymalizacja aprowizowanej przepływności jest o wiele łatwiejsza.

Projektowanie mniejszych elementów pod kątem większej przepływności

Opłata za żądanie lub koszt przetwarzania żądań danej operacji jest bezpośrednio skorelowany z rozmiarem elementu. Operacje na dużych elementach kosztują więcej niż operacje na mniejszych elementach.

Wzorce dostępu do danych

Zawsze dobrym rozwiązaniem jest logiczne oddzielenie danych od kategorii logicznych na podstawie tego, jak często uzyskujesz dostęp do danych. Kategoryzując je jako gorące, średnie lub zimne dane, można dostosować ilość używanego magazynu i wymaganą przepływność. W zależności od częstotliwości dostępu można umieścić dane w osobnych kontenerach (na przykład tabele, grafy i kolekcje) oraz dostosować aprowizowaną przepływność, aby dostosować je do potrzeb tego segmentu danych.

Ponadto jeśli używasz usługi Azure Cosmos DB i wiesz, że nie zamierzasz wyszukiwać według określonych wartości danych lub rzadko uzyskujesz do nich dostęp, należy przechowywać skompresowane wartości tych atrybutów. Dzięki tej metodzie oszczędzasz miejsce do magazynowania, miejsce na indeksie i aprowizowaną przepływność oraz obniżasz koszty.

Optymalizowanie przez zmianę zasad indeksowania

Domyślnie usługa Azure Cosmos DB automatycznie indeksuje każdą właściwość każdego rekordu. Ma to na celu ułatwienie programowania i zapewnienie doskonałej wydajności w wielu różnych typach zapytań ad hoc. Jeśli masz duże rekordy z tysiącami właściwości, płacenie kosztu przepływności indeksowania każdej właściwości może nie być przydatne, zwłaszcza jeśli zapytanie dotyczy tylko 10 lub 20 tych właściwości. W miarę zbliżania się do obsługi określonego obciążenia nasze wskazówki dotyczą dostosowywania zasad indeksu. Szczegółowe informacje na temat zasad indeksowania usługi Azure Cosmos DB można znaleźć tutaj.

Monitorowanie aprowizowanej i zużytej przepływności

Możesz monitorować łączną liczbę aprowizowanych jednostek żądań, liczbę żądań ograniczonych szybkością oraz liczbę jednostek RU użytych w witrynie Azure Portal. Aby dowiedzieć się więcej, zobacz Analizowanie metryk usługi Azure Cosmos DB. Na poniższej ilustracji przedstawiono przykładową metryki użycia:

Monitorowanie jednostek żądań w witrynie Azure Portal

Możesz również ustawić alerty, aby sprawdzić, czy liczba żądań ograniczonych szybkością przekracza określony próg. Aby dowiedzieć się więcej o alertach, zobacz Alerty usługi Azure Monitor.

Elastyczne skalowanie przepływności i na żądanie

Ponieważ opłaty są naliczane za aprowizowaną przepływność, dopasowanie aprowizowanej przepływności do potrzeb może pomóc uniknąć opłat za nieużywaną przepływność. Możesz skalować aprowizowaną przepływność w górę lub w dół w dowolnym momencie, zgodnie z potrzebami. Jeśli potrzeby dotyczące przepływności są bardzo przewidywalne, możesz użyć usługi Azure Functions i użyć wyzwalacza czasomierza, aby zwiększyć lub zmniejszyć przepływność zgodnie z harmonogramem.

  • Monitorowanie zużycia jednostek RU i współczynnik żądań ograniczonych szybkością może ujawnić, że nie trzeba utrzymywać aprowizacji przez cały dzień lub tydzień. Możesz otrzymać mniej ruchu w nocy lub w weekend. Korzystając z witryny Azure Portal lub natywnych zestawów SDK usługi Azure Cosmos DB lub interfejsu API REST, możesz skalować aprowizowaną przepływność w dowolnym momencie. Interfejs API REST usługi Azure Cosmos DB udostępnia punkty końcowe do programowego aktualizowania poziomu wydajności kontenerów, co ułatwia dostosowanie przepływności z kodu w zależności od pory dnia lub dnia tygodnia. Operacja jest wykonywana bez żadnych przestojów i zwykle trwa krócej niż minutę.

  • Jednym z obszarów, w których należy skalować przepływność, jest pozyskiwanie danych do usługi Azure Cosmos DB, na przykład podczas migracji danych. Po zakończeniu migracji można skalować aprowizowaną przepływność w dół, aby obsłużyć stały stan rozwiązania.

  • Pamiętaj, że rozliczenia są na poziomie szczegółowości jednej godziny, więc nie oszczędzasz żadnych pieniędzy, jeśli zmienisz aprowizowaną przepływność częściej niż godzinę naraz.

Określanie przepływności wymaganej dla nowego obciążenia

Aby określić aprowizowaną przepływność dla nowego obciążenia, możesz wykonać następujące kroki:

  1. Wykonaj wstępną, przybliżoną ocenę przy użyciu planisty pojemności i dostosuj szacowania za pomocą Eksploratora usługi Azure Cosmos DB w witrynie Azure Portal.

  2. Zaleca się utworzenie kontenerów o wyższej przepływności niż oczekiwano, a następnie skalowanie w dół zgodnie z potrzebami.

  3. Zaleca się użycie jednego z natywnych zestawów SDK usługi Azure Cosmos DB, aby skorzystać z automatycznych ponownych prób w przypadku żądań z ograniczoną szybkością. Jeśli pracujesz na platformie, która nie jest obsługiwana i używasz interfejsu API REST usługi Azure Cosmos DB, zaimplementuj własne zasady ponawiania przy użyciu nagłówka x-ms-retry-after-ms .

  4. Upewnij się, że kod aplikacji bezpiecznie obsługuje przypadek, gdy wszystkie ponawianie próby nie powiedzie się.

  5. Alerty można skonfigurować w witrynie Azure Portal, aby otrzymywać powiadomienia dotyczące ograniczania szybkości. Możesz zacząć od konserwatywnych limitów, takich jak 10 żądań ograniczonych szybkością w ciągu ostatnich 15 minut i przełączyć się na bardziej chętne reguły, gdy dowiesz się, jak rzeczywiste zużycie. Okazjonalne limity szybkości są w porządku, pokazują, że grasz z limitami ustawionymi i to jest dokładnie to, co chcesz zrobić.

  6. Użyj monitorowania, aby zrozumieć wzorzec ruchu, aby rozważyć konieczność dynamicznego dostosowywania aprowizacji przepływności w ciągu dnia lub tygodnia.

  7. Regularnie monitoruj aprowizowany współczynnik przepływności w porównaniu z użyciem, aby upewnić się, że nie zainicjowano obsługi administracyjnej więcej niż wymagana liczba kontenerów i baz danych. Posiadanie nieco większej aprowizowanej przepływności jest dobrym sprawdzaniem bezpieczeństwa.

Najlepsze rozwiązania dotyczące optymalizowania aprowizowanej przepływności

Poniższe kroki ułatwiają uczynienie rozwiązań wysoce skalowalnymi i opłacalne w przypadku korzystania z usługi Azure Cosmos DB.

  1. Jeśli masz znacznie większą aprowizowaną przepływność w kontenerach i bazach danych, zapoznaj się z aprowizowaną jednostkami RU w porównaniu z użyciem jednostek RU i dostosuj obciążenia.

  2. Jedną z metod szacowania ilości zarezerwowanej przepływności wymaganej przez aplikację jest zarejestrowanie opłaty za jednostkę żądania skojarzona z uruchamianiem typowych operacji względem reprezentatywnego kontenera lub bazy danych usługi Azure Cosmos DB używanej przez aplikację, a następnie oszacowania liczby operacji przewidywanych na sekundę. Pamiętaj, aby mierzyć i uwzględniać typowe zapytania oraz ich użycie. Aby dowiedzieć się, jak programowo oszacować koszty jednostek RU zapytań lub za pomocą portalu, zobacz Optymalizowanie kosztów zapytań.

  3. Innym sposobem uzyskania operacji i ich kosztów w jednostkach RU jest włączenie dzienników usługi Azure Monitor, co zapewni podział operacji/czasu trwania i opłaty za żądanie. Usługa Azure Cosmos DB zapewnia opłatę za żądanie za każdą operację, więc każdą opłatę za operację można przechowywać z powrotem z odpowiedzi, a następnie używać do analizy.

  4. Możesz elastycznie skalować aprowizowaną przepływność w górę i w dół zgodnie z potrzebami obciążeń.

  5. Możesz dodawać i usuwać regiony skojarzone z kontem usługi Azure Cosmos DB zgodnie z potrzebami i kontrolować koszty.

  6. Upewnij się, że masz równomierną dystrybucję danych i obciążeń między partycjami logicznymi kontenerów. W przypadku nierównej dystrybucji partycji może to spowodować aprowizację wyższej przepływności niż wymagana wartość. Jeśli okaże się, że masz niesymetryczną dystrybucję, zalecamy równomierne dystrybuowanie obciążenia między partycjami lub ponowne partycjonowanie danych.

  7. Jeśli masz wiele kontenerów, a te kontenery nie wymagają umów SLA, możesz użyć oferty opartej na bazie danych w przypadkach, w których umowy SLA dla poszczególnych kontenerów przepływności nie mają zastosowania. Należy określić, które z kontenerów usługi Azure Cosmos DB chcesz migrować do oferty przepływności na poziomie bazy danych, a następnie przeprowadzić migrację przy użyciu rozwiązania opartego na zestawieniach zmian.

  8. Rozważ użycie warstwy Bezpłatna usługi Azure Cosmos DB (bezpłatna przez rok), wypróbuj usługę Azure Cosmos DB (maksymalnie trzy regiony) lub można pobrać emulator usługi Azure Cosmos DB na potrzeby scenariuszy tworzenia i testowania. Korzystając z tych opcji dla testowania deweloperskiego, możesz znacznie obniżyć koszty.

  9. Można dodatkowo wykonywać optymalizacje kosztów specyficzne dla obciążenia — na przykład zwiększenie rozmiaru partii, odczytów równoważenia obciążenia w wielu regionach i deduplikowanie danych, jeśli ma to zastosowanie.

  10. Dzięki pojemności zarezerwowanej usługi Azure Cosmos DB możesz uzyskać znaczne rabaty przez maksymalnie 65% przez trzy lata. Model pojemności zarezerwowanej usługi Azure Cosmos DB to zobowiązanie z góry dotyczące jednostek żądań potrzebnych w czasie. Rabaty są warstwowe, tak aby więcej jednostek żądań używanych w dłuższym okresie, tym więcej rabatu będzie. Rabaty te są stosowane natychmiast. Opłaty za wszystkie jednostki RU używane powyżej aprowizowanej wartości są naliczane w oparciu o koszt pojemności nieobsługiwanej. Aby uzyskać więcej informacji, zobacz Pojemność zarezerwowana usługi Azure Cosmos DB. Rozważ zakup pojemności zarezerwowanej, aby jeszcze bardziej obniżyć koszty aprowizowanej przepływności.

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: