Zalecenia dotyczące partycjonowania danych

Artykuł
03/05/2025

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

RE:06	Zaimplementuj terminową i niezawodną strategię skalowania na poziomie aplikacji, danych i infrastruktury. Bazuj strategię skalowania na rzeczywistych lub przewidywanych wzorcach użycia i minimalizuj interwencję ręczną.

Powiązany przewodnik :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.

Notatka

W tym artykule termin partycjonowanie oznacza proces fizycznego dzielenia danych na oddzielne repozytoria danych. Różni się ona od partycjonowania tabel programu SQL Server.

Możesz podzielić dane na partycje, aby:

Zwiększ 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, przy czym każda z nich jest hostowana na osobnym serwerze, możesz rozbudowywać system prawie w nieskończoność.
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. Operacje, które mają wpływ na więcej niż jedną partycję, mogą być uruchamiane równolegle.
Zwiększ 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.
Zapewnienie elastyczności operacyjnej. 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.
Dopasuj magazyn danych do wzorca użycia. 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 blob i zapisywać dane ustrukturyzowane w bazie danych dokumentów. Aby uzyskać więcej informacji, zobacz Omówienie modeli magazynu danych.
Zwiększ 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ść.

Wybieranie odpowiedniej strategii partycjonowania

Istnieją trzy typowe strategie partycjonowania danych:

Partycjonowanie poziome (często nazywane shardingiem). W tej strategii każda partycja jest oddzielnym magazynem danych, ale wszystkie partycje mają ten sam schemat. Każda partycja jest znana jako fragment i przechowuje podzestaw danych, takich jak zestaw zamówień klientów.
Partycjonowanie pionowe. W tej strategii każda partycja zawiera podzestaw pól dla elementów w magazynie danych. Pola są podzielone zgodnie z ich wzorcem użycia. Na przykład często używane pola mogą być umieszczane w jednej partycji pionowej i rzadziej używane pola w innym.
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żesz na przykład podzielić dane na fragmenty, a następnie użyć partycjonowania pionowego, aby dalej podzielić dane 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 przechowuje dane dla ciągłego zakresu kluczy (A-G i H-Z), uporządkowane alfabetycznie. 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. Zmiana klucza po uruchomieniu systemu 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. Również ważne jest, 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ść. Na przykład, jeśli używasz pierwszej litery imienia klienta, może ona spowodować niezrównoważoną dystrybucję, 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 wzorzec fragmentowania .

Partycjonowanie pionowe

Najczęstszym zastosowaniem partycjonowania pionowego jest zmniejszenie kosztów operacji we/wy oraz wpływu na wydajność, związanych 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 inwentaryzacyjne, w tym stan magazynowy i ostatnią datę zamówienia.

W tym przykładzie aplikacja regularnie wykonuje zapytania dotyczące nazwy produktu, opisu i ceny, gdy wyświetla szczegóły produktu klientom. Stan magazynowy i data ostatniego zamówienia znajdują się w osobnej 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). Dane o wolnym przepływie są 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, częściowo normalizując jednostkę w celu podzielenia jej z szerokiego elementu na zestaw elementów wąskich. 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 partycjonowania może pomóc zmniejszyć rywalizację 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 rozłóż dane między partycje, aby spełnić cel skalowalności. W przypadku partycjonowania poziomego wybierz odpowiedni klucz shardu, aby zapewnić równomierną dystrybucję. Aby uzyskać więcej informacji, zobacz 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 dotyczące skalowalności i wydajności dla kont magazynowych w standardowej warstwie. 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.

Projektowanie partycji dla 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. Ta redukcja woluminu może zwiększyć 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, które zapytania są wykonywane najczęściej. Nawet jeśli pojedyncze zapytanie ma minimalny koszt, skumulowane użycie zasobów może być znaczące.
Podziel dane, które powodują wolne działanie.
- Ogranicz rozmiar każdej partycji, aby czas odpowiedzi zapytania mieścił się w obszarze docelowym.
- Jeśli używasz partycjonowania poziomego, zaprojektuj klucz fragmentu, aby aplikacja mogła łatwo wybrać odpowiednią partycję. Ta specyfikacja uniemożliwia zapytaniu skanowanie każdej partycji.
- Rozważ 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ść.

