Wielodzierżawność i Azure Table Storage

Azure Table Storage przechowuje dane ustrukturyzowane, nierelacyjne. W tym artykule opisano strategie partycjonowania, modele izolacji i funkcje usługi Table Storage dla rozwiązań wielodostępnych. Zawiera on wskazówki, które mogą ułatwić dystrybucję danych encji i obciążenia związanego z żądaniami, izolowanie encji dzierżawców oraz zarządzanie dostępem, szyfrowaniem i użyciem.

Strategie partycjonowania

Usługa Table Storage automatycznie partycjonuje encje na podstawie wartości właściwości PartitionKey. Każda jednostka musi zawierać element PartitionKey i element RowKey. Razem te właściwości jednoznacznie identyfikują jednostkę. Każda właściwość może zawierać ciąg zawierający maksymalnie 1024 znaki.

Wszystkie encje, które mają tę samą wartość PartitionKey, należą do tej samej partycji. Gdy aplikacja zapisuje pierwszą encję z nową PartitionKey wartością, usługa Table Storage tworzy odpowiednią partycję logiczną i zarządza jej fizycznym rozmieszczeniem. Usługa Table Storage dystrybuuje partycje między węzłami magazynu i może je ponownie zrównoważyć w miarę zmiany wzorców żądań. To automatyczne zarządzanie partycjami umożliwia usłudze skalowanie w poziomie podczas dodawania wartości klucza partycji.

Projektowanie kluczy dla wzorców dostępu

Wybierz wartości PartitionKey i RowKey na podstawie sposobu wykonywania zapytań i modyfikowania danych przez aplikację. Zapytanie punktowe, które określa obie wartości, jest najbardziej wydajnym zapytaniem. Zapytania określające PartitionKey i zakres RowKey wartości skanują tylko jedną partycję. Zapytania, które nie określają PartitionKey partcji klucza, muszą skanować wiele partycji lub całą tabelę. Wybierz element RowKey, który obsługuje kolejność sortowania i zapytania zakresowe najczęściej używane przez obciążenie robocze.

Klucz naturalny jest kandydatem PartitionKey tylko wtedy, gdy jest zgodny z wymaganiami obciążenia roboczego dotyczącymi zapytań, dystrybucji i transakcji. Jeśli partycja logiczna zawiera dokładnie jedną jednostkę, możesz użyć klucza naturalnego jako PartitionKey i pustego ciągu jako RowKey Jeśli jednostka ma wiele stabilnych właściwości klucza, wybierz wartość lub wartości dla PartitionKey, które rozkładają obciążenie żądań, obsługują dominujące zapytania i grupują jednostki wymagające transakcji niepodzielnych. Służy RowKey do unikatowego identyfikowania i porządkowania encji w ramach tej partycji. Jeśli żadna właściwość nie spełnia tych wymagań, skonstruuj klucz syntetyczny, łącząc stabilne wartości właściwości.

Usługa Table Storage automatycznie indeksuje tylko PartitionKey i RowKey. Jeśli regularnie wysyłasz zapytania według innych właściwości, rozważ zaimplementowanie wzorca Index Table, duplikowanie encji w celu obsługi innego wzorca dostępu lub użycie magazynu danych obsługującego indeksy wtórne. Aby uzyskać więcej informacji na temat projektowania zapytań, zobacz Projektowanie pod kątem wykonywania zapytań.

Podziel właściwości jednostki w pionie

W przypadku jednostek logicznych zawierających wiele właściwości użyj projekcji po stronie serwera, aby pobrać tylko właściwości wymagane przez każde zapytanie. Jeśli grupy właściwości mają znacznie różniące się wzorce dostępu lub aktualizacji, lub jeśli jednostka logiczna zbliża się do limitów jednostek usługi Table Storage, rozważ podzielenie jednostki logicznej na wiele jednostek lub tabel. Zachowaj powiązane encje w tej samej tabeli z tym samym PartitionKey, gdy trzeba je zaktualizować w transakcji grupy encji. Aby uzyskać więcej informacji, zobacz Wzorce projektowe tabel.

