Zalecenia dotyczące partycjonowania danych

Artykuł
11/15/2023

Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:

RE:06	Zaimplementuj terminową i niezawodną strategię skalowania na poziomie aplikacji, danych i infrastruktury.

Przewodnik pokrewny: skalowanie

W tym przewodniku opisano zalecenia dotyczące projektowania strategii partycjonowania danych dla wdrażanej technologii przechowywania danych i bazy danych. Ta strategia pomaga zwiększyć niezawodność majątku danych.

Kluczowe strategie projektowania

W wielu rozwiązaniach na dużą skalę partycje są używane do dzielenia danych, aby można było zarządzać nimi i uzyskiwać do niego dostęp oddzielnie. Partycjonowanie danych zwiększa skalowalność, zmniejsza rywalizację i optymalizuje wydajność. Zaimplementuj partycjonowanie danych, aby podzielić dane według wzorca użycia. Można na przykład zarchiwizować starsze dane w niedrogim magazynie danych. Starannie wybierz strategię partycjonowania, aby zmaksymalizować korzyści i zminimalizować niekorzystne skutki.

Uwaga

W tym artykule określenie partycjonowanie oznacza proces fizycznego dzielenia danych pomiędzy odrębne magazyny danych. Różni się ona od partycjonowania tabel programu SQL Server.

Cele partycjonowania danych

Zwiększyć skalowalność. Podczas skalowania w górę pojedynczego systemu bazy danych baza danych ostatecznie osiągnie limit sprzętu fizycznego. Jeśli dzielisz dane między wiele partycji, z każdą partycją hostowaną na osobnym serwerze, możesz skalować system w poziomie prawie na czas nieokreślony.
Zwiększyć wydajność. W każdej partycji operacje dostępu do danych są wykonywane na mniejszej ilości danych w porównaniu z danymi, które nie są partycjonowane. Partycjonowanie danych w celu zwiększenia wydajności systemu. Można również równolegle uruchamiać operacje na większej liczbie partycji.
Poprawić bezpieczeństwo. W niektórych przypadkach można oddzielić poufne i niewrażliwe dane na różne partycje i zastosować różne mechanizmy kontroli zabezpieczeń do poufnych danych.
Zapewnić elastyczność działania. Dane można partycjonować, aby dostosować operacje, zmaksymalizować wydajność administracyjną i zminimalizować koszty. Można na przykład zdefiniować strategie zarządzania, monitorowania, tworzenia kopii zapasowych i przywracania oraz innych zadań administracyjnych na podstawie znaczenia danych w każdej partycji.
Dostosować rodzaj magazynu danych do sposobu użycia danych. Każdą partycję można wdrożyć na innym typie magazynu danych na podstawie kosztów i wbudowanych funkcji oferowanych przez magazyn danych. Można na przykład przechowywać duże dane binarne w magazynie obiektów blob i przechowywać dane ustrukturyzowane w bazie danych dokumentów. Aby uzyskać więcej informacji, zobacz Omówienie modeli magazynu danych.
Zwiększyć dostępność. Aby uniknąć pojedynczego punktu awarii, można oddzielić dane między wieloma serwerami. Jeśli jedno wystąpienie nie powiedzie się, tylko dane w tej partycji są niedostępne. Operacje są kontynuowane w innych partycjach. To zagadnienie jest mniej istotne w przypadku magazynów danych zarządzanych platformy jako usługi (PaaS), ponieważ mają wbudowaną nadmiarowość.

Partycje projektowe

Istnieją trzy typowe strategie partycjonowania danych:

Partycjonowanie poziome (nazywane często fragmentowaniem). W tej strategii każda partycja jest oddzielnym magazynem danych, ale wszystkie partycje mają ten sam schemat. Każda partycja jest nazywana fragmentem i przechowuje podzbiór danych, takich jak zestaw zamówień klientów.
Partycjonowanie pionowe. W przypadku użycia tej strategii każda partycja zawiera podzestaw pól z elementów przechowywanych w magazynie danych. Pola są dzielone zgodnie ze sposobem ich użycia. Na przykład często używane pola mogą zostać umieszczone w jednej partycji pionowej, a rzadziej używane pola — w innej.
Partycjonowanie funkcjonalne. W tej strategii dane są agregowane zgodnie z tym, jak każdy ograniczony kontekst w systemie korzysta z danych. Na przykład system handlu elektronicznego może przechowywać dane faktur w jednej partycji i danych spisu produktów w innym.

Rozważ połączenie tych strategii podczas projektowania schematu partycjonowania. Można na przykład podzielić dane na fragmenty, a następnie zastosować partycjonowanie pionowe w celu dalszego podziału danych w poszczególnych fragmentach.

Partycjonowanie poziome (fragmentowanie)

