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

  • Artykuł

DOTYCZY: Nosql Mongodb Cassandra Gremlin Tabeli

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ą potrzebną przepływność, a usługa Azure Cosmos DB gwarantuje skonfigurowaną przepływność popartą umową SLA.

Możesz rozpocząć 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 odliczany od aprowizowanej przepływności. Jeśli aprowizujesz 400 RU/s i wydasz zapytanie, które kosztuje 40 jednostek RU, będzie można wydać 10 takich zapytań na sekundę. Każde żądanie wykraczające poza to zostanie ograniczone 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, wspierane 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 niektóre wskazówki dotyczące 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żawczej 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. A 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 dokonać oceny modelu 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ń ze względu na przepływność w puli na poziomie bazy danych, co może być spowodowane nieoczekiwanym wzrostem obciążenia.

  4. Zamiast ustawiać określoną przepływność dla poszczególnych kontenerów, zależy ci na uzyskaniu 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 kontenerów powiedzmy 10-20 w jednym kontenerze ma sens. Co najmniej 400 jednostek RU dla kontenerów, łączenie wszystkich kontenerów 10–20 z jednym może być bardziej opłacalne.

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

Rozważ połączenie 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 tej samej bazie danych, które mogą mieć dedykowane ilości aprowizowanej przepływności.

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

Jak pokazano w poniższej tabeli, w zależności od wyboru 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 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, przepływność skonfigurowana w kontenerze lub zestaw 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żna aprowizować mniejszą przepływność i pozwolić aplikacji na ograniczanie szybkości, gdy rzeczywista przepływność przekracza aprowizowaną przepływność. Serwer z wyprzedzeniem zakończy żądanie RequestRateTooLarge (kod stanu HTTP 429) i zwróci x-ms-retry-after-ms nagłówek wskazujący czas (w milisekundach), który 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ą określonego przez serwer nagłówka ponawiania próby i ponów próbę żądania. Jeśli twoje konto nie będzie jednocześnie uzyskiwane przez wielu klientów, następne ponowienie próby powiedzie się.

Jeśli masz więcej niż jednego klienta skumulowanie operacyjnego stale 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 właściwość RetryOptions w wystąpieniu ConnectionPolicy. Domyślnie kod stanu 429 jest zwracany po skumulowanym czasie oczekiwania wynoszącym 30 sekund, RequestRateTooLargeException 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.

Parametr MaxRetryAttemptsOnThrottledRequests jest ustawiony 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. Parametr MaxRetryWaitTimeInSeconds ma wartość 60, więc w tym przypadku, jeśli łączny 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 aprowizowana przepływność

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 w kierunku określonych kluczy partycji. Klucze dominujące w magazynie są uwidaczniane za pośrednictwem metryk, ale klucz będzie 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 rozkłada obciążenie równomiernie na wszystkie partycje, a nawet w czasie. Innymi słowy, nie należy mieć niektórych kluczy do większości danych i niektórych kluczy z mniejszymi lub żadnymi danymi.

  • Wybierz klucz partycji, który umożliwia równomierne rozłożenie wzorców dostępu między partycjami logicznymi. Obciążenie jest rozsądnie nawet 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 będzie znacznie łatwiejsza.

Projektowanie mniejszych elementów pod kątem wyższej przepływności

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

Wzorce dostępu do danych

Zawsze dobrym rozwiązaniem jest logiczne rozdzielenie danych na kategorie logiczne w zależności od tego, jak często uzyskujesz dostęp do danych. Kategoryzując je jako gorące, średnie lub zimne dane, można dostosować ilość zużytego magazynu i wymaganą przepływność. W zależności od częstotliwości dostępu można umieścić dane w oddzielnych kontenerach (na przykład w tabelach, grafach i kolekcjach) oraz dostosować aprowizowaną przepływność 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 można zaoszczędzić miejsce do magazynowania, miejsce na indeksie i aprowizowaną przepływność oraz obniżyć 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 za indeksowanie 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ę aprowizowania jednostek RU, liczbę żądań ograniczonych szybkością, a także liczbę jednostek RU użytych w Azure Portal. Na poniższej ilustracji przedstawiono przykładową metryki użycia:

Monitorowanie jednostek żądań w Azure Portal

Możesz również ustawić alerty, aby sprawdzić, czy liczba żądań ograniczonych szybkości przekracza określony próg. Aby uzyskać więcej informacji, zobacz artykuł Jak monitorować usługę Azure Cosmos DB . Te alerty mogą wysyłać wiadomość e-mail do administratorów konta lub wywoływać niestandardowy element webhook HTTP lub funkcję platformy Azure, aby automatycznie zwiększyć aprowizowaną przepływność.

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

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 wymagania dotyczące przepływności są bardzo przewidywalne, możesz użyć 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ń. W nocy lub w weekend możesz otrzymywać mniej ruchu. Korzystając z 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 zaoszczędzisz pieniędzy, jeśli aprowizowana przepływność zostanie zmieniona częściej niż jedna godzina 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. Przeprowadź wstępną, przybliżoną ocenę przy użyciu planisty wydajności i dostosuj szacowania za pomocą Eksploratora usługi Azure Cosmos DB w 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ób nie powiedzie się.

  5. Alerty z Azure Portal można skonfigurować, 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 przejść do bardziej chętnych reguł po zorientowaniu się rzeczywistego zużycia. Okazjonalne limity szybkości są w porządku, pokazują, że grasz z ustawionymi limitami 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 aprowizowaną a używaną przepływność, aby upewnić się, że nie aprowizowaliśmy więcej niż wymagana liczba kontenerów i baz danych. Posiadanie nieco większej aprowizowanej przepływności jest dobrym rozwiązaniem w zakresie 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, przejrzyj aprowizowane jednostki RU aużytkowane jednostki 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 oszacowanie liczby operacji, które przewidujesz do wykonania w każdej sekundzie. Pamiętaj, aby zmierzyć i uwzględnić typowe zapytania oraz ich użycie. Aby dowiedzieć się, jak programowo oszacować koszty jednostek RU zapytań lub przy użyciu portalu, zobacz Optymalizowanie kosztów zapytań.

  3. Innym sposobem na uzyskanie 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 żądania dla każdej operacji, więc każda opłata za operację może być przechowywana z powrotem z odpowiedzi, a następnie używana do analizy.

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

  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ównomierny rozkład danych i obciążeń między partycjami logicznymi kontenerów. Jeśli masz nierównomierną dystrybucję 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 dotyczące przepływności kontenera nie mają zastosowania. Należy zidentyfikować kontenery usługi Azure Cosmos DB, które mają zostać zmigrowane do oferty przepływności na poziomie bazy danych, a następnie przeprowadzić ich 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 jeden rok), wypróbuj usługę Azure Cosmos DB (maksymalnie trzy regiony) lub pobierz emulator usługi Azure Cosmos DB na potrzeby scenariuszy tworzenia i testowania. Korzystając z tych opcji do tworzenia testów, 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, równoważenie obciążenia odczytów 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żyte powyżej zaaprowizowanych wartości są naliczane w oparciu o koszt pojemności nieuwzwiązanej z rezerwą. 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: