Obsługa wielu dzierżaw i usługa Azure SQL Database

Rozwiązania wielodostępne na platformie Azure często używają usługi Azure SQL Database. W tym artykule opisano strategie partycjonowania i wielodostępności oraz funkcje usługi SQL Database dla rozwiązań wielodostępnych dla wielu dzierżawców.

Przeczytaj ten artykuł wraz z Podejścia architektoniczne dotyczące magazynowania i danych w rozwiązaniach wielodostępnych, w którym opisano ogólne zagadnienia i podejścia stosowane we wszystkich usługach danych.

Strategie partycjonowania i wielodostępności

Wybierz model wielodostępności spełniający wymagania obciążenia dotyczące skali, izolacji, odzyskiwania, dostosowywania i kosztów. Preferuj najprostszy model spełniający te wymagania. Fragmentowanie dodaje złożoność aplikacyjną i operacyjną, dlatego nie wprowadzaj go tylko po to, aby obejść limity, które można zaspokoić za pomocą wyższej warstwy usługi.

Aby porównać kompromisy architektoniczne typowych modeli dzierżawienia Azure SQL Database, zobacz Jak wybrać odpowiedni model dzierżawienia.

Zdecyduj, czy używać jednej lub wielu baz danych

Pojedyncza baza danych SQL ma ograniczoną pojemność magazynowania. Jej przepływność i współbieżność są ograniczone przez warstwę usług, konfigurację obliczeniową, limity połączeń i charakterystykę obciążenia. Przed wybraniem jednej udostępnionej bazy danych, bazy danych dla każdego dzierżawcy lub topologii podzielonej na fragmenty należy oszacować wymagania dotyczące pamięci masowej, przepływności, współbieżności, opóźnienia, izolacji, odzyskiwania po awarii i konfiguracji regionalnej.

Granica bazy danych określa również stopień szczegółowości operacji tworzenia kopii zapasowych, przywracania, replikacji geograficznej i przełączenia awaryjnego. Aby uzyskać więcej informacji, zobacz Architecture best practices for Azure SQL Database.

Współdzielona wielodzierżawna baza danych może zapewnić dużą gęstość dzierżawców i niski koszt na dzierżawcę, ale wiele baz danych może być odpowiednim rozwiązaniem, zanim pojedyncza baza danych osiągnie swoje limity techniczne, jeśli dzierżawcy wymagają silniejszej izolacji lub niezależnych operacji konfiguracji i cyklu życia.

Modele izolacji dzierżawy można łączyć. Na przykład większość dzierżawców można umieścić we współdzielonych bazach danych, a dzierżawcom o wysokim zapotrzebowaniu lub podlegającym regulacjom przydzielić dedykowane bazy danych. Użyj katalogu dzierżawców, aby skierować każdego dzierżawcę do odpowiedniej bazy danych.

Oceń warstwę usługi Hyperscale, gdy rozmiar bazy danych, czas trwania tworzenia kopii zapasowej i przywracania, skalowanie odczytu w poziomie lub szybkie skalowanie mocy obliczeniowej decydują o projekcie. Hyperscale obsługuje automatyczne zwiększanie magazynowania do 128 TB dla bazy danych i do 100 TB dla elastycznej puli Hyperscale. Jeśli istniejąca architektura używa fragmentowania tylko do obejścia limitów magazynu bazy danych, rozważ skonsolidowanie fragmentów do bazy danych Hyperscale. Przed skonsolidowaniem zweryfikuj przepustowość zapisu, koszty, cele odzyskiwania, izolację i wymagania operacyjne.

Współdzielona baza danych z wieloma dzierżawcami

We współdzielonej bazie danych zapisz identyfikator tenantu w każdej tabeli zawierającej dane należące do tenantu. Propaguj uwierzytelnionego użytkownika i tożsamość dzierżawy do bazy danych dla każdego żądania. Ustanów i zweryfikuj ten kontekst przy każdym ponownym użyciu połączenia w puli zamiast polegać na kontekście z poprzedniego żądania. Użyj zabezpieczeń na poziomie wierszy jako zabezpieczenia wymuszanego przez bazę danych przed dostępem do danych między tenantami.

Wszyscy dzierżawcy współdzielą moc obliczeniową, magazyn danych, kopię zapasową, przywracanie i konfigurację regionalną bazy danych. Ten model jest podatny na antywzorzec Noisy Neighbor, w którym obciążenie jednego dzierżawcy wpływa na innych dzierżawców. Przywracanie lub przenoszenie jednego tenanta wymaga wyodrębniania i walidacji danych kontrolowanych przez aplikację. Użyj tego modelu, gdy gęstość dzierżawców i wydajność kosztowa są ważniejsze niż konfiguracja specyficzna dla dzierżawcy lub silna izolacja wydajności.