Na poniższej ilustracji przedstawiono przykład partycjonowania poziomego lub fragmentowania. W tym przykładzie dane spisu produktów są podzielone na fragmenty oparte na kluczu produktu. Każdy fragment zawiera dane dla ciągłego zakresu kluczy fragmentowania (A–G oraz H–Z) w porządku alfabetycznym. Podczas dzielenia na fragmenty rozkłada obciążenie większej liczby komputerów, co zmniejsza rywalizację i poprawia wydajność.

Najważniejszym czynnikiem jest wybrany klucz fragmentowania. Gdy system będzie już działał, zmiana klucza może być trudna. Klucz musi zapewnić partycjonowanie danych w celu równomiernego rozłożenia obciążenia na fragmenty.

Fragmenty nie muszą mieć tego samego rozmiaru. Ważniejsze jest zrównoważenie liczby żądań. Niektóre fragmenty mogą być duże, ale każdy element w fragmentach ma niewielką liczbę operacji dostępu. Inne fragmenty mogą być mniejsze, ale dostęp do każdego elementu w fragmentach jest uzyskiwany częściej. Ważne jest również, aby zapewnić, że pojedynczy fragment nie przekracza limitów skalowania, w odniesieniu do pojemności i zasobów przetwarzania magazynu danych.

Unikaj tworzenia gorących partycji, które mogą mieć wpływ na wydajność i dostępność. Jeśli na przykład używasz pierwszej litery nazwy klienta, może ona utworzyć dystrybucję niezrównoważone, ponieważ niektóre litery są bardziej powszechne niż inne. Zamiast tego użyj skrótu identyfikatora klienta, aby równomiernie dystrybuować dane między partycjami.

Wybierz klucz fragmentowania, który minimalizuje przyszłą konieczność dzielenia dużych fragmentów, łączenia małych fragmentów w większe partycje lub zmiany schematu. Te operacje są czasochłonne i mogą wymagać przełączenie jednego lub większej liczby fragmentów w tryb offline.

Jeśli fragmenty są replikowane, można zachować niektóre repliki w trybie online, podczas gdy inne są podzielone, scalone lub ponownie skonfigurowane. Jednak system może ograniczyć operacje, które można wykonać podczas ponownej konfiguracji. Na przykład dane w replikach mogą być oznaczone jako tylko do odczytu, aby zapobiec niespójnościom danych.

Aby uzyskać więcej informacji, zobacz Sharding pattern (Wzorzec fragmentowania).

Partycjonowanie pionowe

Najczęstszym zastosowaniem partycjonowania pionowego jest zmniejszenie kosztów operacji we/wy i wydajności skojarzonych z pobieraniem często używanych elementów. Na poniższej ilustracji przedstawiono przykład partycjonowania pionowego. W tym przykładzie różne właściwości elementu są przechowywane w różnych partycjach. Jedna partycja przechowuje dane, do których uzyskuje się dostęp częściej, w tym nazwę produktu, opis i cenę. Inna partycja przechowuje dane spisu, w tym liczbę zapasów i ostatnią uporządkowaną datę.

W tym przykładzie aplikacja regularnie wykonuje zapytania dotyczące nazwy produktu, opisu i ceny, gdy wyświetla szczegóły produktu klientom. Liczba akcji i data ostatniego zamówienia znajdują się w oddzielnej partycji, ponieważ te dwa elementy są często używane razem.

Zobacz następujące zalety partycjonowania pionowego:

Możesz oddzielić dane stosunkowo wolno poruszające się (nazwa produktu, opis i cena) od bardziej dynamicznych danych (poziom zapasów i data ostatniej zamówienia). Powolne przenoszenie danych jest dobrym kandydatem do buforowania w pamięci przez aplikację.
Poufne dane można przechowywać w oddzielnej partycji z dodanymi mechanizmami kontroli zabezpieczeń.
Partycjonowanie pionowe może zmniejszyć ilość wymaganego dostępu współbieżnego.

Partycjonowanie pionowe działa na poziomie jednostki w magazynie danych i częściowo normalizuje jednostkę, dzieląc element o szerokim zakresie na zestaw elementów o wąskim zakresie. Idealnie nadaje się do magazynów danych zorientowanych na kolumny, takich jak HBase i Cassandra. Jeśli dane w kolekcji kolumn nie zmienią się, rozważ użycie magazynów kolumn w programie SQL Server.

Partycjonowanie funkcjonalne

Gdy ograniczony kontekst można zidentyfikować dla każdego odrębnego obszaru biznesowego w aplikacji, partycjonowanie funkcjonalne może poprawić wydajność izolacji i dostępu do danych. Innym typowym zastosowaniem partycjonowania funkcjonalnego jest oddzielenie danych odczytu i zapisu od danych tylko do odczytu. Na poniższej ilustracji przedstawiono przegląd partycjonowania funkcjonalnego, który zawiera dane spisu oddzielone od danych klientów.