Wybierz stopień szczegółowości klucza partycji

Stopień szczegółowości PartitionKey wartości wpływa na skalowalność, wydajność zapytań i granice transakcji:

  • Jedna partycja dla wielu encji: Użycie tej samej PartitionKey wartości dla wielu encji przechowuje powiązane dane razem. Zapytania mogą pobierać grupę z jednej partycji, a transakcje grupy encji mogą aktualizować encje atomowo. Jednak wszystkie żądania dla tych jednostek współdzielą docelową przepustowość partycji. Użycie jednej PartitionKey wartości dla całej tabeli może utworzyć gorącą partycję i jest odpowiednie tylko dla małych obciążeń.
  • Jedna partycja dla każdej encji: Użycie unikatowej PartitionKey wartości dla każdej encji dystrybuuje obciążenie żądania między wiele partycji. Zapytania dotyczące punktów pozostają wydajne, ale zapytania pobierające wiele encji mogą wymagać dostępu do wielu partycji. Wiele jednostek nie może uczestniczyć w tej samej transakcji grupy jednostek, ponieważ nie współdzielą elementu PartitionKey.
  • Jedna partycja dla każdej powiązanej grupy: Udostępnianie wartości PartitionKey między jednostkami, które aplikacja często odpytuje lub aktualizuje razem, równoważy lokalność zapytań, obsługę transakcji i skalowalność. W przypadku obciążenia wielodostępnego powiązana grupa może być tenantem lub zbiorem jednostek w ramach dużego tenanta.

Unikaj monotonicznie rosnących lub malejących wartości PartitionKey w obciążeniach intensywnie korzystających z zapisu, takich jak 0001, 0002 i 0003. Te wartości mogą skoncentrować zapisy w wąskim zakresie kluczy i utworzyć gorącą partycję. Użyj stabilnego tworzenia skrótów lub kubełkowania, gdy musisz rozproszyć operacje zapisu, i przetestuj strategię partycjonowania przy oczekiwanym szczytowym obciążeniu. Aby uzyskać bieżące limity i wskazówki dotyczące projektowania, zobacz Cele skalowalności usługi Table Storage i Projektowanie skalowalnej strategii partycjonowania dla usługi Table Storage.

Partycjonowanie według dzierżawcy

W tabeli udostępnionej można użyć identyfikatora dzierżawy jako PartitionKey klucza partycji, gdy większość operacji jest ograniczona do jednej dzierżawy, a szczytowe obciążenie każdej dzierżawy mieści się w ramach celu skalowalności dla jednej partycji. W przypadku jednostek, które mają rozmiar 1 KiB, partycja ma docelową przepływność do 2000 jednostek na sekundę, a konto magazynowe ma maksymalną szybkość żądań wynoszącą 20 000 transakcji na sekundę. Nieproporcjonalnie aktywny dzierżawca może utworzyć gorącą partycję i podlegać ograniczaniu przepustowości nawet wtedy, gdy inne partycje mają nieużywaną pojemność.

Utworzenie większej liczby tabel na tym samym koncie magazynu danych nie zwiększa limitu żądań na poziomie konta. Jeśli jedna partycja zbliża się do swojego celu, dopracuj strategię PartitionKey, aby rozłożyć obciążenie żądaniami. Jeśli zagregowane obciążenie zbliża się do docelowej wartości dla konta magazynu, rozłóż obciążenie na wiele kont magazynu.

W przypadku dużych lub aktywnych dzierżaw należy utworzyć wiele wartości zależnych od dzierżawy PartitionKey, łącząc identyfikator dzierżawy ze stabilnym zasobnikiem lub wartością specyficzną dla domeny. Takie podejście dystrybuuje encje dzierżawcy i obciążenie żądań między partycjami, ale wprowadza kompromisy:

  • Zapytania dotyczące całego dzierżawcy mogą wymagać wykonywania zapytań dotyczących wielu partycji.
  • Transakcje grupy encji nie mogą obejmować partycji dzierżawcy.
  • Aplikacja musi kierować operacje do właściwej partycji.
  • Sygnatury dostępu współdzielonego (SAS) ograniczone do zakresu kluczy stają się bardziej złożone do projektowania i wystawiania.