Baza danych dla każdego dzierżawcy

Używaj oddzielnej bazy danych dla każdego dzierżawcy, gdy dzierżawcy wymagają silniejszej izolacji danych i wydajności, niezależnej kopii zapasowej i przywracania, dostosowywania schematu, umieszczania regionalnego lub jednoznacznego przypisania kosztów. Aplikacja musi utrzymywać niezawodne mapowanie z każdego identyfikatora dzierżawcy do bazy danych i odpowiednio kierować połączenia.

Umieść bazy danych ze zgodnymi wymaganiami dotyczącymi wydajności i odzyskiwania w pulach elastycznych w celu współdzielenia aprowizowanych zasobów obliczeniowych. Użyj Hyperscale lub elastycznych pul Hyperscale, gdy poszczególne bazy danych dzierżawy wymagają magazynu w warstwie Hyperscale, tworzenia kopii zapasowych, przywracania lub skalowania do odczytu.

Fragmentowane wielodzierżawne bazy danych

Używaj wielodzierżawnych baz danych podzielonych na fragmenty, gdy rozproszenie dzierżawców na wiele współużytkowanych baz danych lepiej spełnia wymagania dotyczące skalowania, odzyskiwania, gęstości dzierżawy lub kosztów niż pojedyncza współużytkowana baza danych lub topologia jednej bazy danych na dzierżawcę. Fragment danych jest bazą danych Azure SQL, która przechowuje jednego lub więcej dzierżawców. Użyj stabilnego klucza fragmentacji, takiego jak identyfikator dzierżawcy, aby aplikacja mogła określić, która baza danych przechowuje dane dzierżawcy.

Traktuj zestaw danych każdego dzierżawcy jako jednostkę rozmieszczenia. Zachowaj wszystkie dane tenanta w jednym shardzie, jeśli jest to możliwe, aby zapytania i transakcje dotyczące danego tenanta pozostały w jednej bazie danych. Utrzymuj mapowanie z każdego identyfikatora dzierżawcy na bazę danych zawierającą jego dane.

Mapowanie dzierżawy na bazę danych jest często nazywane shard map. Mapa fragmentacji to wykaz mapujący każdy klucz fragmentacji lub zakres kluczy na bazę danych, która przechowuje skojarzone dane. Zaimplementuj shard map jako trwałe metadane aplikacji spełniające wymagania obciążenia dotyczące dostępności i spójności. Wystąpienia aplikacji mogą buforować wpisy mapy fragmentów, aby zmniejszyć opóźnienie routingu, ale podczas zmiany mapowań muszą odświeżyć lub unieważnić buforowane wpisy.

Udostępnij wysoce dostępną autorytatywną mapę fragmentów i zaktualizuj ją atomowo za pomocą operacji migracji dzierżawcy. Aplikacja musi również być właścicielem routingu połączeń, aprowizacji fragmentów, przenoszenia tenantów, ponownego równoważenia i obsługi błędów. Zaplanuj, jak aplikacja obsługuje nieaktualne mapowania podczas przełączenia i wycofywania. Aby uzyskać ogólne wskazówki dotyczące projektowania, zobacz wzorzec fragmentowania.

Planuj operacje między bazami danych

Zaprojektuj każdą bazę danych jako niezależną granicę transakcji i integralności:

  • Zachowaj lokalność i integralność danych: Zachowaj dane, które aplikacja łączy lub aktualizuje transakcyjnie w tej samej bazie danych. Nie twórz więzów integralności, wyzwalaczy ani zależności od procedur składowanych między bazami danych. W przypadku operacji biznesowych obejmujących bazy danych użyj spójności ostatecznej lub innego wzorca koordynacji na poziomie aplikacji.
  • Spójne zarządzanie schematami: Użyj tych samych tabel, kolumn, indeksów, widoków i procedur składowanych w poszczególnych shardach, aby aplikacja mogła używać tej samej logiki dostępu do danych po skierowaniu żądania do dowolnego shardu. Automatyzuj wdrożenia schematów w całej flocie baz danych i śledź wersję schematu każdej bazy danych. Jeśli celowo obsługujesz odmianę schematu, zapewnij, aby aplikacja i proces wdrażania uwzględniały wersje.
  • Zarządzaj danymi referencyjnymi w sposób przemyślany: Replikuj statyczne lub wolno zmieniające się dane referencyjne, gdy pozwala to uniknąć synchronicznych operacji między bazami danych. Zdefiniuj, w jaki sposób aplikacja propaguje aktualizacje i obsługuje nieaktualne kopie.
  • Równoważenie i umieszczanie fragmentów: Równoważenie fragmentów według ilości danych i obciążenia żądań, nie tylko według liczby dzierżawców. Zaplanuj zautomatyzowany i możliwy do odzyskania proces przenoszenia dzierżawców między fragmentami danych. Umieść bazy danych zgodnie z wymaganiami dotyczącymi opóźnień najemcy, lokalizacji danych i odzyskiwania po awarii.

