Wskazówki dotyczące partycjonowania danych

W wielu rozwiązaniach na dużą skalę dane są podzielone na partycje , które można zarządzać i uzyskiwać do ich dostępu oddzielnie. Partycjonowanie może zwiększyć skalowalność, zmniejszyć stopień rywalizacji o zasoby i zoptymalizować wydajność. Może także zapewnić mechanizm dzielenia danych według wzorca użycia. Na przykład starsze dane można zarchiwizować w tańszym magazynie danych.

Jednak strategia partycjonowania musi być starannie wybrana, aby zmaksymalizować korzyści przy jednoczesnym zminimalizowaniu negatywnych skutków.

Cele partycjonowania danych

• Zwiększyć skalowalność. Skalowanie w górę jednego systemu bazy danych prowadzi ostatecznie do wyczerpania fizycznych ograniczeń sprzętowych. W przypadku dzielenia danych między wiele partycji, z których każda jest hostowana na osobnym serwerze, można skalować system niemal w nieskończoność.

• Zwiększyć wydajność. Operacje dostępu do danych w poszczególnych partycjach obejmują mniejszą ilość danych. Poprawnie wykonane partycjonowanie może zwiększyć wydajność 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. Partycjonowanie oferuje wiele możliwości dostrajania operacji, maksymalizację wydajności administracyjnej i minimalizację kosztów. Można na przykład zdefiniować różne strategie zarządzania, monitorowania, tworzenia i przywracania kopii zapasowych oraz wykonywania innych zadań administracyjnych, które będą stosowane w zależności od ważności danych w poszczególnych partycjach.

• Dostosować rodzaj magazynu danych do sposobu użycia danych. Poszczególne partycje mogą być wdrażane w różnych typach magazynów danych, oferujących różne wbudowane funkcje przy różnych kosztach. Na przykład duże dane binarne mogą być przechowywane w magazynie obiektów blob, podczas gdy bardziej ustrukturyzowane dane mogą być przechowywane w bazie danych dokumentów. Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniego magazynu danych.

• Zwiększyć dostępność. Podzielenie danych pomiędzy wiele serwerów eliminuje pojedynczy punkt awarii. Jeśli jedno wystąpienie nie powiedzie się, tylko dane w tej partycji są niedostępne. Operacje na pozostałych partycjach mogą być nadal wykonywane. W przypadku magazynów danych platformy zarządzanej jako usługi (PaaS) jest to mniej istotne, ponieważ te usługi są zaprojektowane z wbudowaną nadmiarowością.

Projektowanie partycji

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 określony podzestaw danych, na przykład wszystkie zamówienia dla określonego zestawu 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 przypadku użycia tej strategii dane są agregowane zgodnie ze sposobem ich użycia w poszczególnych kontekstach ograniczonych w systemie. Na przykład system handlu elektronicznego może przechowywać dane faktur w jednej partycji i danych spisu produktów w innym.

Te strategie można połączyć i zalecamy rozważenie ich wszystkich 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)

Rysunek 1 przedstawia partycjonowanie poziome lub dzielenie na fragmenty. W tym przykładzie dane dotyczące spisu produktów zostały podzielone na fragmenty na podstawie klucza produktu. Każdy fragment zawiera dane dla ciągłego zakresu kluczy fragmentowania (A–G oraz H–Z) w porządku alfabetycznym. Fragmentowanie rozkłada obciążenie większej liczby komputerów, co zmniejsza rywalizację i poprawia wydajność.

Rysunek 1. Partycjonowanie w poziomie (dzielenie na fragmenty) danych na podstawie klucza partycji.