Zaprojektuj partycje 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. Zaprojektuj partycje, aby wspierać niezależne zarządzanie oraz konserwację. Ta praktyka zapewnia kilka zalet, na przykład:

Jeśli partycja ulegnie awarii, można ją odzyskać niezależnie, bez konieczności używania programów, 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.

Replikuj krytyczne dane w poprzek partycji. 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.

Optymalizowanie kodu aplikacji pod kątem używania partycji

Partycjonowanie zwiększa złożoność projektowania i opracowywania systemu. Traktuj partycjonowanie danych jako podstawową część projektu systemu, nawet jeśli system początkowo zawiera tylko jedną partycję. Jeśli traktujesz partycjonowanie jako rzecz drugorzędną, staje się to wyzwaniem, ponieważ masz już działający system, który trzeba utrzymać. 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ą funkcjonować bez partycji, ale wiele systemów komercyjnych musi się zwiększać 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 projektowania schematu partycjonowania danych należy wziąć pod uwagę 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 niż 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 o dużym ruchu w całym systemie. Istnieją dodatkowe koszty związane z synchronizowaniem zmian w danych referencyjnych.

Zminimalizuj sprzężenia między partycjami. Jeśli to możliwe, zminimalizuj wymagania dotyczące integralności referencyjnej 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 należy rozważyć replikowanie lub anulowanie normalizacji odpowiednich danych. Jeśli konieczne jest łączenie między partycjami, uruchom zapytania równoległe na partycjach i połącz dane w aplikacji.

Zaakceptuj 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.

Zastanów się, jak zapytania lokalizują poprawną 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. Może to być również utrzymywane przez magazyn danych, jeśli obsługuje on 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. Jeśli osiągniesz fizyczne limity strategii partycjonowania, może być konieczne rozszerzenie skalowalności na inny poziom. Jeśli na przykład partycjonowanie znajduje się na poziomie bazy danych, może być konieczne zlokalizowanie 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.

Unikaj transakcji, które uzyskują dostęp 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ą działania zarządzania operacyjnego i monitorowania. Te zadania obejmują ładowanie danych, tworzenie kopii zapasowych i przywracanie danych, reorganizację danych oraz zapewnienie prawidłowego i wydajnego działania systemu.

Rozważ następujące czynniki wpływające na zarządzanie operacyjne:

Zaimplementuj odpowiednie zadania zarządzania i operacyjne podczas partycjonowania danych. Te zadania mogą obejmować tworzenie kopii zapasowych i przywracanie, archiwizowanie danych, monitorowanie systemu i inne zadania 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ę przeciążone, co prowadzi do nadmiernej konkurencji. 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 sprawienie, że partycje będą niedostępne, co jest nazywane migracją offline. W zależności od magazynu danych można migrować dane między partycjami, gdy są one używane. Ta technika jest nazywana migracji 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.
Dzielenie, scalanie i przenoszenie danych do nowych partycji.
Zweryfikuj dane.
Przełącz nowe partycje w tryb online.
Usuń starą partycję.

Migracja 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 element po elemencie lub fragment po fragmencie, kod dostępu do danych w aplikacjach klienckich być może będzie musiał odczytywać i zapisywać dane w dwóch lokalizacjach: w oryginalnej partycji i w nowej partycji.

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

Pojedyncza baza danych SQL ma limit ilości danych, które może zawierać. Przepływność jest ograniczona przez czynniki architektoniczne i liczbę współbieżnych połączeń, które obsługuje.

Elastyczne pule obsługują funkcję skalowania 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 implementowany jako 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 fragmenty danych (shardlets), które zawiera. Shardlet może być pojedynczym elementem danych lub grupą elementów, które współdzielą ten sam klucz shardlet. Na przykład w aplikacji wielodostępnej klucz podfragmentu może być identyfikatorem najemcy, a wszystkie dane najemcy mogą znajdować się w tym samym podfragmentie.

