Partycjonowanie i skalowanie w poziomie w usłudze Azure Cosmos DB

DOTYCZY: NoSQL MongoDB Kasandra Gremlin Stół

Usługa Azure Cosmos DB używa partycjonowania do skalowania poszczególnych kontenerów w bazie danych w celu spełnienia wymagań dotyczących wydajności aplikacji. Elementy w kontenerze są podzielone na odrębne podzestawy nazywane partycjami logicznymi. Partycje logiczne są tworzone na podstawie wartości klucza partycji skojarzonego z każdym elementem w kontenerze. Wszystkie elementy w partycji logicznej mają tę samą wartość klucza partycji.

Na przykład kontener przechowuje elementy. Każdy element ma unikatową wartość właściwości UserID . Jeśli UserID służy jako klucz partycji dla elementów w kontenerze i istnieje 1000 unikatowych UserID wartości, dla kontenera są tworzone 1000 partycji logicznych.

Oprócz klucza partycji, który określa partycję logiczną elementu, każdy element w kontenerze ma identyfikator elementu (unikatowy w ramach partycji logicznej). Połączenie klucza partycji i identyfikatora elementu powoduje utworzenie indeksu elementu, który jednoznacznie identyfikuje element. Wybranie klucza partycji jest ważną decyzją, która wpływa na wydajność aplikacji.

W tym artykule wyjaśniono relację między partycjami logicznymi i fizycznymi. W tym artykule omówiono również najlepsze rozwiązania dotyczące partycjonowania i przedstawiono szczegółowy sposób działania skalowania w poziomie w usłudze Azure Cosmos DB. Nie trzeba rozumieć tych wewnętrznych szczegółów, aby wybrać klucz partycji, ale obejmujemy je, aby mieć jasność co do sposobu działania usługi Azure Cosmos DB.

Partycje logiczne

Partycja logiczna składa się z zestawu elementów, które mają ten sam klucz partycji. Na przykład w kontenerze zawierającym dane dotyczące żywienia żywności wszystkie elementy zawierają foodGroup właściwość. Możesz użyć foodGroup jako klucza partycji dla kontenera. Grupy elementów, które mają określone wartości dla foodGroup, takich jak Beef Products, Baked Productsi Sausages and Luncheon Meats, tworzą odrębne partycje logiczne.

Partycja logiczna definiuje również zakres transakcji bazy danych. Elementy w partycji logicznej można aktualizować przy użyciu transakcji z izolacją migawki. Po dodaniu nowych elementów do kontenera system w przezroczysty sposób tworzy nowe partycje logiczne. Nie musisz martwić się o usunięcie partycji logicznej po usunięciu danych bazowych.

Nie ma limitu liczby partycji logicznych w kontenerze. Każda partycja logiczna może przechowywać do 20 GB danych. Dobre opcje klucza partycji mają szeroki zakres możliwych wartości. Na przykład w kontenerze, w którym wszystkie elementy zawierają foodGroup właściwość, dane w Beef Products partycji logicznej mogą rosnąć do 20 GB. Wybranie klucza partycji z szerokim zakresem możliwych wartości gwarantuje możliwość skalowania kontenera.

Alerty usługi Azure Monitor umożliwiają monitorowanie, czy rozmiar partycji logicznej zbliża się do 20 GB.

Partycje fizyczne

Kontener jest skalowany przez dystrybucję danych i przepływności między partycjami fizycznymi. Wewnętrznie co najmniej jedna partycja logiczna jest mapowana na jedną partycję fizyczną. Zazwyczaj mniejsze kontenery mają wiele partycji logicznych, ale wymagają tylko jednej partycji fizycznej. W przeciwieństwie do partycji logicznych partycje fizyczne są wewnętrzną implementacją systemu, a usługa Azure Cosmos DB całkowicie zarządza partycjami fizycznymi.

Liczba partycji fizycznych w kontenerze zależy od następujących cech:

