Wzorce dzierżawy wielodostępnej bazy danych SaaS

Dotyczy:Azure SQL Database

W tym artykule opisano różne modele dzierżawy dostępne dla wielodostępnej aplikacji SaaS.

Podczas projektowania aplikacji SaaS z wieloma dzierżawami należy dokładnie wybrać model dzierżawy, który najlepiej odpowiada potrzebom aplikacji. Model dzierżawy określa, jak dane poszczególnych dzierżaw są mapowane na magazyn. Wybór modelu dzierżawy ma wpływ na projektowanie aplikacji i zarządzanie nimi. Przełączanie się do innego modelu jest czasami kosztowne.

A. Pojęcia i terminologia saas

W modelu oprogramowania jako usługi (SaaS) firma nie sprzedaje licencji na oprogramowanie. Zamiast tego każdy klient dokonuje płatności czynszu w firmie, co sprawia, że każdy klient jest dzierżawą twojej firmy.

W zamian za płacenie czynszu każda dzierżawa otrzymuje dostęp do składników aplikacji SaaS i ma swoje dane przechowywane w systemie SaaS.

Termin Model dzierżawy odnosi się do sposobu organizowania przechowywanych danych dzierżawy:

• Dzierżawa pojedyncza: każda baza danych przechowuje dane tylko z jednej dzierżawy.
• Obsługa wielu dzierżaw: każda baza danych przechowuje dane z wielu oddzielnych dzierżaw (z mechanizmami ochrony prywatności danych).
• Dostępne są również modele dzierżawy hybrydowej.

B. Jak wybrać odpowiedni model dzierżawy

Ogólnie rzecz biorąc, model dzierżawy nie ma wpływu na funkcję aplikacji, ale prawdopodobnie ma wpływ na inne aspekty ogólnego rozwiązania. Do oceny każdego z modeli służą następujące kryteria:

• Skalowalność:

  • Liczba dzierżaw.
  • Magazyn na dzierżawę.
  • Magazyn w agregacji.
  • Obciążenia.

• Izolacja dzierżawy: izolacja danych i wydajność (czy obciążenie jednej dzierżawy ma wpływ na inne).

• Koszt dzierżawy: koszty bazy danych.

• Złożoność programowania:

  • Zmiany w schemacie.
  • Zmiany w zapytaniach (wymagane przez wzorzec).

• Złożoność operacyjna:

  • Monitorowanie wydajności i zarządzanie nią.
  • Zarządzanie schematami.
  • Przywracanie dzierżawy.
  • Odzyskiwanie po awarii.

• Możliwość dostosowywania: Łatwość obsługi dostosowań schematu, które są specyficzne dla dzierżawy lub specyficzne dla danej klasy dzierżawy.

Dyskusja na temat dzierżawy koncentruje się na warstwie danych . Rozważmy jednak chwilę warstwy aplikacji . Warstwa aplikacji jest traktowana jako jednostka monolityczna. Jeśli podzielisz aplikację na wiele małych składników, wybór modelu dzierżawy może ulec zmianie. Niektóre składniki można traktować inaczej niż inne w odniesieniu zarówno do dzierżawy, jak i używanej technologii magazynowania lub platformy.

C. Autonomiczna aplikacja z jedną dzierżawą z bazą danych z jedną dzierżawą

Izolacja na poziomie aplikacji

W tym modelu cała aplikacja jest instalowana wielokrotnie, raz dla każdej dzierżawy. Każde wystąpienie aplikacji jest wystąpieniem autonomicznym, więc nigdy nie wchodzi w interakcje z żadnym innym autonomicznym wystąpieniem. Każde wystąpienie aplikacji ma tylko jedną dzierżawę i dlatego potrzebuje tylko jednej bazy danych. Dzierżawa ma całą bazę danych.

Każde wystąpienie aplikacji jest instalowane w oddzielnej grupie zasobów platformy Azure. Grupa zasobów może należeć do subskrypcji należącej do dostawcy oprogramowania lub dzierżawy. W obu przypadkach dostawca może zarządzać oprogramowaniem dla dzierżawy. Każde wystąpienie aplikacji jest skonfigurowane do nawiązywania połączenia z odpowiednią bazą danych.

