Fragmentowanie pod kątem skalowalności poziomej w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB
Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB obsługują fragmentowanie w celu poziomego dystrybuowania danych i ruchu. Dokumenty w kolekcji są podzielone na fragmenty nazywane fragmentami logicznymi.
Fragmentowanie jest definiowane indywidualnie dla każdej kolekcji przy użyciu wyznaczonego klucza fragmentu ze struktury dokumentu kolekcji. Dane są następnie dzielone na fragmenty z każdym fragmentem odpowiadającym partycji logicznej. Dokumenty dla każdej unikatowej wartości właściwości klucza fragmentu znajdują się w tym samym logicznym fragmentie.
Dla każdego dokumentu wstawionego do kolekcji podzielonej na fragmenty wartość właściwości klucza fragmentu jest skrótem w celu obliczenia wyznaczonego fragmentu logicznego. Przy użyciu umieszczania logicznego fragmentu i dystrybucji wszystkich fragmentów logicznych w klastrze są abstrahowane od użytkownika i w pełni zarządzane przez usługę.
Fragmenty logiczne
Wszystkie dokumenty zawierające tę samą wartość klucza fragmentu należą do tego samego fragmentu logicznego.
Rozważmy na przykład kolekcję o nazwie Employees z poniższą strukturą dokumentu.
W tej tabeli przedstawiono mapowanie wartości klucza fragmentu na partycje logiczne.
| Identyfikator dokumentu | Wartość klucza fragmentu | Fragment logiczny |
|---|---|---|
| "12345" | "Steve Smith" | Fragment 1 |
| "23456" | "Janina Kowalska" | Fragment 2 |
| "34567" | "Steve Smith" | Fragment 1 |
| "45678" | "Michael Smith" | Fragment 3 |
| "56789" | "Janina Kowalska" | Fragment 2 |
Nie ma żadnych ograniczeń dotyczących liczby fragmentów logicznych dla kolekcji. Kolekcja może zawierać tyle fragmentów logicznych, jak dokumenty o unikatowej wartości dla właściwości klucza fragmentu w każdym dokumencie.
Nie ma również żadnych ograniczeń rozmiaru pojedynczego fragmentu logicznego.
Ponadto usługa nie ogranicza transakcji do zakresu fragmentu logicznego. Usługa oparta na rdzeniach wirtualnych dla usługi Azure Cosmos DB dla bazy danych MongoDB obsługuje transakcje odczytu i zapisu, które mają zastosowanie w wielu fragmentach logicznych i w wielu fizycznych fragmentach w klastrze.
Fragmenty fizyczne
Fragmenty fizyczne to podstawowe maszyny i dyski odpowiedzialne za utrwalanie danych i wypełnianie transakcji bazy danych. W przeciwieństwie do fragmentów logicznych usługa zarządza fragmentami fizycznymi w ramach okładek.
Liczba fragmentów fizycznych jest definiowana podczas tworzenia klastra. Pojedyncze klastry fragmentów mają jeden fizyczny fragment, który jest całkowicie odpowiedzialny za transakcje magazynu i bazy danych klastra. Klastry wieloczęściowe dystrybuują dane i wolumin transakcji w fizycznych fragmentach w klastrze.
Mapowanie fragmentów logicznych na fizyczne fragmenty
Po dodaniu nowych fragmentów logicznych klaster bezproblemowo aktualizuje mapowanie logiczne do fizycznych fragmentów. Podobnie przypisanie przestrzeni adresowej do każdego fizycznego fragmentu jest zmieniane w miarę dodawania nowych fragmentów fizycznych do klastra, po czym fragmenty logiczne są ponownie równoważone w klastrze.
Zakres skrótów używany do mapowania fragmentów logicznych i fizycznych jest równomiernie rozłożony na fizyczne fragmenty w klastrze. Każdy fragment fizyczny jest właścicielem zasobnika o równomiernym rozmiarze zakresu skrótów. Dla każdego zapisanego dokumentu wartość właściwości klucza fragmentu jest skrótem, a wartość skrótu określa mapowanie dokumentu na bazowy fragment fizyczny. Wewnętrznie kilka logicznych fragmentów mapuje się na pojedynczy fragment fizyczny. Co więcej, fragmenty logiczne nigdy nie są dzielone na fragmenty fizyczne, a wszystkie dokumenty dla fragmentu logicznego są mapowane tylko na jeden fizyczny fragment.
Korzystając z poprzedniego przykładu przy użyciu klastra z dwoma fragmentami fizycznymi, w tej tabeli przedstawiono przykładowe mapowanie dokumentów na fizyczne fragmenty.
| Identyfikator dokumentu | Wartość klucza fragmentu | Fragment logiczny | Fragment fizyczny |
|---|---|---|---|
| "12345" | "Steve Smith" | Fragment 1 | Fragment fizyczny 1 |
| "23456" | "Janina Kowalska" | Fragment 2 | Fizyczny fragment 2 |
| "34567" | "Steve Smith" | Fragment 1 | Fragment fizyczny 1 |
| "45678" | "Michael Smith" | Fragment 3 | Fragment fizyczny 1 |
| "56789" | "Janina Kowalska" | Fragment 2 | Fizyczny fragment 2 |
Pojemność fragmentów fizycznych
Warstwa klastra wybrana podczas aprowizowania klastra określa pojemność procesora CPU i pamięci fizycznego fragmentu. Podobnie jednostka SKU magazynu określa pojemność magazynu i liczby operacji we/wy na sekundę fizycznego fragmentu. Większe warstwy klastra zapewniają większą moc obliczeniową i większą pamięć, a większe dyski magazynu zapewniają więcej miejsca do magazynowania i liczby operacji we/wy na sekundę. Duże obciążenia odczytu korzystają z większej warstwy klastra, podczas gdy duże obciążenia zapisu korzystają z większej jednostki SKU magazynu. Warstwę klastra można skalować w górę i w dół po utworzeniu klastra na podstawie zmieniających się potrzeb aplikacji.
W klastrze wieloczęściowym pojemność każdego fizycznego fragmentu jest taka sama. Skalowanie w górę warstwy klastra lub jednostka SKU magazynu nie zmienia umieszczania fragmentów logicznych na fizycznych fragmentach. Po operacji skalowania w górę liczba fragmentów fizycznych pozostaje taka sama, co pozwala uniknąć konieczności ponownego równoważenia danych w klastrze.
Pojemność zasobów obliczeniowych, pamięci, magazynu i liczby operacji we/wy na sekundę fizycznego fragmentu określa zasoby dostępne dla fragmentów logicznych. Klucze fragmentów, które nie mają równomiernej dystrybucji magazynu i woluminów żądań, mogą spowodować nierówne użycie magazynu i przepływności w klastrze. Gorące partycje mogą powodować nierównomierne wykorzystanie fragmentów fizycznych, co prowadzi do nieprzewidywalnej przepływności i wydajności. W związku z tym klastry podzielone na fragmenty wymagają starannego planowania z góry, aby zapewnić spójność wydajności, ponieważ wymagania aplikacji zmieniają się wraz z upływem czasu.
Zestawy replik
Każdy fragment fizyczny składa się z zestawu replik, nazywanych również zestawem replik. Każda replika hostuje wystąpienie aparatu bazy danych. Zestaw replik sprawia, że magazyn danych w ramach fizycznego fragmentu jest trwały, wysoce dostępny i spójny. Każda replika tworząca fragment fizyczny dziedziczy magazyn i pojemność obliczeniową fragmentu fizycznego. Usługa Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB automatycznie zarządza zestawami replik.
Najlepsze rozwiązania dotyczące fragmentowania danych
Fragmentowanie w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB nie jest wymagane, chyba że magazyn kolekcji i woluminy transakcji mogą przekroczyć pojemność pojedynczego fizycznego fragmentu. Na przykład usługa zapewnia 32 TB dysków na fragment. Jeśli kolekcja wymaga więcej niż 32 TB, powinna zostać podzielony na fragmenty.
Nie jest konieczne fragmentowanie każdej kolekcji w klastrze z wieloma fragmentami fizycznymi. Kolekcje podzielone na fragmenty i nieuhardowane mogą współistnieć w tym samym klastrze. Usługa optymalnie dystrybuuje kolekcje w klastrze, aby równomiernie wykorzystać zasoby obliczeniowe i magazynowe klastra tak równomiernie, jak to możliwe.
W przypadku aplikacji z dużą liczbą operacji odczytu klucz fragmentu musi być wybrany na podstawie najczęściej używanych wzorców zapytań. Najczęściej używany filtr zapytań dla kolekcji należy wybrać jako klucz fragmentu, aby zoptymalizować najwyższy procent transakcji bazy danych, lokalizując wyszukiwanie w jednym fizycznym fragmentie.
W przypadku aplikacji intensywnie korzystających z zapisu, które faworyzują wydajność zapisu w ramach operacji odczytu, należy wybrać klucz fragmentu, aby równomiernie rozłożyć dane na fizyczne fragmenty. Klucze fragmentów o najwyższej kardynalności zapewniają najlepszą możliwość równomiernego rozłożenia tak równomiernie, jak to możliwe.
Aby uzyskać optymalną wydajność, rozmiar magazynu fragmentu logicznego powinien być mniejszy niż 4 TB.
Aby uzyskać optymalną wydajność, fragmenty logiczne powinny być równomiernie rozproszone w magazynie i woluminie żądań w fizycznych fragmentach klastra.
Jak fragmentować kolekcję
Rozważmy następujący dokument w kolekcji "kosmicznej" bazy danych i "pracownika"
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Poniższy przykład fragmentuje kolekcję pracowników w bazie danych cosmicworks we właściwości firstName.
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
Kolekcję można również fragmentować przy użyciu polecenia administratora:
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
Chociaż nie jest idealnym rozwiązaniem do zmiany klucza fragmentu po tym, jak kolekcja znacznie wzrosła w woluminie magazynu, można użyć polecenia reshardCollection w celu zmiany klucza fragmentu.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
Kolekcję można również ponownie fragmentować przy użyciu polecenia administratora:
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
Najlepszym rozwiązaniem jest utworzenie indeksu we właściwości klucza fragmentu.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})