Udostępnij za pośrednictwem


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ą

Migrowanie zestawu replik z 3 replikami czterordzeniowej jednostki SKU do usługi Azure Cosmos DB

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

Migrowanie homogenicznego zestawu replik podzielonych na fragmenty z 3 fragmentami, z których każda ma trzy repliki czterordzeniowej jednostki SKU, do usługi Azure Cosmos DB

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

Migrowanie heterogenicznej repliki podzielonej na fragmenty z 3 fragmentami, z których każda ma różne liczby replik czterordzeniowej jednostki SKU, do usługi Azure Cosmos DB

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

Porady dotyczące uzyskiwania 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 jest wię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