Zaplanuj granice transakcji

Usługa Table Storage obsługuje transakcje grup encji dla encji w tej samej tabeli, które mają tę samą wartość PartitionKey. Transakcja może obejmować maksymalnie 100 encji, a jej ładunek musi być mniejszy niż 4 MiB. Wszystkie operacje w transakcji wykonują się atomowo: albo wszystkie się powiodą, albo wszystkie zakończą się niepowodzeniem.

Operacje obejmujące partycje nie są transakcyjne. Jeśli operacja biznesowa musi aktualizować encje atomowo, przechowuj te encje w tej samej partycji. W przeciwnym razie zaprojektuj aplikację tak, aby obsługiwała częściowe awarie i używała odpowiedniej strategii spójności. Aby uzyskać więcej informacji, zobacz Wykonywanie transakcji grupy encji.

Modele izolacji

Po zaprojektowaniu kluczy partycji uwzględniających dzierżawcę określ poziom izolacji dzierżawcy do zastosowania. Usługa Table Storage obsługuje tabele udostępnione, tabele dla każdego dzierżawcy i konta magazynu danych dla każdego dzierżawcy. W poniższej tabeli przedstawiono podsumowanie różnic między głównymi modelami izolacji dzierżawy dla usługi Table Storage.

Rozważenie Udostępnione tabele z kluczami partycji uwzględniającymi dzierżawcę Tabele dla każdego najemcy Konta magazynowe dla każdego dzierżawcy
Izolacja danych Niski poziom Aplikacja lub sygnatura dostępu współdzielonego (SAS) ograniczona do zakresu kluczy wymusza izolację. Nisko-średni High
Izolacja wydajności Low Niski poziom Większość przydziałów i limitów ma zastosowanie do całego konta magazynu. High
Złożoność wdrożenia Low Medium High
Złożoność operacyjna Low Medium High
Przykładowy scenariusz Duże rozwiązanie wielodostępne ma udostępnioną warstwę aplikacji. Wystawiane są adresy URL sygnatur dostępu współdzielonego na poziomie dzierżawy. Każda dzierżawa ma własną sygnaturę wdrożenia.

Note

Podczas wybierania modelu izolacji należy wziąć pod uwagę przydziały i limity. Te limity obejmują limity usług Azure, cele skalowalności usługi Table Storage i cele skalowalności dla dostawcy zasobów usługi Storage.

Udostępnione tabele z kluczami partycji uwzględniającymi dzierżawę

Jeśli używasz pojedynczej tabeli udostępnionej, użyj identyfikatora dzierżawy jako kompletnego PartitionKey dla dzierżaw, których dane i obciążenie żądaniami mieszczą się w jednej partycji, takich jak mniejsze dzierżawy, lub jako jeden ze składników syntetycznego PartitionKey dla większych dzierżaw. Aby zapoznać się z kluczowymi zagadnieniami dotyczącymi projektowania i skalowalności, zobacz Strategie partycjonowania.

Tokeny SAS umożliwiają określenie zakresu kluczy partycji. Usługa Table Storage zapewnia, że żądania zawierające podpis mogą uzyskiwać dostęp tylko do encji w ramach określonych zakresów klucza partycji i klucza wiersza. Jeśli dane dzierżawcy obejmują wiele PartitionKey wartości, zaprojektuj wartości i zakresy sygnatur dostępu współdzielonego, aby token nie mógł udzielić dostępu do encji innego dzierżawcy. Możesz zaimplementować wzorzec Valet Key, aby umożliwić niezaufanym klientom dostęp do zasobów dzierżawcy bez udzielania dostępu innym dzierżawcom.