Każda baza danych dzierżawy jest wdrażana jako pojedyncza baza danych. Ten model zapewnia największą izolację bazy danych. Jednak izolacja wymaga przydzielenia wystarczającej ilości zasobów do każdej bazy danych w celu obsługi szczytowych obciążeń. W tym przypadku ważne jest, aby elastyczne pule nie mogły być używane dla baz danych wdrożonych w różnych grupach zasobów lub w różnych subskrypcjach. To ograniczenie sprawia, że ten autonomiczny model aplikacji z jedną dzierżawą jest najdroższym rozwiązaniem z ogólnej perspektywy kosztów bazy danych.

Zarządzanie dostawcami

Dostawca może uzyskać dostęp do wszystkich baz danych we wszystkich autonomicznych wystąpieniach aplikacji, nawet jeśli wystąpienia aplikacji są zainstalowane w różnych subskrypcjach dzierżawy. Dostęp jest uzyskiwany za pośrednictwem połączeń SQL. Ten dostęp między wystąpieniami może umożliwić dostawcy scentralizowanie zarządzania schematami i zapytań między bazami danych na potrzeby raportowania lub analizy. Jeśli tego rodzaju scentralizowane zarządzanie jest pożądane, należy wdrożyć wykaz, który mapuje identyfikatory dzierżawy na identyfikatory URI bazy danych. Usługa Azure SQL Database udostępnia bibliotekę fragmentowania, która jest używana razem do udostępniania wykazu. Biblioteka fragmentowania jest formalnie nazwana biblioteką kliencką elastycznej bazy danych.

D. Aplikacja wielodostępna z bazą danych na dzierżawę

Ten następny wzorzec używa aplikacji wielodostępnej z wieloma bazami danych, a wszystkie są bazami danych z jedną dzierżawą. Dla każdej nowej dzierżawy jest aprowizowana nowa baza danych. Warstwa aplikacji jest skalowana w górę w pionie , dodając więcej zasobów na węzeł. Lub aplikacja jest skalowana w poziomie przez dodanie większej liczby węzłów. Skalowanie jest oparte na obciążeniu i jest niezależne od liczby lub skali poszczególnych baz danych.

Dostosowywanie dla dzierżawy

Podobnie jak wzorzec aplikacji autonomicznej, użycie baz danych z jedną dzierżawą zapewnia silną izolację dzierżawy. W dowolnej aplikacji, której model określa tylko bazy danych z jedną dzierżawą, schemat dla dowolnej danej bazy danych można dostosować i zoptymalizować pod kątem dzierżawy. To dostosowanie nie ma wpływu na inne dzierżawy w aplikacji. Być może dzierżawa może potrzebować danych poza podstawowymi polami danych, których potrzebują wszyscy dzierżawcy. Ponadto dodatkowe pole danych może wymagać indeksu.

W przypadku bazy danych na dzierżawę dostosowywanie schematu dla co najmniej jednej dzierżawy jest proste do osiągnięcia. Dostawca aplikacji musi projektować procedury, aby dokładnie zarządzać dostosowaniami schematu na dużą skalę.

Pule elastyczne

Gdy bazy danych są wdrażane w tej samej grupie zasobów, można je zgrupować w elastyczne pule. Pule zapewniają ekonomiczny sposób udostępniania zasobów w wielu bazach danych. Ta opcja puli jest tańsza niż wymaganie, aby każda baza danych była wystarczająco duża, aby uwzględnić szczytowe użycie, które napotyka. Mimo że bazy danych w puli współdzielą dostęp do zasobów, nadal mogą osiągnąć wysoki stopień izolacji wydajności.

Usługa Azure SQL Database udostępnia narzędzia niezbędne do konfigurowania, monitorowania i zarządzania udostępnianiem. Metryki wydajności na poziomie puli i na poziomie bazy danych są dostępne w witrynie Azure Portal oraz za pośrednictwem dzienników usługi Azure Monitor. Metryki mogą zapewnić doskonały wgląd zarówno w wydajność agregowaną, jak i specyficzną dla dzierżawy. Poszczególne bazy danych można przenosić między pulami, aby zapewnić zasoby zarezerwowane do określonej dzierżawy. Te narzędzia umożliwiają zapewnienie dobrej wydajności w ekonomiczny sposób.

Skalowanie operacji dla bazy danych na dzierżawę

Usługa Azure SQL Database ma wiele funkcji zarządzania przeznaczonych do zarządzania dużą liczbą baz danych na dużą skalę, takich jak ponad 100 000 baz danych. Te funkcje sprawiają, że wzorzec bazy danych na dzierżawę jest wiarygodny.