Użyj Elastic jobs do zaplanowanych zmian schematu, konserwacji, zbierania danych telemetrycznych i innych operacji w grupach baz danych. W przypadku raportowania i analizy w bazach danych dzierżawców należy użyć scentralizowanego magazynu analitycznego, takiego jak Microsoft Fabric przez replikację lustrzaną dla Azure SQL Database, lub potoku wyodrębniania, przekształcania i ładowania (ETL), takiego jak Azure Data Factory. Jeśli aplikacja wymaga synchronicznych zapytań fan-out, utwórz warstwę zapytania i agregacji, która definiuje limit czasu, ponawianie próby, częściowe niepowodzenie i scalanie wyników.

Funkcje usługi SQL Database, które obsługują wielodostępność

Usługa SQL Database zawiera wiele funkcji, które obsługują wielodzierżawczość.

Pule elastyczne

Pule elastyczne współdzielą skonfigurowany zestaw zasobów obliczeniowych między wieloma bazami danych na tym samym serwerze logicznym. Pule mogą obniżyć koszty, gdy bazy danych dzierżawców mają niskie średnie wykorzystanie i rzadko występujące, nienakładające się szczyty użycia. Bazy danych ze stale średnio wysokim do wysokiego wykorzystaniem mogą być lepiej dostosowane do dedykowanych zasobów obliczeniowych. Możesz ustawić minimalne i maksymalne limity zasobów dla poszczególnych baz danych w puli, aby ograniczyć użycie zasobów, ale wszystkie bazy danych nadal współdzielą łączną pojemność puli. Monitoruj zarówno wykorzystanie puli agregowanej, jak i indywidualne wykorzystanie bazy danych.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Hiperskala

Azure SQL Database Hyperscale oddziela zasoby obliczeniowe od magazynu, dzięki czemu można je skalować niezależnie. Użyj warstwy Hyperscale, gdy współdzielona baza danych wielodostępna lub pojedyncza baza danych dzierżawy wymaga wyższych limitów magazynu, szybkiego tworzenia kopii zapasowych i przywracania lub skalowania odczytu w poziomie.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Zadania elastyczne

Użyj Elastic Jobs, aby uruchamiać zaplanowane skrypty Transact-SQL (T-SQL) i zadania konserwacji względem jednej lub wielu baz danych. Grupy docelowe mogą obejmować poszczególne bazy danych, serwery logiczne, elastyczne pule i bazy danych w różnych subskrypcjach. Typowe zastosowania wielodzierżawne obejmują wdrażanie zmian schematu, zarządzanie poświadczeniami, zbieranie danych telemetrycznych i uruchamianie wsadowych zadań przetwarzania danych w całej flocie baz danych.

Elastic Jobs nie zapewniają synchronicznej warstwy zapytań aplikacji. Jeśli żądanie aplikacji musi odpytywać wiele baz danych i natychmiast agregować wyniki, zaimplementuj to zachowanie w warstwie aplikacji lub analitycznej.

Aby uzyskać więcej informacji, zobacz Zadania elastyczne w usłudze Azure SQL Database.

Zabezpieczenia na poziomie wiersza

Zabezpieczenia na poziomie wiersza pomagają wymusić izolację na poziomie najemcy w udostępnionych tabelach. Aby uzyskać więcej informacji, zobacz Implementacja zabezpieczeń na poziomie Azure SQL.

Zarządzanie kluczami

Azure SQL Database używa funkcji Transparent Data Encryption (TDE) do szyfrowania przechowywanych danych. Jeśli dzierżawcy muszą podać własne klucze szyfrowania, użyj oddzielnych baz danych i skonfiguruj klucze TDE zarządzane przez klienta na poziomie bazy danych. Użyj funkcji Always Encrypted, gdy silnik bazy danych i jego operatorzy nie mogą mieć dostępu do wartości w postaci zwykłego tekstu w określonych poufnych kolumnach. Zweryfikuj zgodność aplikacji i zapytań, ponieważ funkcja Always Encrypted ogranicza niektóre operacje na zaszyfrowanych kolumnach.

Współautorzy

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

Główni autorzy:

  • Paul Burpo | Główny inżynier klienta, fasttrack dla platformy Azure
  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure

Inni współautorzy:

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

Następne kroki

  • Ostatnia aktualizacja o