Ta strategia może zmniejszyć poziom rywalizacji o dostęp do danych w różnych częściach systemu.

Projektowanie partycji pod kątem skalowalności

Ważne jest, aby wziąć pod uwagę rozmiar i obciążenie dla każdej partycji. Zrównoważ je, aby dane były dystrybuowane w celu osiągnięcia maksymalnej skalowalności. Należy jednak również podzielić dane na partycje, aby nie przekraczały limitów skalowania pojedynczego magazynu partycji.

Wykonaj następujące kroki podczas projektowania partycji pod kątem skalowalności:

Przeanalizuj aplikację, aby poznać wzorce dostępu do danych, takie jak rozmiar zestawu wyników zwracanego przez każde zapytanie, częstotliwość dostępu, nieodłączne opóźnienia i wymagania dotyczące przetwarzania obliczeniowego po stronie serwera. W wielu przypadkach kilka głównych jednostek wymaga większości zasobów przetwarzania.
Ta analiza służy do określania bieżących i przyszłych celów skalowalności, takich jak rozmiar danych i obciążenie. Następnie rozmieść dane w partycjach tak, aby osiągnąć tę docelową skalowalność. W przypadku partycjonowania poziomego wybierz odpowiedni klucz fragmentu, aby zapewnić równomierną dystrybucję. Aby uzyskać więcej informacji, zobacz Sharding pattern (Wzorzec fragmentowania).
Upewnij się, że każda partycja ma wystarczającą ilość zasobów, aby obsłużyć wymagania dotyczące skalowalności pod względem rozmiaru i przepływności danych. W zależności od magazynu danych może istnieć limit dla każdej partycji w zakresie ilości miejsca do magazynowania, mocy obliczeniowej lub przepustowości sieci. Jeśli wymagania prawdopodobnie przekroczą te limity, może być konieczne uściślinie strategii partycjonowania lub podzielenie danych dalej. Może być konieczne połączenie co najmniej dwóch strategii.
Monitoruj system, aby sprawdzić, czy dane są dystrybuowane zgodnie z oczekiwaniami i czy partycje mogą obsłużyć obciążenie. Rzeczywiste użycie nie zawsze jest zgodne z przewidywaną analizą. Może być konieczne ponowne równoważenie partycji lub przeprojektowanie niektórych części systemu w celu uzyskania wymaganego salda.

Niektóre środowiska w chmurze przydzielają zasoby na podstawie granic infrastruktury. Upewnij się, że limity wybranej granicy zapewniają wystarczającą ilość miejsca na przewidywany wzrost ilości danych, magazynu danych, mocy obliczeniowej i przepustowości.

Jeśli na przykład używasz usługi Azure Table Storage, istnieje limit liczby żądań, które pojedyncza partycja może obsłużyć w określonym przedziale czasu. Aby uzyskać więcej informacji, zobacz Cele skalowalności i wydajności dla kont magazynu w warstwie Standardowa. Zajęty fragment może wymagać więcej zasobów niż może obsłużyć pojedyncza partycja. Może być konieczne ponowne podzielenie fragmentu w celu rozłożenia obciążenia. Jeśli łączny rozmiar lub przepływność tych tabel przekracza pojemność konta magazynu, może być konieczne utworzenie większej liczby kont magazynu i rozłożenie tabel na tych kontach.

Partycje projektowe pod kątem wydajności zapytań

Wydajność zapytań można zwiększyć przy użyciu małych zestawów danych i uruchamiania zapytań równoległych. Każda partycja powinna zawierać niewielką część całego zestawu danych. Takie zmniejszenie wielkości może poprawić wydajność zapytań. Jednak partycjonowanie nie jest alternatywą dla odpowiedniego projektowania i konfiguracji bazy danych. Upewnij się, że zaimplementowane są niezbędne indeksy.

Wykonaj następujące kroki podczas projektowania partycji pod kątem wydajności zapytań:

Sprawdź wymagania i wydajność aplikacji.
- Użyj wymagań biznesowych, aby określić krytyczne zapytania, które muszą zawsze działać szybko.
- Monitoruj system, aby identyfikować zapytania, które działają wolno.
- Ustal zapytania, które wykonują najczęściej. Nawet jeśli pojedyncze zapytanie ma minimalny koszt, skumulowane użycie zasobów może być znaczące.
Partycjonuj dane, które powodują niską wydajność.
- Ogranicz rozmiar poszczególnych partycji tak, aby uzyskać oczekiwany czas odpowiedzi na zapytanie.
- Jeśli używasz partycjonowania poziomego, zaprojektuj klucz fragmentu, aby aplikacja mogła łatwo wybrać odpowiednią partycję. Ta specyfikacja uniemożliwia skanowanie każdej partycji przez zapytanie.
- Zwróć uwagę na lokalizację partycji. Staraj się przechowywać dane w partycjach, które są geograficznie zbliżone do aplikacji i użytkowników, którzy do niego uzyskują dostęp.
Jeśli jednostka ma wymagania dotyczące przepływności i wydajności zapytań, użyj partycjonowania funkcjonalnego opartego na tej jednostce. Jeśli ta alokacja nadal nie spełnia wymagań, możesz dodać partycjonowanie poziome. Pojedyncza strategia partycjonowania jest zwykle odpowiednia, ale w niektórych przypadkach bardziej wydajne jest łączenie obu strategii.
Uruchamiaj zapytania równolegle między partycjami, aby zwiększyć wydajność.