Najważniejszym czynnikiem jest wybór klucza 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ć bardzo duże, ale każdy element ma niewielką liczbę operacji dostępu. W innych, mniejszych fragmentach, poszczególne elementy mogą być używane znacznie częściej. Ważne jest również zapewnienie, że pojedynczy fragment nie przekracza limitów skalowania (w zakresie 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 użycie pierwszej litery nazwy klienta powoduje rozkład niezrównoważony, ponieważ niektóre litery są częściej spotykane. Zamiast tego użyj skrótu identyfikatora klienta, aby równomiernie dystrybuować dane między partycjami.

Wybierz klucz fragmentowania, który minimalizuje wszelkie przyszłe wymagania dotyczące dzielenia dużych fragmentów, łączenia małych fragmentów na większe partycje lub zmiany schematu. Tego typu operacje bywają bardzo czasochłonne i mogą wymagać przełączenia co najmniej jednego fragmentu do trybu offline na czas ich wykonywania.

W przypadku zastosowania replikacji fragmentów niektóre repliki mogą działać w czasie, gdy inne będą dzielone, scalane czy ponownie konfigurowane. Jednak system może wymagać ograniczenia operacji, 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 na temat partycjonowania poziomego, zobacz Wzorzec fragmentowania.

Partycjonowanie pionowe

Najczęstszym zastosowaniem partycjonowania pionowego jest zmniejszenie kosztów operacji we/wy i wydajności związanych z pobieraniem elementów, do których często uzyskuje się dostęp. Rysunek 2 przedstawia 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: liczbę akcji i datę ostatniego zamówienia.

Rysunek 2. Partycjonowanie w pionie danych według wzorca użycia.

W tym przykładzie aplikacja regularnie przesyła zapytania dotyczące nazwy, opisu i ceny produktu w celu wyświetlenia szczegółowych informacji o produktach klientom. Liczba zapasów i data ostatniego zamówienia są przechowywane w oddzielnej partycji, ponieważ te dwa elementy są często używane razem.

Inne zalety partycjonowania pionowego:

• Stosunkowo wolno poruszające się dane (nazwa produktu, opis i cena) mogą być oddzielone od bardziej dynamicznych danych (poziom zapasów i data ostatniego zamówienia). Powolne przenoszenie danych jest dobrym kandydatem do buforowania w pamięci przez aplikację.

• Poufne dane mogą być przechowywane w oddzielnej partycji z dodatkowymi 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. Jest doskonałym rozwiązaniem dla magazynów danych zorganizowanych pod kątem kolumn, takich jak HBase czy Cassandra. Jeśli istnieje niewielkie prawdopodobieństwo, że dane w zbiorze kolumn ulegną zmianie, można rozważyć też użycie magazynów kolumn w programie SQL Server.

Partycjonowanie funkcjonalne

Gdy możliwe jest zidentyfikowanie ograniczonego kontekstu dla każdego odrębnego obszaru biznesowego w aplikacji, partycjonowanie funkcjonalne to sposób na poprawę wydajności izolacji i dostępu do danych. Innym typowym zastosowaniem partycjonowania funkcjonalnego jest oddzielenie danych odczytu i zapisu od danych tylko do odczytu. Rysunek 3 przedstawia przykład partycjonowania funkcjonalnego, w którym dane spisu produktów zostały oddzielone od danych klientów.

Rysunek 3. Partycjonowanie danych funkcjonalnie według powiązanego kontekstu lub poddomeny.

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

Kluczowe jest zaplanowanie rozmiaru i obciążeń poszczególnych partycji i takie ich zrównoważenie, aby dane były rozłożone w sposób zapewniający maksymalną skalowalność. Podczas partycjonowania danych należy jednak również przestrzegać limitów skalowania poszczególnych magazynów partycji.

Planując partycje pod kątem skalowalności, należy postępować zgodnie z poniższymi wskazówkami:

1. Przeanalizuj aplikację w celu określenia sposobów dostępu do danych, uwzględniając na przykład wielkość zestawu wyników zwracanego przez zapytania, częstotliwość dostępu, typowe opóźnienia oraz wymagania związane z przetwarzaniem obliczeń po stronie serwera. W wielu przypadkach kilka głównych jednostek wykorzystuje większość zasobów do przetwarzania.
2. Na podstawie tej analizy określ bieżące i przyszłe wymagania dotyczące skalowalności, w tym rozmiar danych i obciążenie. Następnie rozmieść dane w partycjach tak, aby osiągnąć tę docelową skalowalność. W przypadku partycjonowania poziomego wybranie odpowiedniego klucza fragmentu jest ważne, aby upewnić się, że dystrybucja jest równomierna. Aby uzyskać więcej informacji, zobacz wzorzec fragmentowania.
3. Upewnij się, że każda partycja ma wystarczającą ilość zasobów do obsługi wymagań dotyczących skalowalności pod względem rozmiaru danych i przepływności. W zależności od magazynu danych może istnieć limit ilości miejsca do magazynowania, mocy obliczeniowej lub przepustowości sieci na partycję. Jeśli wymagania prawdopodobnie przekroczą te limity, może być konieczne uściślinie strategii partycjonowania lub podzielenie danych dalej, prawdopodobnie łącząc dwie lub więcej strategii.
4. 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ą. Jeśli tak, może być możliwe ponowne równoważenie partycji lub inne przeprojektowanie niektórych części systemu w celu uzyskania wymaganej równowagi.

Niektóre środowiska w chmurze przydzielają zasoby pod względem granic infrastruktury. Należy sprawdzić, czy limity miejsca do magazynowania, mocy obliczeniowej i przepustowości w wybranych granicach są odpowiednie do przewidywanego wzrostu ilości danych.

Jeśli na przykład używasz usługi Azure Table Storage, istnieje limit liczby żądań, które mogą być obsługiwane przez pojedynczą partycję w określonym przedziale czasu. (Aby uzyskać więcej informacji, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Storage). Zajęty fragment może wymagać więcej zasobów niż może obsłużyć pojedyncza partycja. Jeśli tak, 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 dodatkowych kont magazynu i rozłożenie tabel na tych kontach.

Projektowanie partycji pod kątem wydajności zapytań

Wydajność zapytań można często zwiększyć, używając mniejszych zbiorów danych i uruchamiając zapytania równolegle. Każda partycja powinna zawierać niewielką część całego zestawu danych. Takie zmniejszenie wielkości może poprawić wydajność zapytań. Partycjonowanie nie zastąpi jednak właściwego zaprojektowania i skonfigurowania bazy danych. Upewnij się na przykład, że masz wymagane indeksy.

Planując partycje pod kątem wydajności zapytań, należy postępować zgodnie z poniższymi wskazówkami:

1. Sprawdź wymagania i wydajność aplikacji:

   • Użyj wymagań biznesowych, aby określić krytyczne zapytania, które muszą zawsze działać szybko.
   • Monitoruj system, aby znaleźć wszelkie zapytania wykonywane z niską wydajnością.
   • Znajdź, 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.

2. Podziel na partycje dane powodujące obniżenie wydajności zapytań:

   • 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ę. Dzięki temu wykonanie zapytania nie będzie wymagało skanowania wszystkich partycji.
   • Zwróć uwagę na lokalizację partycji. Jeśli jest to możliwe, spróbuj przechowywać dane w partycjach znajdujących się w pobliżu lokalizacji geograficznej aplikacji i użytkowników uzyskujących do nich dostęp.

3. Jeśli określona jednostka ma wymagania związane z przepływnością i wydajnością zapytań, zastosuj partycjonowanie funkcjonalne dostosowane do tej jednostki. Jeśli wymagania nadal nie zostaną spełnione, zastosuj dodatkowo partycjonowanie poziome. W większości przypadków wystarczy pojedyncza strategia partycjonowania, ale w niektórych przypadkach bardziej wydajne jest łączenie obu strategii.

4. Rozważ równoległe uruchamianie zapytań między partycjami, aby zwiększyć wydajność.

Projektowanie partycji pod kątem dostępności

Partycjonowanie danych może zwiększyć dostępność aplikacji dzięki wyeliminowaniu pojedynczego punktu awarii w całym zbiorze danych i zapewnieniu możliwości niezależnego zarządzania poszczególnymi podzestawami danych.

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

Jakie znaczenie mają określone dane dla działalności biznesowej. Zidentyfikuj, które dane mają krytyczne znaczenie dla działania firmy, takie jak transakcje, oraz dane są mniej krytyczne dla danych operacyjnych, takich jak pliki dziennika.

• Rozważ przechowywanie krytycznych danych w partycjach o wysokiej dostępności przy użyciu odpowiedniego planu tworzenia kopii zapasowych.

• Ustanów oddzielne procedury zarządzania i monitorowania dla różnych zestawów danych.

• Umieść dane o takim samym poziomie istotności w tej samej partycji, aby umożliwić tworzenie kopii zapasowej wszystkich tych danych z odpowiednią częstotliwością. Na przykład partycje przechowujące dane transakcji mogą wymagać częstszego tworzenia kopii zapasowych niż partycje przechowujące informacje rejestrowania lub śledzenia.

Jak można zarządzać poszczególnymi partycjami. Zapewnienie możliwości zarządzania partycjami i ich obsługi niezależnie od pozostałych partycji niesie ze sobą kilka korzyści. 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 w różnych obszarach geograficznych umożliwia wykonywanie zaplanowanych zadań konserwacyjnych poza godzinami szczytu w poszczególnych lokalizacjach. Upewnij się, że partycje nie są zbyt duże, aby zapobiec zakończeniu planowanej konserwacji w tym okresie.

Czy dane krytyczne będą replikowane między partycjami. Ta strategia może zwiększyć dostępność i wydajność, ale może również wprowadzać problemy ze spójnością. Synchronizacja zmian z każdą repliką zajmuje trochę czasu. Zanim to nastąpi, różne partycje będą zawierały różne wartości danych.

Zagadnienia dotyczące projektowania aplikacji

Partycjonowanie zwiększa złożoność projektowania i opracowywania systemu. Warto traktować partycjonowanie jako podstawowy element projektu systemu nawet w przypadkach, w których system początkowo zawiera tylko jedną partycje. Jeśli adresujesz partycjonowanie jako pokutę, będzie to trudniejsze, ponieważ masz już system na żywo do utrzymania:

• Logika dostępu do danych musi zostać zmodyfikowana.
• Aby dystrybuować je między partycjami, może być konieczne przeprowadzenie migracji dużych ilości istniejących danych.
• Użytkownicy oczekują, że będą mogli nadal korzystać z systemu podczas migracji.

Czasem partycjonowanie jest uznawane za nieistotną kwestię, ponieważ początkowy zestaw danych jest niewielki i może być bez problemów obsługiwany przez jeden serwer. Może to być prawdziwe w przypadku niektórych obciążeń, ale w miarę wzrostu liczby użytkowników wiele systemów komercyjnych musi się zwiększać.

Ponadto nie tylko duże magazyny danych korzystają z partycjonowania. Na przykład mały magazyn danych może być intensywnie użytkowany przez setki klientów jednocześnie. W takiej sytuacji partycjonowanie danych może pomóc w zmniejszeniu stopnia rywalizacji i poprawić przepływność.

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

Zminimalizuj operacje dostępu do danych między partycjami. Jeśli to możliwe, dane potrzebne do operacji najczęściej wykonywanych w bazie danych powinny być przechowywane razem, aby uniknąć konieczności wykonywania operacji dostępu między partycjami. Wykonywanie zapytań między partycjami może być bardziej czasochłonne niż wykonywanie zapytań w ramach jednej partycji, ale 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. (Takie podejście może nie być możliwe w niektórych przypadkach, na przykład gdy wynik jednego zapytania jest używany w następnym zapytaniu).

Rozważ 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 w celu zmniejszenia 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, przy dużym natężeniu ruchu z całego systemu. Istnieje jednak dodatkowy koszt związany z synchronizowaniem wszelkich 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 musi wykonywać kolejne zapytania na podstawie klucza, a następnie klucza obcego. 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ą. Ustal, czy wysoki stopień spójności jest faktycznie wymagany. Typowym podejściem w systemach rozproszonych jest zaimplementowanie spójności ostatecznej. Dane w poszczególnych partycjach są aktualizowane oddzielnie, a logika aplikacji zapewnia pomyślne wykonanie wszystkich aktualizacji. To rozwiązanie radzi sobie także z niespójnościami, które mogą się pojawić w przypadku wykonania zapytania w czasie trwania operacji zapewnienia spójności ostatecznej.

Określ, jak zapytania będą znajdować właściwą partycję. Jeśli znalezienie odpowiednich danych dla zapytania wymaga skanowania wszystkich partycji, ma to istotny wpływ na wydajność, nawet w przypadku równoległego uruchomienia wielu zapytań. W przypadku partycjonowania pionowego i funkcjonalnego zapytania mogą naturalnie określać partycję. Z drugiej strony partycjonowanie w poziomie może utrudnić lokalizowanie elementu, ponieważ każdy fragment ma ten sam schemat. Typowe rozwiązanie do obsługi mapy używanej do wyszukiwania lokalizacji fragmentu dla określonych elementów. Tę mapę można wdrożyć w ramach logiki fragmentowania w aplikacji lub w magazynie danych, o ile magazyn obsługuje niewidoczne fragmentowanie.

Rozważ okresowe ponowne równoważenie fragmentów. Dzięki partycjonowaniu poziomym ponowne równoważenie fragmentów może pomóc równomiernie dystrybuować dane według rozmiaru i obciążenia, aby zminimalizować hotspoty, zmaksymalizować wydajność zapytań i obejść ograniczenia magazynu fizycznego. Jest to jednak złożone zadanie, często wymagające zastosowania niestandardowego narzędzia lub procesu.

Replikowanie partycji. Replikacja wszystkich partycji zapewnia dodatkową ochronę przed awariami. Jeśli pojedyncza replika zakończy się niepowodzeniem, zapytania mogą być kierowane do działającej kopii.

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 zostało już wprowadzone na poziomie bazy danych, a ograniczenia fizyczne są problemem, może być konieczne umieszczenie lub replikowanie partycji na wielu kontach hostingowych.

Należy unikać transakcji wymagających dostępu do danych w wielu partycjach. Niektóry magazyny danych mają wdrożone mechanizmy spójności i integralności transakcyjnej dla operacji modyfikujących dane, ale są one stosowane tylko do danych znajdujących się w jednej partycji. Jeśli potrzebujesz obsługi transakcyjnej dla wielu partycji, prawdopodobnie konieczne będzie wdrożenie jej w ramach logiki aplikacji, ponieważ większość systemów partycjonowania nie oferuje natywnej obsługi takich funkcji.

Wszystkie magazyny danych wymagają wykonywania pewnych zadań związanych z monitorowaniem i zarządzaniem operacyjnym. Zadania te mogą obejmować ładowanie danych, tworzenie i przywracanie kopii zapasowych, reorganizowanie 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:

• Sposób wdrożenia odpowiednich zadań zarządzania i zadań operacyjnych w przypadku partycjonowania danych. Zadania te mogą obejmować tworzenie i przywracanie kopii zapasowych, archiwizowanie danych, monitorowanie systemu i inne czynności administracyjne. Wyzwanie może stanowić na przykład utrzymanie spójności logicznej podczas operacji tworzenia i przywracania kopii zapasowych.

• Sposób ładowania danych do wielu partycji i dodawania nowych danych przekazywanych z innych źródeł. Niektóre narzędzia mogą nie obsługiwać operacji na danych przechowywanych we fragmentach, na przykład ładowania danych do właściwej partycji.

• Sposób regularnego archiwizowania i usuwania danych. Aby zapobiec nadmiernemu wzrostowi partycji, należy regularnie archiwizować i usuwać dane (na przykład miesięczne). Może być konieczne przekształcenie danych w celu dostosowania ich do innego schematu archiwum.

• Sposób wykrywania problemów z integralnością danych. Rozważ uruchomienie okresowego procesu lokalizowania wszelkich 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 próbować automatycznie 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ąć uzyskać 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 może spowodować, że niektóre 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 ponowne równoważenie to zadanie administracyjne składające się z dwóch etapów:

1. Określ nową strategię partycjonowania.

   • Które partycje muszą być podzielone (lub ewentualnie połączone)?
   • Co to jest nowy klucz partycji?

2. Migrowanie danych ze starego schematu partycjonowania do nowego zestawu partycji.

W zależności od magazynu danych można migrować dane między partycjami, gdy są one używane. Jest to nazywane migracją online. Jeśli nie jest to możliwe, może być konieczne uczynienie partycji niedostępnymi podczas przenoszenia danych (migracja w trybie offline).

Migracja w trybie offline

Migracja w trybie offline jest zwykle prostsza, ponieważ zmniejsza prawdopodobieństwo wystąpienia rywalizacji. Migracja w trybie offline działa w następujący sposób:

1. Oznacz partycję w trybie offline.
2. Scalanie i przenoszenie danych do nowych partycji.
3. Verify the data.
4. Przełącz nowe partycje w tryb online.
5. Usuń starą partycję.

Opcjonalnie możesz oznaczyć partycję jako tylko do odczytu w kroku 1, aby aplikacje mogły nadal odczytywać dane podczas przenoszenia.

Migracja w trybie online

Migracja online jest bardziej skomplikowana do wykonania, ale mniej destrukcyjna. Proces jest podobny do migracji w trybie offline, z wyjątkiem oryginalnej partycji nie jest oznaczany w trybie offline. W zależności od stopnia szczegółowości procesu migracji (na przykład elementu według elementu a fragmentu według fragmentu) kod dostępu do danych w aplikacjach klienckich może być musiał obsługiwać odczytywanie i zapisywanie danych przechowywanych w dwóch lokalizacjach, oryginalnej partycji i nowej partycji.

Następne kroki

• Dowiedz się więcej o strategiach partycjonowania dla określonych usług platformy Azure. Aby uzyskać więcej informacji, zobacz Strategie partycjonowania danych.
• Cele dotyczące skalowalności i wydajności usługi Azure Storage

Powiązane zasoby

• Wybór odpowiedniego magazynu danych

Następujące wzorce projektowe mogą być istotne dla danego scenariusza:

• Wzorzec fragmentowania opisuje niektóre typowe strategie fragmentowania danych.

• Wzorzec tabeli indeksów pokazuje, jak utworzyć indeksy pomocnicze na danych. Dzięki tej metodzie aplikacja może szybko pobrać dane przy użyciu zapytań nie odwołujących się do klucza podstawowego kolekcji.

• Wzorzec zmaterializowanego widoku opisuje sposób generowania wstępnie wypełnionych widoków, które podsumowują dane w celu obsługi szybkich operacji zapytań. Ta metoda może być użyteczna w przypadku partycjonowanego magazynu danych, w którym podsumowywane dane znajdują się w partycjach rozproszonych w różnych lokalizacjach.