Załóżmy na przykład, że system ma 1000-dzierżawcową bazę danych jako jedyną bazę danych. Baza danych może mieć 20 indeksów. Jeśli system konwertuje na 1000 baz danych z jedną dzierżawą, ilość indeksów wzrośnie do 20 000. W usłudze Azure SQL Database w ramach automatycznego dostrajania funkcje automatycznego indeksowania są domyślnie włączone. Automatyczne indeksowanie zarządza wszystkimi 20 000 indeksami i ich trwającymi optymalizacjami tworzenia i upuszczania. Te zautomatyzowane akcje są wykonywane w ramach pojedynczej bazy danych i nie są one koordynowane ani ograniczone przez podobne akcje w innych bazach danych. Automatyczne indeksowanie traktuje indeksy inaczej w zajętej bazie danych niż w mniej zajętej bazie danych. Ten typ dostosowywania zarządzania indeksami byłby niepraktyczny w skali bazy danych na dzierżawę, gdyby to ogromne zadanie zarządzania musiało zostać wykonane ręcznie.

Inne funkcje zarządzania, które są skalowane dobrze, obejmują następujące elementy:

• Wbudowane kopie zapasowe.
• Wysoka dostępność.
• Szyfrowanie na dysku.
• Telemetria wydajności.

Automatyzacja

Operacje zarządzania można wykonywać skryptami i oferować za pomocą modelu devops . Operacje można nawet zautomatyzować i uwidocznić w aplikacji.

Można na przykład zautomatyzować odzyskiwanie pojedynczej dzierżawy do wcześniejszego punktu w czasie. Odzyskiwanie musi tylko przywrócić jedną bazę danych z jedną dzierżawą, która przechowuje dzierżawę. To przywracanie nie ma wpływu na inne dzierżawy, co potwierdza, że operacje zarządzania są na dokładnie szczegółowym poziomie poszczególnych dzierżaw.

E. Aplikacja wielodostępna z wielodostępnymi bazami danych

Innym dostępnym wzorcem jest przechowywanie wielu dzierżaw w wielodostępnej bazie danych. Wystąpienie aplikacji może mieć dowolną liczbę wielodostępnych baz danych. Schemat bazy danych z wieloma dzierżawami musi zawierać co najmniej jedną kolumnę identyfikatora dzierżawy, aby można było selektywnie pobierać dane z dowolnej dzierżawy. Ponadto schemat może wymagać kilku tabel lub kolumn używanych tylko przez podzbiór dzierżaw. Jednak statyczny kod i dane referencyjne są przechowywane tylko raz i są współużytkowane przez wszystkich dzierżawców.

Izolacja dzierżawy jest poświęcana

Dane: wielodostępna baza danych musi poświęcać izolację dzierżawy. Dane wielu dzierżaw są przechowywane razem w jednej bazie danych. Podczas programowania upewnij się, że zapytania nigdy nie uwidaczniają danych z więcej niż jednej dzierżawy. Usługa SQL Database obsługuje zabezpieczenia na poziomie wiersza, które mogą wymuszać, że dane zwracane z zapytania mają zakres do jednej dzierżawy.

Przetwarzanie: wielodostępna baza danych udostępnia zasoby obliczeniowe i magazynowe we wszystkich dzierżawach. Bazę danych jako całość można monitorować, aby upewnić się, że działa w sposób akceptowalny. Jednak system platformy Azure nie ma wbudowanego sposobu monitorowania użycia tych zasobów lub zarządzania nimi przez pojedynczą dzierżawę. W związku z tym baza danych z wieloma dzierżawami wiąże się ze zwiększonym ryzykiem napotkania hałaśliwych sąsiadów, gdzie obciążenie jednej nadaktywnej dzierżawy wpływa na wydajność innych dzierżaw w tej samej bazie danych. Dodatkowe monitorowanie na poziomie aplikacji może monitorować wydajność na poziomie dzierżawy.

Niższy koszt

Ogólnie rzecz biorąc, bazy danych z wieloma dzierżawami mają najniższy koszt dzierżawy. Koszty zasobów dla pojedynczej bazy danych są niższe niż w przypadku puli elastycznej o równoważnym rozmiarze. Ponadto w przypadku scenariuszy, w których dzierżawcy potrzebują tylko ograniczonego magazynu, potencjalnie miliony dzierżaw może być przechowywanych w jednej bazie danych. Żadna elastyczna pula nie może zawierać milionów baz danych. Jednak rozwiązanie zawierające 1000 baz danych na pulę, z 1000 pulami, może osiągnąć skalę milionów na ryzyko, że stanie się niewygodne do zarządzania.