Partycje projektowe pod kątem dostępności

Partycjonowanie danych w celu zwiększenia dostępności aplikacji. Partycjonowanie gwarantuje, że cały zestaw danych nie ma pojedynczego punktu awarii i można niezależnie zarządzać poszczególnymi podzbiorami zestawu danych.

Rozważ następujące czynniki wpływające na dostępność:

Określ krytyczne znaczenie danych. Zidentyfikuj krytyczne dane biznesowe, takie jak transakcje, oraz mniej krytyczne dane operacyjne, takie jak pliki dziennika.

Przechowywanie krytycznych danych w partycjach o wysokiej dostępności i tworzenie odpowiedniego planu tworzenia kopii zapasowych.
Ustanów oddzielne procedury zarządzania i monitorowania dla różnych zestawów danych.
Umieść dane o tym samym poziomie krytycznym w tej samej partycji, aby można było utworzyć kopię zapasową z taką samą częstotliwością. Na przykład może być konieczne tworzenie kopii zapasowych partycji, które przechowują dane transakcji częściej niż partycje przechowujące informacje rejestrowania lub śledzenia.

Zarządzanie poszczególnymi partycjami. Projektowanie partycji w celu obsługi niezależnego zarządzania i konserwacji. Ta praktyka zapewnia kilka zalet, na przykład:

Jeśli partycja nie powiedzie się, można ją odzyskać niezależnie bez aplikacji, które uzyskują dostęp do danych w innych partycjach.
Partycjonowanie danych według obszaru geograficznego umożliwia wykonywanie zaplanowanych zadań konserwacji poza godzinami szczytu dla każdej lokalizacji. Upewnij się, że partycje nie są tak duże, aby zapobiec zakończeniu planowanej konserwacji w tym okresie.

Replikowanie krytycznych danych między partycjami. Ta strategia zwiększa dostępność i wydajność, ale może również powodować problemy ze spójnością. Synchronizacja zmian z każdą repliką zajmuje trochę czasu. Podczas synchronizacji różne partycje zawierają różne wartości danych.

Zagadnienia dotyczące projektowania aplikacji

Partycjonowanie zwiększa złożoność projektowania i opracowywania systemu. Partycjonowanie danych jako podstawowej części projektu systemu, nawet jeśli system początkowo zawiera tylko jedną partycję. Jeśli adresujesz partycjonowanie jako pokutę, jest to trudne, ponieważ masz już system na żywo do utrzymania. Możesz:

Należy zmodyfikować logikę dostępu do danych.
Należy przeprowadzić migrację dużych ilości istniejących danych, aby rozłożyć je między partycjami.
Napotkaj wyzwania, ponieważ użytkownicy oczekują dalszego korzystania z systemu podczas migracji.

W niektórych przypadkach partycjonowanie nie jest ważne, ponieważ początkowy zestaw danych jest mały, a pojedynczy serwer może go łatwo obsłużyć. Niektóre obciążenia mogą przechodzić bez partycji, ale wiele systemów komercyjnych musi rosnąć wraz ze wzrostem liczby użytkowników.

Niektóre małe magazyny danych również korzystają z partycjonowania. Na przykład setki równoczesnych klientów może uzyskiwać dostęp do małego magazynu danych. Jeśli partycjonujesz dane w tej sytuacji, może to pomóc zmniejszyć rywalizację i zwiększyć przepływność.

Podczas planowania strategii partycjonowania danych należy rozważyć następujące kwestie:

Zminimalizuj operacje dostępu do danych między partycjami. Staraj się zachować dane dla najbardziej typowych operacji bazy danych w partycji, aby zminimalizować operacje dostępu do danych między partycjami. Wykonywanie zapytań między partycjami może być bardziej czasochłonne, a nie wykonywanie zapytań w ramach jednej partycji. Jednak optymalizacja partycji dla jednego zestawu zapytań może niekorzystnie wpłynąć na inne zestawy zapytań. Jeśli musisz wykonywać zapytania między partycjami, zminimalizuj czas zapytania, uruchamiając zapytania równoległe i agregując wyniki w aplikacji. W niektórych przypadkach nie można użyć tego podejścia, na przykład jeśli wynik jednego zapytania zostanie użyty w następnym zapytaniu.