• Aprowizowana przepływność (każda pojedyncza partycja fizyczna może zapewnić przepływność do 10 000 jednostek żądań na sekundę). Limit 10 000 RU/s dla partycji fizycznych oznacza, że partycje logiczne mają również limit 10 000 RU/s, ponieważ każda partycja logiczna jest mapowana tylko na jedną partycję fizyczną.

• Łączny magazyn danych (każda pojedyncza partycja fizyczna może przechowywać do 50 GB danych).

Uwaga

Partycje fizyczne są wewnętrzną implementacją systemu i są całkowicie zarządzane przez usługę Azure Cosmos DB. Podczas opracowywania rozwiązań nie skupiaj się na partycjach fizycznych, ponieważ nie można ich kontrolować. Zamiast tego skoncentruj się na kluczach partycji. Jeśli wybierzesz klucz partycji, który równomiernie rozdziela zużycie przepływności między partycjami logicznymi, upewnij się, że zużycie przepływności między partycjami fizycznymi jest zrównoważone.

Nie ma limitu całkowitej liczby partycji fizycznych w kontenerze. W miarę wzrostu aprowizowanej przepływności lub rozmiaru danych usługa Azure Cosmos DB automatycznie tworzy nowe partycje fizyczne, dzieląc istniejące. Podziały partycji fizycznej nie wpływają na dostępność aplikacji. Po podzieleniu partycji fizycznej wszystkie dane w ramach jednej partycji logicznej będą nadal przechowywane na tej samej partycji fizycznej. Podział partycji fizycznej po prostu tworzy nowe mapowanie partycji logicznych na partycje fizyczne.

Przepływność aprowizowana dla kontenera jest podzielona równomiernie między partycje fizyczne. Projekt klucza partycji, który nie dystrybuuje żądań równomiernie, może spowodować zbyt wiele żądań skierowanych do małego podzbioru partycji, które stają się "gorące". Gorące partycje prowadzą do nieefektywnego użycia aprowizowanej przepływności, co może spowodować ograniczenie szybkości i wyższe koszty.

Rozważmy na przykład kontener ze ścieżką /foodGroup określoną jako klucz partycji. Kontener może mieć dowolną liczbę partycji fizycznych, ale w tym przykładzie przyjęto założenie, że ma trzy partycje. Pojedyncza partycja fizyczna może zawierać wiele kluczy partycji. Na przykład największa partycja fizyczna może zawierać trzy najważniejsze partycje logiczne o największym rozmiarze: Beef Products, Vegetable and Vegetable Productsi Soups, Sauces, and Gravies.

Jeśli przypiszesz przepływność wynoszącą 18 000 jednostek żądań na sekundę (RU/s), każda z trzech partycji fizycznych może korzystać z 1/3 całkowitej aprowizowanej przepływności. W ramach wybranej partycji fizycznej klucze Beef Productspartycji logicznej , Vegetable and Vegetable Productsi Soups, Sauces, and Gravies mogą łącznie korzystać z 6000 aprowizowanych jednostek RU/s partycji fizycznej. Ponieważ aprowizowana przepływność jest równomiernie podzielona na partycje fizyczne kontenera, ważne jest, aby wybrać klucz partycji, który równomiernie rozdziela zużycie przepływności. Aby uzyskać więcej informacji, zobacz wybieranie odpowiedniego klucza partycji logicznej.

Zarządzanie partycjami logicznymi

Usługa Azure Cosmos DB w sposób przezroczysty i automatycznie zarządza umieszczaniem partycji logicznych na partycjach fizycznych w celu efektywnego zaspokojenia potrzeb związanych ze skalowalnością i wydajnością kontenera. Wraz ze wzrostem przepływności i wymagań dotyczących magazynu aplikacji usługa Azure Cosmos DB przenosi partycje logiczne, aby automatycznie rozkładać obciążenie na większą liczbę partycji fizycznych. Możesz dowiedzieć się więcej o partycjach fizycznych.

