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

  • Dotyczy: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

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 przydzielisz 400 RU/s i wykonasz zapytanie, które kosztuje 40 RU, będziesz mógł wykonać 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 przydzielać dla baz danych lub kontenerów, a każda strategia, w zależności od scenariusza, może pomóc w obniżeniu kosztów.

Optymalizacja przez przydzielanie przepustowoś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 zapewniasz przepustowość kontenerowi, przepustowość jest gwarantowana dla tego kontenera, poparta przez SLA. Wybór klucza partycji logicznej ma kluczowe znaczenie dla równomiernego rozkładu obciążenia we wszystkich partycjach logicznych kontenera. Zobacz artykuł Partycjonowanie i artykuł Skalowanie poziome po więcej szczegółów.

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

Rozważ udostępnienie przepustowoś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 bazy danych jednolokatorskiej zaprojektowanej do działania na maszynach wirtualnych w usłudze IaaS lub lokalnie, na przykład z baz danych NoSQL lub relacyjnych, do 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 złagodzić nieplanowane skoki obciążeń dzięki połączonej przepustowości na poziomie bazy danych, kiedy występuje niespodziewany wzrost 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ż skonfigurowanie 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. Warto rozważyć, czy grupowanie odrębnych, na przykład 10-20 kontenerów, w jeden kontener ma sens. Przy minimalnej liczbie 400 jednostek RU dla kontenerów, połączenie wszystkich 10-20 kontenerów w jeden 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.

API W przypadku udostępnionej przepływności skonfiguruj W przypadku dedykowanej przepływności skonfiguruj
Interfejs API dla noSQL Database Pojemnik
Interfejs API usługi Azure Cosmos DB dla bazy danych MongoDB Database Kolekcja
Interfejs API dla bazy danych Cassandra Przestrzeń kluczy Tabela
Interfejs API dla języka Gremlin Konto bazy danych Graph
Interfejs API dla tabeli Konto bazy danych Tabela

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.

Optymalizuj żądania za pomocą ograniczania szybkości

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 przedwcześnie zakończy żądanie RequestRateTooLarge (kod stanu HTTP 429) i zwróci nagłówek x-ms-retry-after-ms, wskazujący czas w milisekundach, który użytkownik musi odczekać przed ponowieniem 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 „retry-after” określonego przez serwer i ponawiają żądanie. 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 działających łącznie systematycznie powyżej limitu 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 wyrzuca RequestRateTooLargeException z kodem stanu 429 w 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 przekracza przepustowość żądań. 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.

Parametr MaxRetryAttemptsOnThrottledRequests jest ustawiony na 3, więc w tym przypadku, jeśli operacja żądania jest ograniczona przez przekroczenie określonej przepustowości zarezerwowanej dla kontenera, operacja żądania jest ponawiana 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 przekrzywienia partycji, które są widoczne za pośrednictwem metryk danych. 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 systemie przechowywania są udostępniane za pośrednictwem metryk, ale zależą od wzorca dostępu w 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 oraz równomiernie w czasie. Innymi słowy, nie powinno się mieć kluczy do większości danych oraz kluczy z mniejszą ilością danych 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 klawiszach. 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ę uzyskiwania lepszego zrozumienia swojego konkretnego obciążenia sugerujemy dostosowanie polityki indeksacji. 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ę przydzielonych jednostek zapytań (RU), liczbę żądań ograniczanych przez szybkość oraz liczbę wykorzystanych jednostek RU w portalu Azure. 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 portalu Azure

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 stosunku żądań ograniczonych przez szybkość może ujawnić, że nie trzeba utrzymywać stałego poziomu aprowizacji przez cały dzień lub tydzień. Możesz otrzymać mniej ruchu w nocy lub w weekend. Korzystając z portalu Azure lub natywnych zestawów SDK usługi Azure Cosmos DB albo interfejsu API REST, możesz skalować przepływność aprowizowaną 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 zmniejszyć aprowizowaną przepływność, 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ń podlegających ograniczeniom przepustowości. Jeśli pracujesz na platformie, która nie jest obsługiwana i używasz interfejsu API REST dla Azure Cosmos DB, zaimplementuj własną politykę ponawiania przy użyciu nagłówka x-ms-retry-after-ms.

  4. Upewnij się, że kod aplikacji starannie obsługuje przypadek, gdy wszystkie ponowienia prób się nie powiodą.

  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ń z limitem tempa w ciągu ostatnich 15 minut i przełączyć się na bardziej elastyczne reguły, gdy zrozumiesz swoje 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 i rozważyć potrzebę dynamicznego dostosowywania przydziału przepływności w ciągu dnia lub tygodnia.

  7. Regularnie monitoruj współczynnik aprowizowanej do zużytej przepustowości, aby upewnić się, że nie przydzieliłeś więcej kontenerów i baz danych, niż jest to potrzebne. Posiadanie nieco większej przydzielonej przepływności jest dobrym zabezpieczeniem.

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 nadmierną aprowizowaną przepustowość w kontenerach i bazach danych, przejrzyj aprowizowane RU w porównaniu z używanymi RU i dopracuj obciążenia.

  2. Jedną z metod szacowania ilości zarezerwowanej przepływności wymaganej przez aplikację jest zarejestrowanie opłaty za jednostkę żądania skojarzoną z uruchamianiem typowych operacji względem reprezentatywnego kontenera lub bazy danych usługi Azure Cosmos DB używanej przez aplikację, a następnie oszacować liczbę operacji przewidywanych na sekundę. Pamiętaj, aby mierzyć i uwzględniać typowe zapytania oraz ich użycie. Aby dowiedzieć się, jak oszacować koszty RU zapytań programowo 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 dla każdej operacji, dzięki czemu każdą opłatę można zapisać z odpowiedzi i 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ę większej przepustowości niż to, co jest potrzebne. 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 zarezerwowanej pojemności usługi Azure Cosmos DB możesz uzyskać znaczne rabaty sięgające 65% na okres trzech lat. Model pojemności zarezerwowanej usługi Azure Cosmos DB jest wcześniejszym zobowiązaniem dotyczącym jednostek żądań potrzebnych przez określony czas. Rabaty są gradacyjne, im więcej jednostek żądań używasz w dłuższym okresie, tym większy będzie Twój rabat. Rabaty te są stosowane natychmiast. Opłaty za wszystkie jednostki RU używane powyżej aprowizowanej wartości są naliczane na podstawie kosztu nieprzydzielonej pojemności. 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, zapoznając się z następującymi artykułami:

  • Last updated on