Replikowanie statycznych danych referencyjnych. Jeśli zapytania używają stosunkowo statycznych danych referencyjnych, takich jak tabele kodu pocztowego lub listy produktów, rozważ replikowanie tych danych we wszystkich partycjach, aby zmniejszyć liczbę oddzielnych operacji wyszukiwania w różnych partycjach. Takie podejście może również zmniejszyć prawdopodobieństwo, że dane referencyjne staną się gorącym zestawem danych z dużym ruchem z całego systemu. Istnieją dodatkowe koszty związane z synchronizowaniem zmian w danych referencyjnych.

Zminimalizuj sprzężenia między partycjami. Jeśli jest to możliwe, należy zminimalizować potrzebę zapewnienia więzów integralności w partycjach pionowych i funkcjonalnych. W tych schematach aplikacja jest odpowiedzialna za utrzymanie integralności referencyjnej między partycjami. Zapytania, które łączą dane w wielu partycjach, są nieefektywne, ponieważ aplikacja zazwyczaj wykonuje kolejne zapytania oparte na kluczu, a następnie klucz obcy. Zamiast tego warto rozważyć replikowanie lub denormalizowanie danych. Jeśli konieczne jest sprzężenia między partycjami, uruchom zapytania równoległe na partycjach i dołącz dane w aplikacji.

Uwzględniaj spójność ostateczną. Oceń, czy wymagana jest silna spójność. Typowym podejściem w systemach rozproszonych jest zaimplementowanie spójności ostatecznej. Dane w każdej partycji są aktualizowane oddzielnie, a logika aplikacji gwarantuje pomyślne zakończenie aktualizacji. Logika aplikacji obsługuje również niespójności, które wynikają z wykonywania zapytań dotyczących danych, podczas gdy ostatecznie spójna operacja jest uruchamiana.

Określ, jak zapytania będą znajdować właściwą partycję. Jeśli zapytanie musi skanować wszystkie partycje w celu zlokalizowania wymaganych danych, ma to znaczący wpływ na wydajność, nawet w przypadku uruchamiania wielu zapytań równoległych. W przypadku partycjonowania pionowego i funkcjonalnego zapytania mogą określać partycję. Z drugiej strony partycjonowanie poziome może utrudnić lokalizowanie elementu, ponieważ każdy fragment ma ten sam schemat. Typowym rozwiązaniem jest utrzymywanie mapy używanej do wyszukiwania lokalizacji fragmentów elementów. Zaimplementuj tę mapę w logice fragmentowania aplikacji. Magazyn danych może również być obsługiwany przez magazyn danych, jeśli magazyn danych obsługuje przezroczyste fragmentowanie.

Okresowo ponowne równoważenie fragmentów. Dzięki partycjonowaniu poziomym ponowne równoważenie fragmentów może pomóc równomiernie rozłożyć dane według rozmiaru i obciążenia. Ponowne równoważenie fragmentów w celu zminimalizowania hotspotów, zmaksymalizowania wydajności zapytań i obejścia ograniczeń magazynu fizycznego. To zadanie jest złożone i często wymaga niestandardowego narzędzia lub procesu.

Replikowanie partycji. Replikuj każdą partycję, aby zapewnić dodatkową ochronę przed awarią. Jeśli pojedyncza replika zakończy się niepowodzeniem, zapytania są kierowane do działającej kopii.

Rozszerzanie skalowalności na inny poziom. W przypadku wyczerpania fizycznych ograniczeń określonej strategii partycjonowania może być konieczne rozszerzenie skalowalności na inny poziom. Na przykład jeśli skonfigurowano partycjonowanie na poziomie bazy danych, może być konieczne umieszczenie lub replikowanie partycji w wielu bazach danych. Jeśli partycjonowanie jest już na poziomie bazy danych i istnieją ograniczenia fizyczne, może być konieczne zlokalizowanie lub replikowanie partycji na wielu kontach hostingu.

Należy unikać transakcji wymagających dostępu do danych w wielu partycjach. Niektóre magazyny danych implementują spójność transakcyjną i integralność dla operacji modyfikujących dane, ale tylko wtedy, gdy dane znajdują się w jednej partycji. Jeśli potrzebujesz obsługi transakcyjnej w wielu partycjach, zaimplementuj ją w ramach logiki aplikacji, ponieważ większość systemów partycjonowania nie zapewnia natywnej obsługi.

Wszystkie magazyny danych wymagają wykonywania pewnych zadań związanych z monitorowaniem i zarządzaniem operacyjnym. Te zadania obejmują ładowanie danych, tworzenie kopii zapasowych i przywracanie danych, reorganizację danych oraz zapewnienie prawidłowego i wydajnego działania systemu.

Należy wziąć pod uwagę następujące czynniki mające wpływ na zarządzanie operacyjne:

Zaimplementuj odpowiednie zadania zarządzania i operacyjne podczas partycjonowania danych. Zadania te mogą obejmować tworzenie i przywracanie kopii zapasowych, archiwizowanie danych, monitorowanie systemu i inne czynności administracyjne. Na przykład zachowanie spójności logicznej podczas operacji tworzenia kopii zapasowych i przywracania może być trudne.
Załaduj dane do wielu partycji i dodaj nowe dane pochodzące z innych źródeł. Niektóre narzędzia i narzędzia mogą nie obsługiwać operacji podzielonych na fragmenty danych, takich jak ładowanie danych do właściwej partycji.
Archiwizowanie i usuwanie danych regularnie. Aby zapobiec nadmiernemu wzrostowi partycji, zarchiwizuj i usuń dane co miesiąc. Może być konieczne przekształcenie danych w celu dopasowania ich do innego schematu archiwum.
Znajdź problemy z integralnością danych. Rozważ uruchomienie okresowego procesu lokalizowania problemów z integralnością danych, takich jak dane w jednej partycji, która odwołuje się do brakujących informacji w innej. Proces może automatycznie próbować rozwiązać te problemy lub wygenerować raport na potrzeby ręcznego przeglądu.

Ponowne równoważenie partycji

W miarę dojrzewania systemu może być konieczne dostosowanie schematu partycjonowania. Na przykład poszczególne partycje mogą zacząć otrzymywać nieproporcjonalną ilość ruchu i stać się gorące, co prowadzi do nadmiernej rywalizacji. Możesz też lekceważyć ilość danych w niektórych partycjach, co powoduje, że partycje zbliżają się do limitów pojemności.

Niektóre magazyny danych, takie jak Azure Cosmos DB, mogą automatycznie ponownie równoważyć partycje. W innych przypadkach można ponownie zrównoważyć partycje w dwóch etapach:

Określ nową strategię partycjonowania.
- Które partycje muszą być podzielone lub połączone?
- Jaki jest nowy klucz partycji?
Migrowanie danych ze starego schematu partycjonowania do nowego zestawu partycji.

Podczas przenoszenia danych może być konieczne uczynienie partycji niedostępnymi, co jest nazywane migracją w trybie offline. W zależności od magazynu danych można migrować dane między partycjami, gdy są one używane. Ta technika jest nazywana migracją online.

Migracja w trybie offline

Migracja w trybie offline zmniejsza prawdopodobieństwo wystąpienia rywalizacji. Aby przeprowadzić migrację w trybie offline:

Oznacz partycję jako offline. Partycję można oznaczyć jako tylko do odczytu, aby aplikacje mogły nadal odczytywać dane podczas przenoszenia.
Scalanie i przenoszenie danych do nowych partycji.
Verify the data.
Przełącz nowe partycje w tryb online.
Usuń starą partycję.

Migracja w trybie online

Migracja online jest bardziej złożona, ale mniej destrukcyjna w porównaniu z migracją w trybie offline. Proces jest podobny do migracji w trybie offline, ale nie oznaczasz oryginalnej partycji jako offline. W zależności od stopnia szczegółowości procesu migracji, na przykład elementu według elementu i fragmentu według fragmentu, kod dostępu do danych w aplikacjach klienckich może być musiał odczytywać i zapisywać dane w dwóch lokalizacjach, oryginalną partycję i nową partycję.

Ułatwienia platformy Azure

W poniższych sekcjach opisano zalecenia dotyczące partycjonowania danych przechowywanych w usługach platformy Azure.

Partycjonowanie w usłudze Azure SQL Database

Ilość danych, które może zawierać jedna baza danych SQL, jest ograniczona. Czynniki związane z architekturą oraz liczba obsługiwanych połączeń współbieżnych ograniczają przepływność.

Pule elastyczne obsługują skalowanie w poziomie dla bazy danych SQL. Użyj elastycznych pul, aby podzielić dane na fragmenty rozłożone na wiele baz danych SQL. Możesz również dodawać lub usuwać fragmenty w miarę wzrostu i zmniejszania ilości danych. Elastyczne pule mogą również pomóc zmniejszyć rywalizację poprzez dystrybucję obciążenia między bazami danych.

Każdy fragment jest wdrażany jako oddzielna baza danych SQL. Fragment może zawierać więcej niż jeden zestaw danych. Każdy zestaw danych jest nazywany fragmentem. Każda baza danych zawiera metadane opisujące zawarte w niej podfragmenty. Fragmentlet może być pojedynczym elementem danych lub grupą elementów, które współużytkujące ten sam klucz fragmentu. Na przykład w aplikacji wielodostępnej klucz podfragmentu może być identyfikatorem dzierżawy, a wszystkie dane dzierżawy mogą znajdować się w tym samym podfragmentie.

