Zalecenia dotyczące partycjonowania danych

Artykuł
11/15/2023

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

RE:06	Zaimplementuj strategię terminowego i niezawodnego skalowania na poziomie aplikacji, danych i infrastruktury.

Powiązany przewodnik:Skalowanie

W tym przewodniku opisano zalecenia dotyczące projektowania strategii partycjonowania danych dla wdrożonej technologii magazynu danych i bazy danych. Ta strategia pomaga zwiększyć niezawodność twoich twoich 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 niej dostęp oddzielnie. Partycjonowanie danych zwiększa skalowalność, zmniejsza rywalizację i optymalizuje wydajność. Zaimplementuj partycjonowanie danych, aby podzielić dane według wzorca użycia. Na przykład możesz archiwizować starsze dane w niedrogim magazynie danych. Starannie wybierz strategię partycjonowania, aby zmaksymalizować korzyści i zminimalizować negatywne skutki.

Uwaga

W tym artykule określenie partycjonowanie oznacza proces fizycznego dzielenia danych pomiędzy odrębne magazyny danych. Różni się od partycjonowania tabeli 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 na wiele partycji, z każdą partycją hostowaną na osobnym serwerze, możesz skalować system niemal bezterminowo.
Zwiększ 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 podzielić na partycje, 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. Ta kwestia jest mniej istotna w przypadku magazynów danych platformy zarządzanej 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 podzestaw danych, na przykład zestaw zamówień klientów.
Partycjonowanie w pionie. 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 używa 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 zwiększa wydajność.

Najważniejszym czynnikiem jest wybrany klucz fragmentowania. Gdy system będzie już działał, zmiana klucza może być trudna. Klucz musi mieć pewność, że dane są podzielone na partycje, aby rozłożyć obciążenie tak równomiernie, jak to możliwe w obrębie fragmentów.

Fragmenty nie muszą być takie same. 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 każdy element w fragmentach jest uzyskiwany częściej. Ważne jest również, aby upewnić się, że pojedynczy fragment nie przekracza limitów skalowania, pod względem 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 utworzyć rozkład niezrównoważony, 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 w pionie 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 wysyła zapytania dotyczące nazwy produktu, opisu i ceny, gdy wyświetla szczegóły produktu klientom. Liczba zapasów i data ostatniej kolejności znajdują się w oddzielnej partycji, ponieważ te dwa elementy są często używane razem.

Zapoznaj się z następującymi zaletami partycjonowania pionowego:

Możesz oddzielić stosunkowo wolno poruszające się dane (nazwa produktu, opis i cena) z bardziej dynamicznych danych (poziom zapasów i data ostatniej zamówienia). Powolne przenoszenie danych jest dobrym kandydatem aplikacji do buforowania w pamięci.
Poufne dane można przechowywać w oddzielnej partycji z dodanymi mechanizmami kontroli zabezpieczeń.
Partycjonowanie w pionie 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 będą się zmieniać, rozważ użycie magazynów kolumn w 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 omówienie partycjonowania funkcjonalnego zawierającego dane spisu oddzielone od danych klienta.

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

Należy wziąć pod uwagę rozmiar i obciążenie dla każdej partycji. Zrównoważ je, aby dane mogły być 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.
Użyj tej analizy, aby określić bieżące i przyszłe cele skalowalności, takie 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 danych i przepływności. 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 mogą przekroczyć te limity, może być konieczne uściślinie strategii partycjonowania lub dalsze dzielenie danych. 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 dotyczące 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. Aby rozłożyć obciążenie, może być konieczne ponowne podzielenie fragmentu. 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.

Projektowanie partycji 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.
- Określ zapytania, które wykonują najczęściej. Nawet jeśli pojedyncze zapytanie ma minimalny koszt, skumulowane zużycie zasobów może być znaczące.
Partycjonowanie danych, 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. Spróbuj zachować dane w partycjach, które znajdują się geograficznie blisko aplikacji i użytkowników, którzy do niej 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 w poziomie. Pojedyncza strategia partycjonowania jest zwykle odpowiednia, ale w niektórych przypadkach bardziej wydajne jest łączenie obu strategii.
Uruchom 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 krytyczność danych. Zidentyfikuj krytyczne dane biznesowe, takie jak transakcje, oraz mniej krytyczne dane operacyjne, takie jak pliki dziennika.

Przechowuj dane krytyczne w partycjach o wysokiej dostępności i utwórz odpowiedni plan 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ą w tej samej 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 rejestrowanie lub informacje dotyczące ś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 ulegnie awarii, 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ą kontynuowania 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 łatwo go 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 korzystają również 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:

Minimalizuj operacje dostępu do danych między partycjami. Spróbuj 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 negatywnie 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 z jednego zapytania jest używany 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 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 zwykle wykonuje kolejne zapytania oparte na kluczu, a następnie klucz obcy. Zamiast tego warto rozważyć replikowanie lub denormalizowanie danych. Jeśli sprzężenia między partycjami są niezbędne, 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 wykonywana jest spójna operacja.