Dwa warianty modelu bazy danych z wieloma dzierżawami zostały omówione w następujący sposób, z modelem wielodostępnym podzielonym na fragmenty, który jest najbardziej elastyczny i skalowalny.

F. Aplikacja wielodostępna z pojedynczą wielodostępną bazą danych

Najprostszy wzorzec bazy danych z wieloma dzierżawami używa pojedynczej bazy danych do hostowania danych dla wszystkich dzierżaw. W miarę dodawania większej liczby dzierżaw baza danych jest skalowana w górę z większą ilością miejsca do magazynowania i zasobów obliczeniowych. Ta skala w górę może być potrzebna, chociaż zawsze istnieje ostateczny limit skalowania. Jednak na długo przed osiągnięciem tego limitu baza danych staje się nieswoja do zarządzania.

Operacje zarządzania, które koncentrują się na poszczególnych dzierżawach, są bardziej złożone do zaimplementowania w wielodostępnej bazie danych. A na dużą skalę te operacje mogą stać się niedopuszczalnie powolne. Jednym z przykładów jest przywracanie danych do punktu w czasie tylko dla jednej dzierżawy.

G. Aplikacja wielodostępna z podzielonymi na fragmenty bazami danych z wieloma dzierżawami

Większość aplikacji SaaS uzyskuje dostęp do danych tylko jednej dzierżawy jednocześnie. Ten wzorzec dostępu umożliwia dystrybuowanie danych dzierżawy między wieloma bazami danych lub fragmentami, gdzie wszystkie dane dla każdej dzierżawy znajdują się w jednym fragmentie. W połączeniu ze wzorcem bazy danych z wieloma dzierżawami model podzielony na fragmenty umożliwia niemal nieograniczoną skalę.

Zarządzanie fragmentami

Fragmentowanie zwiększa złożoność zarówno do zarządzania projektowego, jak i operacyjnego. Wykaz jest wymagany do utrzymania mapowania między dzierżawami i bazami danych. Ponadto procedury zarządzania są wymagane do zarządzania fragmentami i populacją dzierżawy. Na przykład procedury muszą być zaprojektowane tak, aby dodawać i usuwać fragmenty oraz przenosić dane dzierżawy między fragmentami. Jednym ze sposobów skalowania jest dodanie nowego fragmentu i wypełnienie go nowymi dzierżawami. Innym razem można podzielić gęsto wypełniony fragment na dwa mniej gęsto wypełnione fragmenty. Po przeniesieniu lub zaprzestaniu kilku dzierżaw możesz scalić rozrzedzone fragmenty razem. Scalanie spowodowałoby bardziej ekonomiczne wykorzystanie zasobów. Dzierżawy mogą być również przenoszone między fragmentami, aby zrównoważyć obciążenia.

Usługa SQL Database udostępnia narzędzie do dzielenia/scalania, które działa w połączeniu z biblioteką fragmentowania i bazą danych wykazu. Udostępniona aplikacja może dzielić i scalać fragmenty, a także przenosić dane dzierżawy między fragmentami. Aplikacja utrzymuje również wykaz podczas tych operacji, oznaczając dzierżawy, których dotyczy problem, przed ich przeniesieniem. Po przeniesieniu aplikacja ponownie zaktualizuje katalog przy użyciu nowego mapowania i oznaczy dzierżawę w trybie online.

Mniejsze bazy danych łatwiej zarządzać

Dzięki dystrybucji dzierżaw w wielu bazach danych rozwiązanie wielodostępne podzielone na fragmenty powoduje łatwiejsze zarządzanie mniejszymi bazami danych. Na przykład przywrócenie określonej dzierżawy do wcześniejszego punktu w czasie obejmuje teraz przywrócenie pojedynczej mniejszej bazy danych z kopii zapasowej, a nie większej bazy danych zawierającej wszystkie dzierżawy. Rozmiar bazy danych i liczba dzierżaw na bazę danych można wybrać, aby zrównoważyć obciążenie i nakłady pracy związane z zarządzaniem.

Identyfikator dzierżawy w schemacie

W zależności od używanego podejścia fragmentowania na schemacie bazy danych mogą być nakładane dodatkowe ograniczenia. Aplikacja dzieląca/scalana usługi SQL Database wymaga, aby schemat zawierał klucz fragmentowania, który zazwyczaj jest identyfikatorem dzierżawy. Identyfikator dzierżawy jest wiodącym elementem w kluczu podstawowym wszystkich tabel podzielonych na fragmenty. Identyfikator dzierżawy umożliwia aplikacji dzielenia/scalania szybkie lokalizowanie i przenoszenie danych skojarzonych z określoną dzierżawą.

