Konwertowanie liczby rdzeni wirtualnych lub procesorów wirtualnych w nierelacyjnej bazie danych na jednostki RU/s usługi Azure Cosmos DB

DOTYCZY: NoSQL

DOTYCZY: Mongodb

W tym artykule wyjaśniono, jak oszacować jednostki żądań (RU/s) usługi Azure Cosmos DB podczas rozważania migracji danych, ale wszystko, co wiesz, to łączna liczba rdzeni wirtualnych lub procesorów wirtualnych w istniejących zestawach replik bazy danych. Podczas migracji co najmniej jednego zestawu replik do usługi Azure Cosmos DB każda kolekcja przechowywana w tych zestawach replik będzie przechowywana jako kolekcja usługi Azure Cosmos DB składająca się z klastra podzielonego na fragmenty z 4-krotnym współczynnikiem replikacji. Więcej informacji na temat naszej architektury można uzyskać w tym przewodniku dotyczącym partycjonowania i skalowania. Jednostki żądań to sposób aprowizowania pojemności przepływności w kolekcji; Aby dowiedzieć się więcej, przeczytaj przewodnik jednostki żądań i przewodnik aprowizacji jednostek RU/s. Podczas migracji kolekcji usługa Azure Cosmos DB aprowizuje wystarczającą liczbę fragmentów, aby obsługiwać aprowizowane jednostki żądań i przechowywać dane. Dlatego szacowanie jednostek RU/s dla kolekcji jest ważnym krokiem w określaniu zakresu skali planowanej jednostki danych usługi Azure Cosmos DB przed migracją. Na podstawie naszych doświadczeń z tysiącami klientów odkryliśmy, że ta formuła pomaga nam osiągnąć przybliżone oszacowanie jednostek RU/s punktu początkowego z rdzeni wirtualnych lub procesorów wirtualnych:

Provisioned RU/s = C*T/R

• T: Łączna liczba rdzeni wirtualnych i/lub procesorów wirtualnych w istniejących zestawach replik nośnych danych bazy danych.
• R: Współczynnik replikacji istniejących zestawów replik nośnych danych.
• C: Zalecana aprowizowana jednostka RU/s na rdzeń wirtualny lub procesor wirtualny. Ta wartość pochodzi z architektury usługi Azure Cosmos DB:
  • C = 600 RU/s/vCore* dla usługi Azure Cosmos DB for NoSQL
  • C = 1000 RU/s/vCore* dla usługi Azure Cosmos DB dla bazy danych MongoDB w wersji 4.0
  • Oszacowania języka C dla interfejsu API dla bazy danych Cassandra, Gremlin lub innych interfejsów API nie są obecnie dostępne

Wartości dla języka C są podane powyżej. T należy określić, sprawdzając liczbę rdzeni wirtualnych lub procesorów wirtualnych w każdym zestawie replik nośnych danych istniejącej bazy danych i sumując, aby uzyskać sumę. Jeśli nie możesz oszacować T , rozważ wykonanie naszego przewodnika w celu oszacowania jednostek RU/s przy użyciu planisty pojemności usługi Azure Cosmos DB zamiast tego przewodnika. Język T nie powinien zawierać rdzeni wirtualnych ani procesorów wirtualnych skojarzonych z serwerem routingu lub klastrem konfiguracji istniejącej bazy danych, jeśli ma te składniki.

W przypadku języka R zalecamy podłączanie średniego współczynnika replikacji zestawów replik bazy danych. Jeśli te informacje nie są dostępne , R=3 jest dobrą regułą kciuka.

Interfejsy API międzyoperacyjności usługi Azure Cosmos DB działają na podstawie interfejsu API dla noSQL i implementują własne unikatowe architektury; dlatego usługa Azure Cosmos DB dla bazy danych MongoDB w wersji 4.0 ma inną wartość C niż interfejs API usługi Azure Cosmos DB dla noSQL.

Przykład pracy: szacowanie jednostek RU/s na potrzeby migracji zestawu replik z jedną repliką

Rozważmy pojedynczy zestaw replik ze współczynnikiem replikacji R=3 opartym na czterordzeniowej jednostce SKU serwera. Następnie

• T = 12 rdzeni wirtualnych
• R = 3

Następnie zalecane jednostki żądania dla interfejsu API usługi Azure Cosmos DB dla bazy danych NoSQL są następujące:

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (12 vCores) / (3) = 2,400 RU/s

Zalecane jednostki żądań dla usługi Azure Cosmos DB dla bazy danych MongoDB to

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (12 vCores) / (3) = 4,000 RU/s

Przykład pracy: szacowanie jednostek RU/s podczas migrowania klastra homogenicznych zestawów replik

Rozważmy klaster podzielony na fragmenty i zreplikowany składający się z trzech zestawów replik z trzema zestawami replikacji, gdzie każdy serwer jest czterordzeniową jednostkę SKU. Następnie

• T = 36 rdzeni wirtualnych
• R = 3

Następnie zalecane jednostki żądania dla interfejsu API usługi Azure Cosmos DB dla bazy danych NoSQL są następujące:

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

Zalecane jednostki żądań dla usługi Azure Cosmos DB dla bazy danych MongoDB to

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