Aplikacje są odpowiedzialne za kojarzenie zestawu danych z kluczem podfragmentu. Oddzielna baza danych SQL działa jako globalny menedżer mapy fragmentów. Ta baza danych zawiera listę wszystkich fragmentów i mikrofragmentów w systemie. Aplikacja łączy się z bazą danych menedżera mapy 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.

Więcej informacji na temat elastycznych pul znajdziesz w Skalowanie 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 usługi 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.

Elastyczna baza danych udostępnia dwa schematy mapowania danych na fragmenty i przechowywania ich w fragmentach:

Mapa fragmentów typu lista przypisuje pojedynczy klucz do fragmentu. Na przykład w systemie wielodostępnym dane dla każdego najemcy mogą być skojarzone z unikatowym kluczem i przechowywane w osobnym kawałku danych. Aby zagwarantować izolację, każdy mikrofragment może być przechowywany w ramach własnej części.

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

Pobierz plik Visio tego diagramu

Pojedynczy fragment może zawierać dane dla kilku podfragmentów. Na przykład można użyć fragmentów listy do przechowywania danych dla różnych dzierżaw nieciągłych w tym samym fragmentzie. Można również mieszać fragmenty zakresowe i fragmenty list w tym samym fragmencie, ale są one wtedy adresowane za pomocą różnych map. Na poniższym diagramie przedstawiono takie podejście:

Pobierz plik programu Visio 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ą destruktywną, która wymaga również usunięcia wszystkich danych w tym fragmentzie.

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 kwestie:

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 usługa SQL Database nie obsługuje sprzężeń między bazami danych, można użyć narzędzi Elastic Database do wykonywania zapytań wieloodłamkowych. Zapytanie wielofragmentowe 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 shardletó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 podziałek ma inny schemat. Zamiast tego utwórz oddzielne mapy fragmentów dla każdego schematu. Dane należące do różnych odłamków można przechowywać w tym samym fragmencie.
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 shardach, a nie pomiędzy shardami. Transakcje mogą obejmować shardlety, jeśli są częścią tego samego shardu.
Umieść fragmenty w pobliżu użytkowników, którzy uzyskują dostęp do danych w tych fragmentach. Ta strategia pomaga zmniejszyć opóźnienie.
Unikaj łączenia bardzo aktywnych i stosunkowo nieaktywnych fragmentów. Spróbuj równomiernie rozłożyć obciążenie na fragmenty. Być może trzeba będzie zhashować klucze fragmentowania. Jeśli lokalizujesz fragmenty geograficznie, upewnij się, że haszowane klucze są mapowane na części fragmentów przechowywane w fragmentach zlokalizowanych 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. Bloki blob można używać w scenariuszach, które wymagają szybkiego przesyłania 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 obiekt blob typu blokowego lub stronicowego jest przechowywany w kontenerze na koncie Azure Storage. Użyj kontenerów do grupowania powiązanych obiektów blob, które mają te same wymagania dotyczące zabezpieczeń. To grupowanie jest logiczne, a nie fizyczne. Wewnątrz kontenera każdy obiekt typu blob 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ą równomiernie rozłożone w całym systemie. Obiekty blob można dystrybuować na wielu serwerach, aby zwiększyć dostęp do nich. 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 w jednej partycji. Zapobiega to efektywnemu równoważeniu obciążenia przez system. Jeśli na przykład masz codzienne procesy, które używają obiektu blob ze znacznikiem czasu, takim jak yyyy-mm-dd, cały ruch dla tego procesu jest kierowany do jednego serwera partycji. Zamiast tego poprzedź nazwę trzycyfrowym skrótem. Aby uzyskać więcej informacji, zobacz Partition naming convention.

Czynności 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, uzyskaj blokadę zapisu korzystając z dzierżawy obiektu blob.

Zagadnienia dotyczące

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 przełączania awaryjnego i odzyskiwania po awarii stają się złożone, gdy trzeba koordynować wykonywanie 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 niezawodności

Udostępnij za pośrednictwem

Zalecenia dotyczące partycjonowania danych

Kluczowe strategie projektowania