Usługa Azure Cosmos DB używa partycjonowania opartego na skrótach w celu rozłożenia partycji logicznych między partycje fizyczne. Usługa Azure Cosmos DB tworzy skrót wartości klucza partycji elementu. Wynik skrótu określa partycję logiczną. Następnie usługa Azure Cosmos DB przydziela równomiernie odstępy kluczy partycji między partycjami fizycznymi.

Transakcje (w procedurach składowanych lub wyzwalaczach) są dozwolone tylko dla elementów w pojedynczej partycji logicznej.

Zestawy replik

Każda partycja fizyczna 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 partycji fizycznej jest trwały, wysoce dostępny i spójny. Każda replika tworząca partycję fizyczną dziedziczy przydział magazynu partycji. Wszystkie repliki partycji fizycznej łącznie obsługują przepływność przydzieloną do partycji fizycznej. Usługa Azure Cosmos DB automatycznie zarządza zestawami replik.

Zazwyczaj mniejsze kontenery wymagają tylko jednej partycji fizycznej, ale nadal mają co najmniej cztery repliki.

Na poniższej ilustracji przedstawiono sposób mapowania partycji logicznych na partycje fizyczne, które są dystrybuowane globalnie. Zestaw partycji na obrazie odnosi się do grupy partycji fizycznych, które zarządzają tymi samymi kluczami partycji logicznych w wielu regionach:

Wybieranie klucza partycji

Klucz partycji ma dwa składniki: ścieżkę klucza partycji i wartość klucza partycji. Rozważmy na przykład element { "userId" : "Andrew", "worksFor": "Microsoft" } , jeśli jako klucz partycji wybierzesz wartość "userId", oto dwa kluczowe składniki partycji:

• Ścieżka klucza partycji (np. "/userId"). Ścieżka klucza partycji akceptuje znaki alfanumeryczne i podkreślenia (_). Można również używać obiektów zagnieżdżonych przy użyciu standardowej notacji ścieżki(/).

• Wartość klucza partycji (na przykład: "Andrew"). Wartość klucza partycji może być typu ciągowego lub liczbowego.

Aby dowiedzieć się więcej na temat limitów przepływności, magazynu i długości klucza partycji, zobacz artykuł Limity przydziału usługi Azure Cosmos DB.

Wybór klucza partycji jest prostym, ale ważnym wyborem projektowym w usłudze Azure Cosmos DB. Po wybraniu klucza partycji nie można go zmienić w miejscu. Jeśli musisz zmienić klucz partycji, należy przenieść dane do nowego kontenera przy użyciu nowego żądanego klucza partycji. (Zadania kopiowania kontenerów pomagają w tym procesie).

W przypadku wszystkich kontenerów klucz partycji powinien:

• Być właściwością, która ma wartość, która nie zmienia się. Jeśli właściwość jest kluczem partycji, nie można zaktualizować wartości tej właściwości.

• Powinna zawierać String tylko wartości — lub liczby powinny zostać przekonwertowane na String, jeśli istnieje prawdopodobieństwo, że znajdują się poza granicami liczby podwójnej dokładności zgodnie z IEEE 754 binary64. Specyfikacja Json określa przyczyny, dla których używanie liczb spoza tej granicy jest w ogóle złą praktyką ze względu na prawdopodobne problemy ze współdziałaniem. Te problemy są szczególnie istotne w przypadku kolumny klucza partycji, ponieważ jest niezmienna i wymaga późniejszej zmiany migracji danych.

• Ma wysoką kardynalność. Innymi słowy, właściwość powinna mieć szeroki zakres możliwych wartości.

• Równomierne rozłożenie użycia jednostek żądań (RU) i magazynu danych we wszystkich partycjach logicznych. Dzięki temu równomierne użycie jednostek ŻĄDANIA i dystrybucja magazynu między partycjami fizycznymi.

• Mają wartości, które nie są zwykle większe niż 2048 bajtów lub 101 bajtów, jeśli duże klucze partycji nie są włączone. Aby uzyskać więcej informacji, zobacz duże klucze partycji