Elastyczna pula dla fragmentów

Bazy danych z wieloma dzierżawami podzielone na fragmenty można umieszczać w elastycznych pulach. Ogólnie rzecz biorąc, posiadanie wielu baz danych z jedną dzierżawą w puli jest tak ekonomiczne, jak posiadanie wielu dzierżaw w kilku wielodostępnych bazach danych. Wielodostępne bazy danych są korzystne, jeśli istnieje duża liczba stosunkowo nieaktywnych dzierżaw.

H. Hybrydowy model bazy danych z wieloma dzierżawami podzielony na fragmenty

W modelu hybrydowym wszystkie bazy danych mają identyfikator dzierżawy w schemacie. Bazy danych mogą przechowywać więcej niż jedną dzierżawę, a bazy danych mogą być podzielone na fragmenty. W sensie schematu są to wszystkie bazy danych z wieloma dzierżawami. Jednak w praktyce niektóre z tych baz danych zawierają tylko jedną dzierżawę. Niezależnie od tego, ilość dzierżaw przechowywanych w danej bazie danych nie ma wpływu na schemat bazy danych.

Przenoszenie dzierżaw

W dowolnym momencie możesz przenieść określoną dzierżawę do własnej wielodostępnej bazy danych. W dowolnym momencie możesz zmienić zdanie i przenieść dzierżawę z powrotem do bazy danych zawierającej wiele dzierżaw. Dzierżawę można również przypisać do nowej bazy danych z jedną dzierżawą podczas aprowizacji nowej bazy danych.

Model hybrydowy świeci, gdy istnieją duże różnice między potrzebami zasobów w zakresie możliwych do zidentyfikowania grup dzierżaw. Załóżmy na przykład, że dzierżawcy uczestniczący w bezpłatnej wersji próbnej nie mają gwarantowanego wysokiego poziomu wydajności subskrybowanych dzierżaw. Zasady mogą dotyczyć dzierżaw w fazie bezpłatnej wersji próbnej, która będzie przechowywana w bazie danych z wieloma dzierżawami, która jest współdzielona przez wszystkie dzierżawy bezpłatnej wersji próbnej. Gdy dzierżawa bezpłatnej wersji próbnej subskrybuje podstawową warstwę usługi, dzierżawa może zostać przeniesiona do innej wielodostępnej bazy danych, która może mieć mniej dzierżaw. Subskrybent, który płaci za warstwę usługi Premium, może zostać przeniesiony do własnej bazy danych z jedną dzierżawą.

Pule

W tym modelu hybrydowym bazy danych z jedną dzierżawą dla dzierżawców subskrybentów można umieścić w pulach zasobów, aby zmniejszyć koszty bazy danych na dzierżawę. Odbywa się to również w modelu bazy danych na dzierżawę.

I. Modele dzierżawy porównane

W poniższej tabeli przedstawiono podsumowanie różnic między głównymi modelami dzierżawy.

Miara	Aplikacja autonomiczna	Baza danych na dzierżawę	Podzielone na fragmenty wielodostępne
Skalowanie	Średnia 1–100s	Bardzo wysoka 1–100 000s	Nieograniczony 1–1 000 000s
Izolacja dzierżawy	Bardzo wysoka	Maksimum	Niskie; z wyjątkiem jednej dzierżawy (która jest sama w bazie danych MT).
Koszt bazy danych na dzierżawę	Wysokiej; jest wielkością szczytów.	Niskie; używane pule.	Najniższa, w przypadku małych dzierżaw w bazach danych MT.
Monitorowanie wydajności i zarządzanie	Tylko dla dzierżawy	Agregacja i dzierżawa	Agregacji; chociaż jest tylko dla poszczególnych dzierżawców dla pojedynczych.
Złożoność programowania	Minimum	Minimum	Średni; ze względu na fragmentowanie.
Złożoność operacyjna	Niski poziom. Indywidualnie proste, złożone na dużą skalę.	Niski średni. Wzorce dotyczą złożoności na dużą skalę.	Niski poziom. Zarządzanie poszczególnymi dzierżawami jest złożone.

Następne kroki

• Wdrażanie i eksplorowanie wielodostępnej aplikacji Wingtip korzystającej z modelu SaaS bazy danych na dzierżawę — Azure SQL Database

• Przykładowa aplikacja dzierżawy usługi Azure SQL Database w usłudze Wingtip Tickets — Zapraszamy!