Aplikacje są odpowiedzialne za kojarzenie zestawu danych z kluczem podfragmentu. Funkcję globalnego menedżera mapowań fragmentów pełni oddzielna baza danych SQL. Ta baza danych zawiera listę wszystkich fragmentów i fragmentów w systemie. Aplikacja łączy się z bazą danych menedżera map fragmentów w celu uzyskania kopii mapy fragmentów. Buforuje ona mapę fragmentów lokalnie i używa mapy do kierowania żądań danych do odpowiedniego fragmentu. Ta funkcja jest ukryta za serią interfejsów API, które znajdują się w bibliotece klienta funkcji Elastic Database usługi SQL Database, która jest dostępna dla języków Java i .NET.

Aby uzyskać więcej informacji na temat elastycznych pul, zobacz Skalowanie w górę za pomocą usługi SQL Database.

Aby zmniejszyć opóźnienia i zwiększyć dostępność, można replikować globalną bazę danych menedżera map fragmentów. W warstwach cenowych Premium można skonfigurować aktywną replikację geograficzną, aby stale kopiować dane do baz danych w różnych regionach.

Alternatywnie użyj usługi SQL Data Sync dla usługi SQL Database lub Azure Data Factory , aby replikować bazę danych menedżera map fragmentów w różnych regionach. Ta forma replikacji jest okresowo uruchamiana i jest bardziej odpowiednia, jeśli mapa fragmentów zmienia się rzadko i nie wymaga warstwy Premium.

Funkcja Elastic Database udostępnia dwa schematy mapowania danych na podfragmenty i przechowywania ich we fragmentach:

Mapa fragmentów listy kojarzy pojedynczy klucz z podfragmentem. Na przykład w systemie wielodostępnym dane każdej dzierżawy mogą być skojarzone z unikatowym kluczem i przechowywane w oddzielnym podfragmencie. Aby zagwarantować izolację, każdy fragment może być przechowywany w ramach własnego fragmentu.

Pobierz plik programu Visio z tego diagramu.
Mapa fragmentów zakresu kojarzy zestaw ciągłych wartości kluczy z fragmentem. Na przykład można grupować dane dla zestawu dzierżaw, z których każdy ma własny klucz, w ramach tego samego fragmentu. Ten schemat jest mniej kosztowny niż mapa fragmentów listy, ponieważ dzierżawcy współdzielą magazyn danych, ale zapewnia mniej izolacji.

Pobieranie pliku programu Visio z tego diagramu

Pojedynczy fragment może zawierać dane dla kilku fragmentów. Można na przykład użyć podfragmentów z mapowaniem w postaci listy do przechowywania danych różnych, niesąsiadujących ze sobą dzierżaw w jednym fragmencie. Można również mieszać fragmentlety zakresów i podfragmenty listy w tym samym fragmentzie, ale następnie są one adresowane za pomocą różnych map. Na poniższym diagramie przedstawiono takie podejście:

Pobierz plik programu Visio z tego diagramu.

Dzięki elastycznym pulam można dodawać i usuwać fragmenty w miarę wzrostu i zmniejszania ilości danych. Aplikacje klienckie mogą tworzyć i usuwać fragmenty dynamicznie i w sposób przezroczysty aktualizować menedżera map fragmentów. Jednak usunięcie fragmentu jest operacją destrukcyjną, która wymaga również usunięcia wszystkich danych zawartych w tym fragmencie.

Jeśli aplikacja musi podzielić fragment na dwa oddzielne fragmenty lub połączyć fragmenty, użyj narzędzia split-merge. To narzędzie działa jako usługa internetowa platformy Azure i bezpiecznie migruje dane między fragmentami.

Schemat partycjonowania może znacząco wpłynąć na wydajność systemu. Może to również mieć wpływ na szybkość dodawania lub usuwania fragmentów albo ponowne partycjonowanie danych między fragmentami. Rozważ następujące punkty:

Grupuj dane używane razem w tym samym fragmentzie i unikaj operacji, które uzyskują dostęp do danych z wielu fragmentów. Fragment jest własną bazą danych SQL, a sprzężenia między bazami danych muszą być wykonywane po stronie klienta, gdy operacje uzyskują dostęp do wielu fragmentów.

