Wybieranie klucza partycji
Pamiętaj, że dane w dokumentach JSON są przechowywane w bazach danych usługi Azure Cosmos DB w kontenerach, które z kolei są dystrybuowane między partycjami fizycznymi i gdzie dane są kierowane do odpowiedniej partycji fizycznej na podstawie wartości klucza partycji.
Klucz partycji jest wymaganą właściwością dokumentu, która zapewnia, że dokumenty z tą samą wartością klucza partycji są kierowane i przechowywane w określonej partycji fizycznej. Partycja fizyczna obsługuje stałą maksymalną ilość miejsca do magazynowania i przepływności (RU/s). Usługa Azure Cosmos DB automatycznie dystrybuuje partycje logiczne między dostępne partycje fizyczne, ponownie używając wartości klucza partycji, aby to zrobić w przewidywalny sposób.
W tej lekcji dowiesz się więcej o partycjach logicznych i sposobach unikania gorących partycji. Te informacje pomogą nam wybrać odpowiedni klucz partycji dla danych klienta w naszym scenariuszu.
W usłudze Azure Cosmos DB zwiększasz magazyn i przepływność, dodając więcej partycji fizycznych w celu uzyskiwania dostępu do danych i ich przechowywania. Maksymalny rozmiar magazynu partycji fizycznej wynosi 50 GB, a maksymalna przepływność to 10 000 RU/s.
Partycje logiczne w usłudze Azure Cosmos DB
Partycja logiczna jest abstrakcją nad bazowymi partycjami fizycznymi. Wiele partycji logicznych można przechowywać w jednej partycji fizycznej. Kontener może mieć nieograniczoną liczbę partycji logicznych. Poszczególne partycje logiczne są przenoszone do nowych partycji fizycznych w miarę zwiększania rozmiaru w celu zapewnienia optymalnego wykorzystania i wzrostu magazynu. Przeniesienie partycji logicznych jako jednostki gwarantuje, że wszystkie dokumenty w nim znajdują się na tej samej partycji fizycznej. Maksymalny rozmiar partycji logicznej to 20 GB. Użycie klucza partycji o wysokiej kardynalności pozwala uniknąć tego limitu 20 GB przez rozłożenie danych na większą liczbę partycji logicznych. Możesz również użyć hierarchicznych kluczy partycji, które organizują wartości kluczy partycji w hierarchii, aby uniknąć tego limitu. Zostały one omówione w innej ścieżce szkoleniowej.
Klucz partycji umożliwia kierowanie danych dla partycji logicznej. Jest to właściwość, która istnieje w każdym dokumencie w kontenerze, która kieruje dane. Kontener to kolejna abstrakcja dla wszystkich danych przechowywanych przy użyciu tego samego klucza partycji. Klucz partycji jest definiowany podczas tworzenia kontenera.
W poniższym przykładzie kontener ma klucz /usernamepartycji .
Unikaj gorących partycji
Podczas modelowania danych dla usługi Azure Cosmos DB niezwykle ważne jest, aby wybrany klucz partycji był równomiernym rozkładem danych i żądań zarówno logicznych, jak i rozszerzeń, partycji fizycznych w kontenerze. Jest to szczególnie istotne, gdy kontenery rosną większe i mają coraz większą liczbę partycji fizycznych.
Jeśli podczas programowania nie przetestujesz projektu bazy danych pod obciążeniem, może nie zostać ujawniony słaby wybór klucza partycji, dopóki aplikacja nie zostanie już zapisana w środowisku produkcyjnym i znaczących danych.
Jeśli dane nie są poprawnie partycjonowane, mogą powodować gorące partycje. Gorące partycje uniemożliwiają skalowanie obciążenia aplikacji i mogą występować zarówno w magazynie, jak i przepływności.
Gorące partycje magazynu
Gorąca partycja w magazynie występuje, gdy masz klucz partycji, który powoduje wysoce asymetryczne wzorce magazynu. Rozważmy na przykład wielodostępną aplikację, która używa identyfikatora TenantId jako klucza partycji z sześcioma dzierżawami: od A do F. Dzierżawy B,C,E i F są bardzo małe, dzierżawa D ma nieco więcej danych. Jednak dzierżawa A jest ogromna i szybko osiąga limit 20 GB dla swojej partycji. W tym scenariuszu musimy wybrać inny klucz partycji, który będzie rozkładać magazyn na więcej partycji logicznych.
Gorąca partycje przepływności
Przepływność może mieć problemy z gorącą partycją, gdy większość lub wszystkie żądania przechodzą do tej samej partycji logicznej.
Ważne jest, aby zrozumieć wzorce dostępu dla aplikacji, aby upewnić się, że żądania są rozłożone tak równomiernie, jak to możliwe dla wartości klucza partycji. Gdy przepływność jest aprowizowana dla kontenera w usłudze Azure Cosmos DB, jest przydzielana równomiernie we wszystkich partycjach fizycznych w kontenerze.
Na przykład jeśli masz kontener z 30 000 RU/s, to obciążenie jest rozłożone na trzy partycje fizyczne dla tych samych sześciu dzierżaw wymienionych wcześniej. Więc każda partycja fizyczna pobiera 10 000 RU/s. Jeśli dzierżawa D zużywa wszystkie swoje 10 000 RU/s, będzie ograniczona szybkość, ponieważ nie może korzystać z przepływności przydzielonej do innych partycji. Powoduje to niską wydajność dzierżawy C i D oraz pozostawienie nieużywanej pojemności obliczeniowej w innych partycjach fizycznych i pozostałych dzierżawach. Ostatecznie ten klucz partycji powoduje projekt bazy danych, w którym obciążenie aplikacji nie może być skalowane.
Gdy dane i żądania są równomiernie rozłożone, baza danych może rozwijać się w sposób, który w pełni wykorzystuje zarówno magazyn, jak i przepływność. Wynik będzie najlepszą możliwą wydajnością i najwyższą wydajnością. Krótko mówiąc, projekt bazy danych będzie skalowany.
Rozważ odczyty i zapisy
Podczas wybierania klucza partycji należy również rozważyć, czy dane są duże, czy duże. Należy dążyć do dystrybucji żądań z dużym obciążeniem zapisem przy użyciu klucza partycji, który ma wysoką kardynalność.
W przypadku obciążeń z dużym obciążeniem odczytu należy upewnić się, że zapytania są przetwarzane przez jedną lub ograniczoną liczbę partycji przez dołączenie WHERE klauzuli z filtrem równości dla klucza partycji lub operatora IN w podzestawie wartości klucza partycji w zapytaniach.
W scenariuszach, w których obciążenie aplikacji jest duże i duże obciążenie zapisu, istnieje rozwiązanie. Zapoznamy się z tym w następnym module.
Poniższa ilustracja przedstawia kontener podzielony na partycje według nazwy użytkownika. To zapytanie będzie osiągać tylko jedną partycję logiczną, więc jej wydajność zawsze będzie dobra.
Zapytanie, które filtruje inną właściwość, na przykład favoriteColor, spowoduje "rozsyłanie" do wszystkich partycji w kontenerze. Jest to również nazywane zapytaniem między partycjami. Takie zapytanie będzie działać zgodnie z oczekiwaniami, gdy kontener jest mały i zajmuje tylko jedną partycję. Jednak w miarę zwiększania się kontenera i rosnącej liczby partycji fizycznych to zapytanie stanie się wolniejsze i droższe, ponieważ będzie musiał sprawdzić każdą partycję, aby uzyskać wyniki, czy partycja fizyczna zawiera dane związane z zapytaniem, czy nie.
Wybieranie klucza partycji dla klientów
Teraz, gdy rozumiesz partycjonowanie w usłudze Azure Cosmos DB, możemy zdecydować o kluczu partycji dla danych klientów. Jak wspomniano wcześniej, przeprowadzamy trzy operacje na klientach: tworzenie klienta, aktualizowanie klienta i pobieranie klienta. W takim przypadku pobierzemy klienta według ich identyfikatora. Ponieważ ta operacja będzie najbardziej wywoływana, warto mieć sens, aby identyfikator klienta był kluczem partycji dla kontenera.
W tym miejscu może się martwić, że utworzenie identyfikatora klucza partycji oznacza, że będziemy mieć tyle partycji logicznych, ile istnieje klientów, z każdą partycją logiczną zawierającą tylko jeden dokument. Miliony klientów spowodowałoby miliony partycji logicznych.
Ale to jest całkowicie w porządku! Partycje logiczne są pojęciem wirtualnym i nie ma limitu liczby partycji logicznych, które można mieć. Usługa Azure Cosmos DB będzie sortować wiele partycji logicznych na tej samej partycji fizycznej. W miarę wzrostu liczby lub rozmiaru partycji logicznych usługa Cosmos DB przeniesie je do nowych partycji fizycznych w razie potrzeby.