Jeśli aplikacja uzyskuje dostęp do udostępnionej tabeli w imieniu dzierżawców, wymuszaj zakres kluczy dzierżawcy dla każdej operacji. Konwencja nazewnictwa klucza partycji nie zapewnia samej izolacji dostępu.

Tabele dla każdego najemcy

Można utworzyć indywidualne tabele dla każdego dzierżawcy w ramach jednego konta magazynowego. Nie ma limitu liczby tabel, które można utworzyć na koncie przechowywania danych.

Oddzielne tabele zapewniają granicę routingu i kontroli dostępu, ale nie zapewniają izolacji wydajności. Wszystkie tabele na koncie współdzielą cele dotyczące pojemności i wydajności konta magazynowego.

W tym scenariuszu możesz użyć kontroli dostępu do usługi Table Storage, w tym sygnatury dostępu współdzielonego, aby zarządzać dostępem do danych każdego dzierżawcy.

Konta magazynowe dla każdego dzierżawcy

Najsilniejszy poziom izolacji używa dedykowanego konta storage dla każdego najemcy. Ten model zapewnia pełną izolację kluczy konta magazynu danych, które można rotować niezależnie. Umożliwia również skalowanie rozwiązania poza limity i przydziały dla każdego konta magazynowego. Rozważ ten model dla dzierżawców, którzy utrzymują stale wysoki wolumen transakcji lub wymagają niezależnej konfiguracji regionalnej, kluczy szyfrowania lub celów wydajności. Należy również wziąć pod uwagę maksymalną liczbę kont magazynu danych dozwolonych w ramach jednej subskrypcji Azure.

Funkcje usługi Table Storage, które obsługują wielodzierżawność

Poniższe funkcje usługi Table Storage mogą pomóc w zaimplementowaniu i obsłudze wybranego modelu izolacji.

Sygnatury dostępu współdzielonego

W przypadku korzystania z usługi Table Storage z poziomu aplikacji klienckiej należy rozważyć kierowanie żądań za pośrednictwem warstwy aplikacji lub zezwalanie klientom na bezpośrednie łączenie się z tabelą. Bezpośredni dostęp po stronie klienta może zmniejszyć obciążenie aplikacji zaplecza i liczbę przeskoków sieciowych.

sygnatura dostępu współdzielonego (SAS) umożliwia zapewnienie aplikacjom klienckim ograniczonego dostępu do tabeli. Można ograniczyć operacje, które klient może wykonać, zakresy kluczy partycji i wierszy, do których może uzyskać dostęp, oraz okres, w którym jest dozwolony dostęp. Na przykład można wydać sygnaturę dostępu współdzielonego (SAS), która zezwala dzierżawcy na odczyt tylko jednostek w ramach własnego zakresu kluczy partycji.

Użyj wzorca Valet Key, aby wystawiać ograniczone tokeny SAS ze swojego poziomu aplikacji. Uwierzytelnij klienta przy użyciu systemu uwierzytelniania aplikacji, określ, do których encji dzierżawcy mogą uzyskać dostęp, i wystawiaj token tylko dla wymaganych zakresów kluczy i operacji.

Przechowywane zasady dostępu umożliwiają zdefiniowanie pojedynczej zasady do użycia w przypadku wystawiania wielu tokenów SAS usługi. Przechowywane zasady dostępu nie mają zastosowania do tokenów SAS delegowania użytkownika ani tokenów SAS konta.

Delegowanie użytkownika SAS

Sygnatura dostępu współdzielonego usługi lub sygnatura dostępu współdzielonego konta jest podpisana przy użyciu jednego z kluczy konta magazynu. Sygnatura dostępu współdzielonego delegowania użytkownika jest zamiast tego zabezpieczona przy użyciu poświadczeń Microsoft Entra. Warstwa aplikacji żąda klucza delegowania użytkownika przy użyciu własnej tożsamości zarządzanej, a następnie podpisuje tokeny o określonym zakresie i ograniczone czasowo dla każdego dzierżawcy. Nie dystrybuujesz ani nie przechowujesz kluczy kont. Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkownika zamiast sygnatury dostępu współdzielonego SAS klucza konta, jeśli projekt to obsługuje.