Chociaż usługa SQL Database nie obsługuje sprzężeń między bazami danych, można użyć narzędzi elastic database do wykonywania zapytań obejmujących wiele fragmentów. Zapytanie obejmujące wiele fragmentów wysyła poszczególne zapytania do każdej bazy danych i scala wyniki.
Zaprojektuj system, który nie ma zależności między fragmentami. Ograniczenia integralności referencyjnej, wyzwalacze i procedury składowane w jednej bazie danych nie mogą odwoływać się do obiektów w innej bazie danych.
Rozważ replikowanie danych między fragmentami, jeśli masz dane referencyjne, które są często używane przez zapytania. Takie podejście może wyeliminować konieczność łączenia danych między bazami danych. W idealnym przypadku takie dane powinny być statyczne lub wolno przenoszone, aby zminimalizować nakład pracy związany z replikacją i zmniejszyć prawdopodobieństwo ich nieaktualności.
Użyj tego samego schematu dla fragmentów, które należą do tej samej mapy fragmentów. Te wskazówki nie są wymuszane przez usługę SQL Database, ale zarządzanie danymi i wykonywanie zapytań jest złożone, jeśli każdy fragmentlet ma inny schemat. Zamiast tego utwórz oddzielne mapy fragmentów dla każdego schematu. Dane należące do różnych fragmentów można przechowywać w tym samym fragmentzie.
Przechowuj dane w tym samym fragmentze lub implementuj spójność ostateczną, jeśli logika biznesowa musi wykonywać transakcje. Operacje transakcyjne są obsługiwane tylko w przypadku danych, które znajdują się w fragmentach, a nie we fragmentach. Transakcje mogą obejmować fragmenty, jeśli są częścią tego samego fragmentu.
Umieść fragmenty w pobliżu użytkowników, którzy uzyskują dostęp do danych w tych fragmentach. Ta strategia umożliwia zminimalizowanie opóźnień.
Unikaj łączenia bardzo aktywnych i stosunkowo nieaktywnych fragmentów. Należy dążyć do równomiernego rozłożenia obciążenia fragmentów. Być może trzeba będzie utworzyć skrót kluczy fragmentowania. Jeśli lokalizujesz fragmenty geograficzne, upewnij się, że skróty kluczy są mapowane na fragmenty przechowywane w fragmentach przechowywanych blisko użytkowników, którzy uzyskują dostęp do tych danych.

Partycja w usłudze Azure Blob Storage

Za pomocą usługi Blob Storage można przechowywać duże obiekty binarne. Blokowe obiekty blob można używać w scenariuszach, które wymagają szybkiego przekazywania lub pobierania dużych ilości danych. Użyj stronicowych obiektów blob dla aplikacji, które wymagają losowego, a nie szeregowego dostępu do części danych.

Każdy blokowy obiekt blob lub stronicowy obiekt blob jest przechowywany w kontenerze na koncie usługi Azure Storage. Użyj kontenerów do grupowania powiązanych obiektów blob, które mają te same wymagania dotyczące zabezpieczeń. To grupowanie ma charakter logiczny, a nie fizyczny. Każdy obiekt blob w kontenerze ma unikatową nazwę.

Klucz partycji dla obiektu blob to nazwa konta, nazwa kontenera i nazwa obiektu blob. Klucz partycji służy do partycjonowania danych w zakresy. Te zakresy są ze zrównoważonym obciążeniem w całym systemie. Obiekty blob można dystrybuować na wielu serwerach, aby skalować do nich dostęp w poziomie. Pojedynczy obiekt blob może być obsługiwany tylko przez jeden serwer.

Jeśli schemat nazewnictwa używa sygnatur czasowych lub identyfikatorów liczbowych, może to prowadzić do nadmiernego ruchu do jednej partycji. Zapobiega to efektywnemu równoważeniu obciążenia przez system. Jeśli na przykład masz codzienne operacje używające obiektu blob z sygnaturą czasową, taką jak rrrr-mm-dd, cały ruch dla tej operacji przechodzi do pojedynczego serwera partycji. Zamiast tego prefiks nazwy z trzycyfrowym skrótem. Aby uzyskać więcej informacji, zobacz Konwencja nazewnictwa partycji.

Akcje zapisu pojedynczego bloku lub strony są niepodzielne, ale operacje obejmujące bloki, strony lub obiekty blob nie są. Jeśli musisz zapewnić spójność podczas wykonywania operacji zapisu w blokach, stronach i obiektach blob, wyjmij blokadę zapisu przy użyciu dzierżawy obiektu blob.

Kwestie wymagające rozważenia

Partycjonowanie danych wprowadza pewne wyzwania i złożoność, które należy wziąć pod uwagę.

Synchronizacja danych między partycjami może stanowić wyzwanie. Upewnij się, że aktualizacje lub zmiany w jednej partycji są propagowane do innych partycji w odpowiednim czasie i spójnie.
Procesy trybu failover i odzyskiwania po awarii stają się złożone, gdy trzeba koordynować tworzenie kopii zapasowych i przywracanie wielu partycji. Problemy z integralnością danych mogą wystąpić, jeśli niektóre partycje lub ich kopie zapasowe są uszkodzone lub niedostępne.
Partycjonowanie danych może mieć wpływ na wydajność i niezawodność, jeśli musisz wykonywać zapytania między partycjami, a podczas ponownego równoważenia partycji, jeśli dane rosną nierównomiernie.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności

Udostępnij za pośrednictwem

Zalecenia dotyczące partycjonowania danych