Fragmentowanie pod kątem skalowalności poziomej w usłudze Azure DocumentDB

Usługa Azure DocumentDB obsługuje 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 których każdy odpowiada partycji logicznej. Dokumenty z każdą unikalną wartością właściwości klucza shardu znajdują się w tym samym logicznym shardzie.

Dla każdego dokumentu wstawionego do kolekcji podzielonej na fragmenty wartość klucza shardu jest haszowana w celu obliczenia przypisanego logicznego fragmentu. Zadanie umieszczania logicznego fragmentu i dystrybucji wszystkich fragmentów logicznych w klastrze jest zdjęte z użytkownika i w pełni zarządzane przez usługę.

Fragmenty logiczne

Wszystkie dokumenty zawierające tę samą wartość klucza shardingu należą do tego samego fragmentu logicznego.

Rozważmy na przykład kolekcję o nazwie Employees z poniższą strukturą dokumentu.

W tej tabeli przedstawiono odwzorowanie wartości klucza shardu na partycje logiczne.

• 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 Azure DocumentDB 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 pod przykrywką.

Liczba fragmentów fizycznych jest definiowana podczas tworzenia klastra i może zostać zwiększona, jeśli rozmiar bazy danych wzrośnie wraz z upływem czasu. Klastry z pojedynczym fragmentem mają jeden fizyczny fragment (węzeł), który jest całkowicie odpowiedzialny za przechowywanie danych i transakcje bazodanowe klastra. Klastry wieloczęściowe dystrybuują dane i obciążenie transakcji między fizycznymi fragmentami w klastrze.

Mapowanie fragmentów logicznych na fizyczne fragmenty

Po dodaniu nowych fragmentów logicznych klaster bezproblemowo aktualizuje mapowanie logicznych fragmentów do fizycznych. 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 posiada segment o równomiernym rozmiarze zakresu skrótów. Dla każdego zapisanego dokumentu wartość właściwości klucza fragmentu jest haszowana, a uzyskana wartość haszu określa mapowanie dokumentu na odpowiadający fizyczny fragment. Wewnętrznie kilka logicznych fragmentów przypisuje się do pojedynczego fragmentu fizycznego. 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.

Pojemność fragmentów fizycznych

Poziom klastra wybrany podczas konfigurowania klastra określa wydajność CPU i pojemność pamięci fizycznego fragmentu. Podobnie SKU magazynowania określa pojemność przechowywania i IOPS fizycznego fragmentu. Większe poziomy klastra zapewniają większą moc obliczeniową i większą pamięć, a większe dyski pamięci masowej zapewniają więcej miejsca i operacji we/wy na sekundę (IOPS). Duże obciążenia odczytu korzystają z większej warstwy klastra, podczas gdy duże obciążenia zapisu korzystają z większej jednostki magazynowej SKU. 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 SKU magazynowania 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ównomiernego rozmieszczenia przechowywania i obciążenia żądaniami, mogą powodować nierówne użycie przestrzeni dyskowej i przepustowości w klastrze. Gorące partycje mogą powodować nierównomierne wykorzystanie fragmentów fizycznych, co prowadzi do nieprzewidywalnej przepustowoś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 zapewnia trwałość, wysoką dostępność i spójność magazynu danych w ramach fizycznego shardu. Każda replika tworząca fragment fizyczny dziedziczy pojemność przechowywania i obliczeniową fragmentu fizycznego. Usługa Azure DocumentDB automatycznie zarządza zestawami replik.

Najlepsze rozwiązania dotyczące fragmentowania danych

• Fragmentacja w usłudze Azure DocumentDB nie jest wymagana, chyba że wolumeny przechowywania i transakcji kolekcji mogą przekraczać 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ć podzielona na fragmenty.

• Nie jest konieczne fragmentowanie każdej kolekcji w klastrze z wieloma fragmentami fizycznymi. Kolekcje podzielone na fragmenty i niepodzielone na fragmenty mogą współistnieć w tej samej 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 nad odczytem, należy wybrać klucz podziału, 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 w możliwie najrówniejszy sposób.

• Aby uzyskać optymalną wydajność, rozmiar przestrzeni dyskowej 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 bazie danych 'cosmicworks' i kolekcji 'pracowników'

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Poniższy przykład sharduje kolekcję pracowników w bazie danych cosmicworks według 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 idealnie zmieniać klucz fragmentu po tym, jak kolekcja znacznie wzrosła w rozmiarze pamięci, 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
})

Dalsze kroki

• Dowiedz się, jak skalować klaster usługi Azure DocumentDB
• Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi indeksowania