Jeśli potrzebujesz transakcji ACID z wieloma elementami w usłudze Azure Cosmos DB, musisz użyć procedur składowanych lub wyzwalaczy. Wszystkie procedury składowane i wyzwalacze oparte na języku JavaScript są ograniczone do jednej partycji logicznej.

Uwaga

Jeśli masz tylko jedną partycję fizyczną, wartość klucza partycji może nie być odpowiednia, ponieważ wszystkie zapytania będą dotyczyć tej samej partycji fizycznej.

Typy kluczy partycji

Strategia partycjonowania	Kiedy używać	Zalety	Wady
Zwykły klucz partycji (np. CustomerId, OrderId)	— Użyj, gdy klucz partycji ma wysoką kardynalność i jest zgodny z wzorcami zapytań (np. filtrowanie według identyfikatora CustomerId). — Odpowiednie dla obciążeń, w których zapytania są przeznaczone głównie dla danych pojedynczego klienta (np. pobieranie wszystkich zamówień dla klienta).	- Proste do zarządzania. — Wydajne zapytania, gdy wzorzec dostępu jest zgodny z kluczem partycji (np. wykonywanie zapytań dotyczących wszystkich zamówień według identyfikatora CustomerId). — Uniemożliwia wykonywanie zapytań między partycjami, jeśli wzorce dostępu są spójne.	- Ryzyko gorących partycji, jeśli niektóre wartości (np. kilku klientów o dużym natężeniu ruchu) generują znacznie więcej danych niż inne. - Może osiągnąć limit 20 GB na partycję logiczną, jeśli wolumin danych dla określonego klucza szybko wzrośnie.
Syntetyczny klucz partycji (np. CustomerId + OrderDate)	— Użyj, gdy żadne pojedyncze pole nie ma zarówno wysokiej kardynalności, jak i pasuje do wzorców zapytań. — Dobra w przypadku obciążeń z dużym obciążeniem zapisem, w których dane muszą być równomiernie dystrybuowane między partycjami fizycznymi (np. wiele zamówień złożonych w tej samej dacie).	— Pomaga równomiernie dystrybuować dane między partycjami, zmniejszając liczbę gorących partycji (np. dystrybucję zamówień według identyfikatorów CustomerId i OrderDate). — Rozkłada zapisy w wielu partycjach, zwiększając przepływność.	— Zapytania filtrujące tylko według jednego pola (np. tylko CustomerId) mogą powodować zapytania obejmujące wiele partycji. - Zapytania obejmujące wiele partycji mogą prowadzić do wyższego użycia jednostek RU (2–3 RU/s dodatkowej opłaty za każdą partycję fizyczną, która istnieje) i dodatkowe opóźnienie.
Hierarchiczny klucz partycji (HPK) (np. CustomerId/OrderId, StoreId/ProductId)	— Używaj funkcji partycjonowania na wielu poziomach, aby obsługiwać zestawy danych na dużą skalę. — Idealne rozwiązanie w przypadku filtrowania zapytań na pierwszych i drugich poziomach hierarchii.	- Pomaga uniknąć limitu 20 GB, tworząc wiele poziomów partycjonowania. — Wydajne wykonywanie zapytań na obu poziomach hierarchicznych (np. filtrowanie najpierw według identyfikatora CustomerID, a następnie według identyfikatora zamówienia). — Minimalizuje zapytania obejmujące wiele partycji dla zapytań przeznaczonych dla najwyższego poziomu (np. pobieranie wszystkich danych z określonego identyfikatora CustomerID).	- Wymaga starannego planowania, aby upewnić się, że klucz pierwszego poziomu ma wysoką kardynalność i jest uwzględniony w większości zapytań. — Bardziej złożone zarządzanie niż zwykły klucz partycji. — Jeśli zapytania nie są zgodne z hierarchią (np. filtrowanie tylko według identyfikatora zamówienia, gdy identyfikator CustomerID jest pierwszym poziomem), wydajność zapytań może ulec pogorszeniu.

Klucze partycji dla kontenerów z dużym obciążeniem do odczytu