Użyj krótkich okresów istnienia tokenu i zaplanuj sposób odwołania dostępu, jeśli token zostanie skompromitowany. Aby skorelować dzienniki aplikacji z dziennikami usługi Table Storage, ustaw identyfikator żądania klienta (x-ms-client-request-id) w żądaniach magazynu i zarejestruj go obok identyfikatora dzierżawy.

Kontrola dostępu oparta na tożsamości

Usługa Table Storage zapewnia kontrolę dostępu opartą na tożsamościach za pośrednictwem Microsoft Entra ID. Użyj tożsamości zarządzanych i kontroli dostępu opartej na rolach platformy Azure, aby autoryzować aplikację do uzyskiwania dostępu do tabel bez przechowywania kluczy kont. Ogranicz dostęp do tabeli każdego tenanta, gdy tenanci wymagają bezpośredniego dostępu. Przypisania ról na poziomie tabeli nie ograniczają dostępu do partycji dzierżawcy w tabeli udostępnionej.

Encryption

Usługa Table Storage domyślnie szyfruje dane magazynowane przy użyciu kluczy zarządzanych przez Microsoft. Aby używać kluczy zarządzanych przez klienta, skonfiguruj konto magazynu do używania klucza szyfrowania w zakresie konta dla tabel podczas tworzenia konta. Nie można zmienić tego zakresu klucza szyfrowania po utworzeniu konta. Pojemność i transakcje usługi Table Storage są rozliczane według różnych stawek, gdy konto jest skonfigurowane do używania klucza szyfrowania o zakresie konta dla tabel, nawet jeśli kluczem zarządza Microsoft.

Jeśli dzierżawcy wymagają oddzielnych kluczy zarządzanych przez klienta, użyj oddzielnych kont magazynu. Blob Storage zakresy szyfrowania i klucze dostarczone przez klienta na poszczególnych żądaniach nie mają zastosowania do usługi Table Storage. Planuj rotację i odwoływanie kluczy wraz z cyklem życia tenantu.

Monitoring

W rozwiązaniu wielodostępnym zastanów się, czy należy zmierzyć zużycie dla każdego najemcy. Zdefiniuj określone metryki do śledzenia, takie jak liczba encji lub operacji dla danych każdego dzierżawcy. Możesz również użyć alokacji kosztów, aby śledzić koszty użycia każdego najemcy i włączyć rozliczanie kosztów w wielu subskrypcjach.

Usługa Table Storage oferuje wbudowane funkcje monitorowania. Gdy dzierżawcy współdzielą tabelę, uwzględnij identyfikatory dzierżawców w telemetrii aplikacji, aby można było przypisywać operacje i użycie do odpowiednich dzierżawców.

Monitoruj współczynniki żądań oraz odpowiedzi HTTP 500 i 503, aby wykrywać partycje danych lub konta, które zbliżają się do celów skalowalności. Skoreluj tę telemetrię z identyfikatorami dzierżawców, aby zidentyfikować dzierżawców, których wykorzystanie zasobów wpływa na pojemność współdzieloną.

Możesz zbierać dzienniki żądań, a następnie agregować i analizować je obok danych telemetrycznych aplikacji. W rozwiązaniach, które tworzą duże ilości żądań, należy rozważyć, czy korzyści uzasadniają koszt przechwytywania i przetwarzania tych dzienników.

Contributors

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure

Inni współautorzy:

  • Dr Christian Geuer-Pollmann | Główny inżynier klienta, fasttrack dla platformy Azure
  • Patrick Horn | Starszy menedżer ds. inżynierii klienta, rozwiązanie FastTrack dla platformy Azure
  • Ben Hummerstone | Główny inżynier klienta, fasttrack dla platformy Azure
  • Vic Perdana | Architekt rozwiązań w chmurze — ISV Azure
  • Daniel Scott-Raynsford | Architekt rozwiązań partnerskich, dane i sztuczna inteligencja
  • Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

  • Ostatnia aktualizacja o