Przykład pracy: szacowanie jednostek RU/s podczas migrowania klastra zestawów replik heterogenicznych

Rozważmy klaster podzielony na fragmenty i zreplikowany składający się z trzech zestawów replik, w których każdy serwer jest oparty na czterordzeniowej jednostce SKU. Zestawy replik są "heterogeniczne" w sensie, że każdy z nich ma inny współczynnik replikacji: odpowiednio 3x, 1x i 5x. Zalecaną metodą jest użycie średniego współczynnika replikacji podczas obliczania jednostek żądania. Następnie

• T = 36 rdzeni wirtualnych
• Ravg = (3+1+5)/3 = 3

Następnie zalecane jednostki żądania dla interfejsu API usługi Azure Cosmos DB dla bazy danych NoSQL są następujące:

Provisioned RU/s, API for NoSQL = (600 RU/s/vCore) * (36 vCores) / (3) = 7,200 RU/s

Zalecane jednostki żądań dla usługi Azure Cosmos DB dla bazy danych MongoDB to

Provisioned RU/s, API for MongoDB = (1,000 RU/s/vCore) * (36 vCores) / (3) = 12,000 RU/s

Wskazówki w celu uzyskania najbardziej dokładnego oszacowania jednostek RU/s

Migrowanie z zarządzanej przez chmurę bazy danych: jeśli obecnie używasz bazy danych zarządzanej przez chmurę, te usługi często wydają się być aprowidowane w jednostkach rdzeni wirtualnych lub procesorów wirtualnych (innymi słowy T), ale w rzeczywistości liczba rdzeni aprowizowanych ustawia rdzenie wirtualne/replikę lub wartość repliki /repliki (T/R) dla zestawu repliki języka R; prawdziwa liczba rdzeni jestwiększa niż liczba aprowizowania jawnie. Zalecamy określenie, czy ten opis ma zastosowanie do bieżącej bazy danych zarządzanej przez chmurę, a jeśli tak, należy pomnożyć nominalną liczbę aprowizowanych rdzeni wirtualnych lub procesorów wirtualnych przez język R, aby uzyskać dokładne oszacowanie T.

Rdzenie wirtualne a procesory wirtualne: w tym artykule traktujemy "rdzenie wirtualne" i "procesory wirtualne" jako synonimy, w związku z czym C ma jednostki RU/s/vCore lub RU/s/vCPU bez rozróżnienia. Jednak w praktyce uproszczenie to może nie być dokładne w niektórych sytuacjach. Te terminy mogą mieć różne znaczenia; na przykład jeśli fizyczne procesory CPU obsługują hiperwątkowanie, możliwe jest, że 2 procesory wirtualne = 1 rdzeń wirtualny w/HT lub coś innego. Ogólnie rzecz biorąc, relacja procesorów wirtualnych z rdzeniami/wirtualnymi jest zależna od sprzętu i zalecamy zbadanie relacji z istniejącym sprzętem klastra oraz to, czy obliczenia klastra są aprowidowane pod względem rdzeni wirtualnych lub procesorów wirtualnych. Jeśli procesor wirtualny i rdzeń wirtualny mają różne znaczenie na sprzęcie, zalecamy traktowanie powyższych szacunków języka C jako jednostek RU/s/rdzeni wirtualnych, a w razie potrzeby przekonwertowanie T z procesorów wirtualnych na rdzeń wirtualny przy użyciu współczynnika konwersji odpowiedniego dla sprzętu.

Podsumowanie

Szacowanie jednostek RU/s z rdzeni wirtualnych lub procesorów wirtualnych wymaga zebrania informacji o łącznych procesorach wirtualnych rdzeni wirtualnych i współczynniku replikacji z istniejących zestawów/ replik bazy danych. Następnie możesz użyć znanych relacji między procesorami wirtualnymi rdzeni wirtualnych/ i przepływnością, aby oszacować jednostki żądań usługi Azure Cosmos DB (RU/s). Znalezienie tego oszacowania jednostki żądania będzie ważnym krokiem w przewidywaniu skali majątku danych usługi Azure Cosmos DB po migracji.

Poniższa tabela zawiera podsumowanie relacji między rdzeniami wirtualnymi i procesorami wirtualnymi dla interfejsu API usługi Azure Cosmos DB dla noSQL i interfejsu API dla bazy danych MongoDB w wersji 4.0:

Rdzenie wirtualne	RU/s (interfejs API dla NoSQL) (rep. factor=3)	RU/s (interfejs API dla bazy danych MongoDB w wersji 4.0) (rep. factor=3)
3	600	1000
6	1200	2000
12	2400	4000
24	4800	8000
48	9600	16000
96	19200	32000
192	38400	64000
384	76800	128000

Następne kroki

• Dowiedz się więcej o cenach usługi Azure Cosmos DB
• Dowiedz się, jak planować koszty usługi Azure Cosmos DB i zarządzać nimi
• Zaplanuj migrację do usługi Azure Cosmos DB dla bazy danych MongoDB. Ten dokument zawiera linki do różnych narzędzi migracji, których można użyć po zakończeniu planowania.