W przypadku większości kontenerów powyższe kryteria należy wziąć pod uwagę podczas wybierania klucza partycji. W przypadku dużych kontenerów z dużym obciążeniem do odczytu warto jednak wybrać klucz partycji, który jest często wyświetlany jako filtr w zapytaniach. Zapytania mogą być efektywnie kierowane tylko do odpowiednich partycji fizycznych , uwzględniając klucz partycji w predykacie filtru.

Ta właściwość może być dobrym wyborem klucza partycji, jeśli większość żądań obciążenia to zapytania, a większość zapytań ma filtr równości dla tej samej właściwości. Jeśli na przykład często uruchamiasz zapytanie, które filtruje UserIDwartość , wybranie UserID go jako klucza partycji spowoduje zmniejszenie liczby zapytań obejmujących wiele partycji.

Jeśli jednak kontener jest mały, prawdopodobnie nie masz wystarczającej liczby partycji fizycznych, aby martwić się o wydajność zapytań obejmujących wiele partycji. Większość małych kontenerów w usłudze Azure Cosmos DB wymaga tylko jednej lub dwóch partycji fizycznych.

Jeśli kontener może wzrosnąć do więcej niż kilku partycji fizycznych, upewnij się, że wybrano klucz partycji, który minimalizuje zapytania obejmujące wiele partycji. Kontener wymaga więcej niż kilku partycji fizycznych, jeśli spełniony jest jeden z następujących warunków:

• Kontener ma ponad 30 000 aprowizowania jednostek RU

• Kontener przechowuje ponad 100 GB danych

Użyj identyfikatora elementu jako klucza partycji

Uwaga

Ta sekcja dotyczy głównie interfejsu API dla noSQL. Inne interfejsy API, takie jak interfejs API dla języka Gremlin, nie obsługują unikatowego identyfikatora jako klucza partycji.

Jeśli kontener ma właściwość, która ma szeroki zakres możliwych wartości, prawdopodobnie jest to doskonały wybór klucza partycji. Jednym z możliwych przykładów takiej właściwości jest identyfikator elementu. W przypadku małych kontenerów z dużym obciążeniem do odczytu lub kontenerów o dużym rozmiarze identyfikator elementu (/id) jest w naturalny sposób doskonałym wyborem dla klucza partycji.

Identyfikator elementu właściwości systemu istnieje w każdym elemencie w kontenerze. Mogą istnieć inne właściwości reprezentujące logiczny identyfikator elementu. W wielu przypadkach te identyfikatory są również doskonałymi opcjami klucza partycji z tych samych powodów co identyfikator elementu.

Identyfikator elementu jest doskonałym wyborem klucza partycji z następujących powodów:

• Istnieje szeroki zakres możliwych wartości (jeden unikatowy identyfikator elementu na element).
• Ponieważ istnieje unikatowy identyfikator elementu na element, identyfikator elementu doskonale sprawdza się podczas równomiernego równoważenia użycia jednostek RU i magazynu danych.
• Efektywne odczyty punktów można łatwo wykonać, ponieważ zawsze znasz klucz partycji elementu, jeśli znasz jego identyfikator elementu.

Niektóre kwestie, które należy wziąć pod uwagę podczas wybierania identyfikatora elementu jako klucza partycji, obejmują:

• Jeśli identyfikator elementu jest kluczem partycji, staje się unikatowym identyfikatorem w całym kontenerze. Nie można utworzyć elementów, które mają zduplikowane identyfikatory elementów.
• Jeśli masz kontener z dużym obciążeniem do odczytu z wieloma partycjami fizycznymi, zapytania są bardziej wydajne, jeśli mają filtr równości z identyfikatorem elementu.
• Nie można uruchamiać procedur składowanych ani wyzwalaczy przeznaczonych dla wielu partycji logicznych.

Powiązana zawartość

• Aprowizowana przepływność w usłudze Azure Cosmos DB.
• Dystrybucja globalna w usłudze Azure Cosmos DB.
• Trenowanie: modelowanie i partycjonowanie danych w usłudze Azure Cosmos DB.