Określ, jak zapytania będą znajdować właściwą partycję. Jeśli zapytanie musi skanować wszystkie partycje w celu zlokalizowania wymaganych danych, znacząco wpływa to 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 utrzymanie mapy używanej do wyszukiwania lokalizacji fragmentów elementów. Zaimplementuj tę mapę w logice fragmentowania aplikacji. Magazyn danych może być również 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 obszarów aktywności, 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ą. W przypadku niepowodzenia pojedynczej repliki 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ść operacji modyfikujących dane, ale tylko wtedy, gdy dane znajdują się w jednej partycji. Jeśli potrzebujesz obsługi transakcyjnej na wielu partycjach, zaimplementuj ją jako część 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, gdy dane są partycjonowane. 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 danych podzielonych na fragmenty, takich jak ładowanie danych do właściwej partycji.
Regularnie archiwizować i usuwać dane. 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.
Zlokalizuj 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 do ręcznego przeglądu.

Ponowne równoważenie partycji

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

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

Określ nową strategię partycjonowania.
- Które partycje należy podzielić lub połączyć?
- Co to jest nowy klucz partycji?
Migrowanie danych ze starego schematu partycjonowania do nowego zestawu partycji.

Może być konieczne, aby partycje są niedostępne podczas przenoszenia danych, co jest nazywane migracją w trybie offline. W zależności od magazynu danych można migrować dane między partycjami, gdy są 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.
Podziel scalanie i przenieś dane do nowych partycji.
Weryfikacja danych.
Przełącz nowe partycje w tryb online.
Usuń starą partycję.

Migracja w trybie online

Migracja online jest bardziej złożona, ale mniej uciążliwa 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 dla platformy Azure

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

Partycja 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 rozmieszczone w wielu bazach danych SQL. W miarę zwiększania i zmniejszania ilości danych można również dodawać lub usuwać fragmenty. Elastyczne pule mogą również pomóc zmniejszyć rywalizację przez rozłożenie 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 podfragmentem. Każda baza danych zawiera metadane opisujące zawarte w nim podfragmenty. Podfragment może być pojedynczym elementem danych lub grupą elementów, które współużytkujące ten sam klucz podfragmentu. 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 podfragmentów w systemie. Aplikacja łączy się z bazą danych menedżera map fragmentów w celu uzyskania kopii mapy fragmentów. Buforuje ona lokalnie mapę fragmentów 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 SQL Database, która jest dostępna dla języków Java i .NET.

Aby uzyskać więcej informacji na temat pul elastycznych, zobacz Skalowanie w pęk wyprzedanie za pomocą SQL Database.

Aby zmniejszyć opóźnienie 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.

Możesz też użyć SQL Data Sync, aby SQL Database lub Azure Data Factory replikować bazę danych menedżera map fragmentów między regionami. 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 podfragment 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 podfragmentem. Na przykład można grupować dane dla zestawu dzierżaw, z których każdy ma własny klucz, w ramach tego samego podfragmentu. Ten schemat jest mniej kosztowny niż mapa fragmentów listy, ponieważ dzierżawcy współdzielą magazyn danych, ale zapewnia mniej izolacji.

Pobierz plik programu Visio z tego diagramu

Pojedynczy fragment może zawierać dane dla kilku podfragmentó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ć podfragmenty zakresu i podfragmenty listy w tym samym fragmentze, ale następnie są one adresowane za pomocą różnych map. Na poniższym diagramie przedstawiono to podejście:

Pobierz plik programu Visio z tego diagramu.

Dzięki elastycznym pulam można dodawać i usuwać fragmenty w miarę zwiększania 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.

Mimo że 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.
Projektowanie systemu, 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 podfragmentów należących do tej samej mapy fragmentów. Te wskazówki nie są wymuszane przez SQL Database, ale zarządzanie danymi i wykonywanie zapytań jest złożone, jeśli każdy podfragment ma inny schemat. Zamiast tego utwórz oddzielne mapy fragmentów dla każdego schematu. Dane należące do różnych podfragmentów można przechowywać w tym samym fragmentze.
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ć podfragmenty, 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 kombinacji 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 podfragmenty przechowywane w fragmentach przechowywanych blisko użytkowników, którzy uzyskują dostęp do tych danych.

Partycjonowanie w Azure Blob Storage

Za pomocą usługi Blob Storage można przechowywać duże obiekty binarne. Blokowe obiekty blob należy 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 obiektu blob to nazwa konta, nazwa kontenera i nazwa obiektu blob. Klucz partycji służy do partycjonowania danych na zakresy. Te zakresy są zrównoważone 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. Uniemożliwia to systemowi efektywne równoważenie obciążenia. Jeśli na przykład masz codzienne operacje, które używają obiektu blob ze znacznikiem czasu, takim jak rrrr-mm-dd, cały ruch dla tej operacji jest kierowany do pojedynczego serwera partycji. Zamiast tego przedrostek nazwy z trzycyfrowym skrótem. Aby uzyskać więcej informacji, zobacz Partition naming convention (Konwencja nazewnictwa partycji).

Akcje pisania pojedynczego bloku lub strony są niepodzielne, ale operacje obejmujące bloki, strony lub obiekty blob nie są. Jeśli chcesz zapewnić spójność podczas wykonywania operacji zapisu między blokami, stronami i obiektami blob, wyjąć blokadę zapisu przy użyciu dzierżawy obiektu blob.

Zagadnienia do 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 stać się wyzwaniem. Upewnij się, że aktualizacje lub zmiany w jednej partycji są propagowane do innych partycji w odpowiednim czasie i spójny sposób.
Procesy przechodzenia w tryb 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 trzeba 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

Zalecenia dotyczące partycjonowania danych