Wdrażanie wielu najemców w Cloud Spanner

W tym dokumencie opisano różne sposoby wdrażania wielu najemców w Cloud Spanner. Omawia też wzorce zarządzania danymi i zarządzanie cyklem życia najemców.

Wiele najemców to sytuacja, gdy jedno lub kilka wystąpień aplikacji obsługuje wielu najemców lub klientów. Ten wzorzec oprogramowania może być skalowany od jednego najemcy lub klienta do setek lub tysięcy. To podejście ma kluczowe znaczenie w przypadku platform w chmurze, w których podstawowa infrastruktura jest współdzielona przez wiele organizacji.

Wyobraź sobie, że wiele najemców to forma podziału na podstawie udostępnionych zasobów komputerowych, takich jak bazy danych. Odpowiednikiem są najemcy w budynku mieszkalnym: wspólna infrastruktura, ale dedykowana przestrzeń najemcy. Korzystanie z wielu najemców jest częścią większości aplikacji (SaaS).

Ten dokument jest przeznaczony dla architektów baz danych, architektów danych i inżynierów, którzy implementują aplikacje działające w wielu dzierżawach jako swoje relacyjne bazy danych. Korzystając z tego kontekstu, opisujemy różne sposoby przechowywania danych o wielu najemcach. Terminy „najemca”, „klient” i „organizacja” są używane wymiennie w całym artykule do wskazania podmiotu, który uzyskuje dostęp do aplikacji obejmującej wielu najemców.

W tym artykule wykorzystujemy przykład dostawcy zasobów SAAS zajmującego się zasobami ludzkimi. W tym przykładzie kilku klientów dostawcy działu kadr musi mieć dostęp do aplikacji dla wielu najemców. Tacy klienci są nazywani najemcami.

Spanner to w pełni zarządzana, rozproszona i spójna baza danych Google Cloud, która łączy zalety modelu relacyjnej bazy danych z nieskorelacyjną skalowalnością w poziomie. Spanner ma semantykę relacyjną - ze schematami, wymuszanymi typami danych, wysoką spójnością, transakcjami ACID z wieloma wyrażeniami i językiem zapytań SQL implementującym ANSI 2011 SQL.

Spanner zapewnia brak przestoju w przypadku planowanych prac konserwacyjnych lub awarii regionu z gwarancją dostępności {999%. Obsługuje nowoczesne aplikacje dla wielu najemców, oferując wysoką dostępność i skalowalność. W tym artykule omawiamy różne rozwiązania związane z architekturą, które pozwalają wdrożyć wiele najemców w Spanner.

Kryteria mapowania danych najemcy

W aplikacji obsługującej wielu najemców dane każdego z najemców są wyodrębniane w jednej z kilku podejść dotyczących architektury w bazie danych Spanner. Poniższa lista przedstawia różne rozwiązania związane z architekturą używane do mapowania danych najemcy na Spanner:

  • Wystąpienie: najemca znajduje się tylko w jednej instancji Spanner i ma dokładnie jedną bazę danych dla tego najemcy.
  • Baza danych: najemca znajduje się w bazie danych w jednej instancji Spanner zawierającej wiele baz danych.
  • Schemat: najemca znajduje się w tabelach na wyłączność w bazie danych, a w tej samej bazie danych może znajdować się kilka najemców.
  • Tabela: dane najemcy to wiersze w tabelach bazy danych. Te tabele są udostępniane innym najemcom.

Powyższe kryteria są nazywane wzorcami zarządzania danymi i zostały szczegółowo omówione w sekcji Wzorce zarządzania wieloma danymi. Dyskusja opiera się na następujących kryteriach:

  • Isolation: izolacja danych wielu najemców jest bardzo ważna dla wielu najemców. Wydzielenie jest uzależnione od wyborów kryteriów w innych kategoriach - na przykład niektóre wymagania prawne i zgodności mogą narzucać większą izolację.
  • Sprawność: łatwość wprowadzania i wyłączania działań najemcy w zakresie tworzenia instancji, bazy danych lub tabeli.
  • Operacje: dostępność lub złożoność implementacji typowych, dzierżawionych operacji bazodanowych i administracyjnych, takich jak regularne prace konserwacyjne, rejestrowanie, tworzenie kopii zapasowych i odzyskiwanie danych po awarii.
  • Skala: możliwość płynnego skalowania w celu umożliwienia przyszłego rozwoju. Opis każdego wzorca zawiera liczbę najemców obsługiwanych przez wzorzec.
  • Wydajność: możliwość przydzielania wyłącznych zasobów każdemu najemcy, reagowania na zjawisko hałaśliwego sąsiada oraz włączania przewidywalnej wydajności odczytu i zapisu dla każdego najemcy.
  • Przepisy i zgodność: możliwość spełnienia wymogów branż i krajów o wysokim stopniu regulacji, które wymagają pełnej kontroli zasobów i działań konserwacyjnych - na przykład wymagania dotyczące miejsca zamieszkania w przypadku Francji wymagają, by informacje umożliwiające identyfikację osób były przechowywane fizycznie. wyłącznie na terenie Francji.

Każdy wzorzec zarządzania danymi w odniesieniu do tych kryteriów został opisany w następnej sekcji. Używając tych samych kryteriów podczas wybierania wzorca zarządzania danymi dla określonego zbioru najemców.

Wzorce zarządzania danymi o wielu najemcach

W poniższych sekcjach opisano cztery główne wzorce zarządzania danymi: wystąpienie, baza danych, schemat i tabela.

Instancja

Aby zapewnić pełną izolację, wzorzec zarządzania danymi instancji przechowuje dane każdego najemcy we własnej instancji Spanner i bazie danych. Wystąpienie Spanner może mieć jedną lub więcej baz danych. W przypadku tego wzorca tworzona jest tylko jedna baza danych. Dla omówionej wcześniej aplikacji działu kadr tworzona jest osobna instancja Spanner z jedną bazą danych dla każdej organizacji klienta.

Jak widać na poniższym diagramie, wzorzec zarządzania danymi ma jednego najemcę.

Wzorzec zarządzania danymi instancji zawiera jeden najemcę.

Mając osobne instancje dla każdego najemcy, możesz używać osobnych projektów Google Cloud, by osiągnąć oddzielne granice zaufania dla różnych najemców. Dodatkową korzyścią jest to, że każda konfiguracja instancji może być wybierana na podstawie lokalizacji każdego najemcy (regionalnego lub multiregionalnego), optymalizując elastyczność i wydajność lokalizacji.

Możesz łatwo skalować architekturę do dowolnej liczby najemców. Dostawcy SaaS mogą utworzyć dowolną liczbę instancji w wybranych regionach bez żadnych ograniczeń.

Poniższa tabela przedstawia wpływ wzorca zarządzania danymi instancji na różne kryteria.

Kryteria Wystąpienie - jeden wzorzec zarządzania danymi instancji najemcy
Izolacja
  • Najwyższy poziom izolacji
  • Zasoby bazy danych nie są udostępniane
Zwinność
  • Wdrożenie i wyłączenie usługi wymaga znacznej konfiguracji lub wycofania w przypadku:
    • Wystąpienie Spanner
    • Zabezpieczenia specyficzne dla instancji
    • Łączność specyficzna dla instancji
  • Wprowadzenie i wyłączenie może zostać zautomatyzowane przy użyciu infrastruktury jako kodu (IaC)
Operacje
  • Niezależne kopie zapasowe dla każdego najemcy
  • Oddzielne i elastyczne harmonogramy tworzenia kopii zapasowych
  • Większe koszty operacyjne
    • Duża liczba instancji do zarządzania i utrzymywania (skalowanie, monitorowanie, rejestrowanie i dostrajanie wydajności)
Skaluj
  • Bardzo skalowalna baza danych
  • Nieograniczony rozwój dzięki dodawaniu węzłów
  • Nieograniczona liczba najemców
  • Wystąpienie Spanner jest dostępne dla każdego najemcy
Wyniki
  • Każdy najemca w oddzielnej instancji
  • Brak rywalizacji o zasoby
  • Dostosowane dostosowywanie skuteczności i rozwiązywanie problemów dla każdego najemcy
Wymagania prawne i dotyczące zgodności
  • Przechowuj dane w określonym regionie
  • Wdrażaj określone procedury zabezpieczeń, tworzenia kopii zapasowych lub przeprowadzania audytów zgodnie z wymaganiami firm lub instytucji rządowych

Podsumowując, najważniejsze wnioski:

  • Zaleta: najwyższy poziom prywatności
  • Wada: największe obciążenie operacyjne

Wzorzec zarządzania danymi instancji najlepiej sprawdza się w następujących sytuacjach:

  • Poszczególni najemcy są rozproszeni w wielu regionach i potrzebują zlokalizowanego rozwiązania.
  • Wymagania prawne i dotyczące zgodności dla niektórych najemców wymagają wyższych poziomów zabezpieczeń i protokołów kontroli.
  • Wielkość najemcy jest bardzo zróżnicowana, więc udostępnianie zasobów dużym najemcom o dużym natężeniu ruchu może spowodować konflikt i wzajemną dezorientację.

Baza danych

We wzorcu zarządzania danymi bazy danych każdy najemca znajduje się w bazie danych w ramach jednej instancji Spanner. W jednej instancji może znajdować się wiele baz danych. Jeśli jedno wystąpienie jest niewystarczające dla liczby najemców, utwórz wiele wystąpień. Ten wzorzec oznacza, że jedna instancja Spanner jest współużytkowana przez wielu najemców.

W Spanner obowiązuje stały limit 100 baz danych na instancję. Ten limit oznacza, że jeśli dostawca usługi SaaS musi skalować ponad 100 klientów, musi utworzyć wiele wystąpień Spanner i z nich korzystać.

W przypadku aplikacji działu kadr dostawca SaaS tworzy każdego najemcę i zarządza nim w osobnej bazie danych w instancji Spanner.

Jak widać na poniższym diagramie, wzorzec zarządzania danymi ma jednego najemcę na bazę danych.

Wzorzec zarządzania danymi bazy danych zawiera po jednym najemcy.

Wzorzec zarządzania danymi bazy danych umożliwia logiczną izolację na poziomie bazy danych dla danych różnych najemców. Ponieważ jednak jest to jedna instancja Spanner, wszystkie bazy danych najemców mają tę samą konfigurację regionalną oraz bazową konfigurację obliczeń i pamięci.

Poniższa tabela przedstawia wpływ wzorca zarządzania danymi bazy danych na różne kryteria.

Kryteria Baza danych - jeden najemca na wzorzec zarządzania danymi bazy danych
Izolacja
  • Pełna logiczna izolacja na poziomie bazy danych
  • Wspólne zasoby infrastruktury podstawowej
Zwinność
  • Wymaga utworzenia lub usunięcia bazy danych i wszelkich specjalnych ustawień zabezpieczeń
  • Automatyzacja rejestracji i wdrażania jest realizowana przez IAC
Operacje
  • Niezależne kopie zapasowe dla każdego najemcy
  • Elastyczny harmonogram
  • Mniej pracy w porównaniu ze schematem instancji
    • Jedno wystąpienie do monitorowania maksymalnie 100 baz danych
Skaluj
  • Bardzo skalowalna baza danych
  • Nieograniczone instancje
  • Zezwala na tysiące węzłów
  • Limit 100 baz danych na instancję
    • Dla każdego 100 najemców utwórz nową instancję Spanner
Wyniki
  • Konflikt zasobów między wieloma bazami danych
    • Baza danych rozproszona w węzłach instancji Spanner
    • Bazy danych mają wspólną infrastrukturę
  • Hałaśliwe sąsiedzi mają wpływ na skuteczność
Wymagania prawne i dotyczące zgodności
  • Region lokalizacji musi być zgodny z regionem instancji, aby spełnić określone wymagania prawne dotyczące miejsca zamieszkania

Podsumowując, najważniejsze wnioski:

  • Zaleta: wyższy poziom prywatności
  • Wada: ograniczona liczba najemców na instancję. Brak elastyczności lokalizacji

Wzorzec zarządzania danymi bazy danych najlepiej sprawdza się w następujących sytuacjach:

  • Wielu klientów znajduje się w tym samym miejscu zamieszkania - na przykład we Francji lub w Wielkiej Brytanii - i/lub podlega temu samemu organowi nadzorczemu.
  • Najemcy wymagają systemowego rozdzielania danych i tworzenia kopii zapasowych/przywracania, ale nie przeszkadza im udostępnianie zasobów infrastruktury.

Schemat

W schemacie zarządzania danymi schematu jedna baza danych - która zawiera jeden schemat - jest używana dla wielu najemców, a dla każdego najemcy jest używany osobny zestaw tabel. Tabele te można rozróżnić, umieszczając tenant ID w nazwach tabel jako prefiks lub sufiks.

Ten wzorzec zarządzania danymi, polegający na stosowaniu osobnego zestawu tabel dla każdego najemcy, zapewnia znacznie niższą izolację w porównaniu z poprzednimi opcjami (wzorcem zarządzania instancją i bazami danych). Wzorzec ten upraszcza też wdrażanie - obejmuje tworzenie nowych tabel oraz powiązanej z nimi integralności i indeksów.

Ważnym zastrzeżeniem jest to, że uprawnienia dostępu do usługi Spanner za pomocą zarządzania tożsamościami i dostępem są przyznawane tylko na poziomie instancji lub bazy danych. Nie można przyznać uprawnień dostępu na poziomie tabeli. Istnieje również limit 5000 tabel na bazę danych. W przypadku wielu klientów to ograniczenie ogranicza możliwość korzystania z aplikacji.

Ponadto użycie oddzielnych tabel dla każdego klienta może spowodować powstanie dużej liczby operacji aktualizacji schematu. Usunięcie takiego zaległości zajmuje dużo czasu.

W przypadku aplikacji działu kadr dostawca SaaS może utworzyć zestaw tabel dla każdego klienta z prefiksem tenant ID w nazwach tabel, na przykład customer1_employee, customer1_payroll, customer1_department.

Jak widać na poniższym diagramie, wzorzec zarządzania danymi schematu ma jeden zestaw tabel dla każdego najemcy.

Wzorzec zarządzania danymi schematu ma jeden zestaw tabel dla każdego najemcy.

W poniższej tabeli opisano wpływ wzorca zarządzania danymi schematu na różne kryteria.

Kryteria Schemat - jeden zestaw tabel dla każdego wzorca zarządzania danymi najemcy
Izolacja
  • Niski poziom izolacji
  • Brak zabezpieczeń na poziomie tabeli
Zwinność
  • Wprowadzenie klienta jest trywialne
    • Tworzenie nowych tabel
    • Tworzenie powiązanych kluczy i indeksów
  • Rezygnacja klienta oznacza usunięcie tabel
    • Może mieć tymczasowy negatywny wpływ na skuteczność innych najemców w bazie danych
Operacje
  • Brak oddzielnych operacji dla najemców
  • Kopia zapasowa, monitorowanie i rejestrowanie muszą być zaimplementowane jako osobne funkcje aplikacji lub jako skrypty narzędziowe
Skaluj
  • Tysiące węzłów
  • Nieograniczony rozwój najemców
  • Jedna baza danych może zawierać tylko 5000 tabel
    • Tylko minimalna liczba (5000 / {liczba tabel dla najemcy}) liczby najemców w każdej bazie danych
    • Gdy baza danych przekroczy 5000 tabel, dodaj nową bazę danych dla dodatkowych najemców
Wyniki
  • Możliwy jest wysoki poziom rywalizacji o zasoby
  • Zadbaj o dobrą skuteczność, osobno projektując indeksy dla każdego zestawu tabel
Wymagania prawne i dotyczące zgodności
  • Region lokalizacji musi być zgodny z określonymi wymaganiami prawnymi dotyczącymi pobytu
  • Wdrażanie określonych ustawień zabezpieczeń i kontroli wpływa na wszystkich najemców znajdujących się w tej samej bazie danych

Podsumowując, najważniejsze wnioski:

  • Zaleta: wdrożenie jest proste
  • Wada: większe koszty operacyjne. brak ustawień zabezpieczeń na poziomie tabeli

Schemat zarządzania danymi schematu najlepiej sprawdza się w następujących sytuacjach:

  • Wewnętrzne aplikacje przeznaczone dla różnych działów, w których ścisła izolacja zabezpieczeń danych nie jest istotnym problemem w porównaniu z łatwością obsługi.
  • Aplikacje dla wielu najemców, w przypadku których dane nie wymagają ścisłej separacji ze względu na wymagania prawne lub regulacyjne.

Mimo że w bazie danych można utworzyć kilka zestawów tabel (każdy zestaw reprezentuje najemcę), jest to najmniej idealny wzorzec z punktu widzenia bazy danych. Główną przyczyną jest to, że tabele muszą być zgodne z konwencjami nazewnictwa. Aplikacja i wszelkie narzędzia do zarządzania bazami danych (na przykład IDE i narzędzia do migracji schematów) muszą znać konwencję nazewnictwa. Ponadto jeśli liczba tabel jest wystarczająco duża dla każdego najemcy, schemat zarządzania danymi schematu nie zapewnia znacznego skalowania.

Lepszym rozwiązaniem jest przejście do jednej bazy danych na najemcę i zwiększenie liczby instancji lub przejście na wzorzec zarządzania danymi w tabeli.

Tabela

Ostateczny wzorzec zarządzania danymi obsługuje wielu najemców ze wspólnym zestawem tabel. Każda tabela zawiera dane kilku najemców. Ten wzorzec zarządzania danymi reprezentuje najwyższy poziom wielu najemców, gdzie wszystko - od infrastruktury przez schemat po model danych - jest współdzielone przez wielu najemców. W tabeli wiersze są dzielone na podstawie kluczy głównych, przy czym pierwszym elementem klucza jest tenant ID. Z punktu widzenia skalowania Spanner najlepiej obsługuje ten wzorzec, ponieważ może skalować tabele bez ograniczeń.

W przypadku aplikacji kadrowej kluczem tabeli płac może być kombinacja customerID i payrollID.

Jak widać na poniższym diagramie, wzorzec zarządzania danymi w tabeli zawiera jedną tabelę dla kilku najemców.

Wzorzec zarządzania danymi w tabeli korzysta z jednej tabeli dla kilku najemców.

Podobnie jak w przypadku schematu, dostęp do danych we wzorcu tabeli nie może być kontrolowany oddzielnie dla różnych najemców. Zmniejszenie liczby tabel oznacza, że operacje aktualizacji schematu są wykonywane szybciej, gdy każdy najemca ma własną tabelę bazy danych. W dużym stopniu upraszcza to wdrażanie, rezygnację i obsługę.

Poniższa tabela przedstawia wpływ wzorca zarządzania danymi w tabeli na różne kryteria.

Kryteria Tabela - jedna tabela dla kilku wzorców zarządzania danymi najemców
Izolacja
  • Najniższy poziom izolacji
  • Brak zabezpieczeń na poziomie najemcy
Zwinność
  • Konfiguracja nie wymaga konfiguracji po stronie bazy danych
    • Aplikacja może zapisywać dane bezpośrednio w istniejących tabelach
  • Rezygnacja oznacza usunięcie wierszy klienta w tabeli
Operacje
  • Brak oddzielnych operacji dla najemców, w tym tworzenia kopii zapasowych, monitorowania i rejestrowania
  • Niewielkie obciążenie lub brak narzutu wraz ze wzrostem liczby najemców
Skaluj
  • Skaluje się do tysięcy węzłów
  • Może dostosować się do każdego poziomu rozwoju najemców
  • Obsługuje nieograniczoną liczbę najemców
Wyniki
  • Wzorzec działa dobrze w kontekście Spanner
  • Pamięć rozproszona, przetwarzanie i równoważenie obciążenia mogą z łatwością współpracować z tym wzorcem
  • Jeśli główne przestrzenie klucza nie są projektowane z rozwagą, możliwe jest wystąpienie wysokiego poziomu konfliktu zasobów (głośny sąsiad)
    • Może zapobiec równoczesności i dystrybucji
  • Przestrzeganie sprawdzonych metod jest bardzo ważne
  • Usunięcie danych najemcy może mieć tymczasowy wpływ na obciążenie
Wymagania prawne i dotyczące zgodności
  • Lokalizacja musi być zgodna z obowiązującymi przepisami dotyczącymi pobytu
  • Wzorzec nie może zapewniać partycjonowania na poziomie systemu (w porównaniu do wzorca instancji lub bazy danych)
  • Wdrażanie konkretnych ustawień zabezpieczeń i kontroli wpływa na wszystkich najemców

Podsumowując, najważniejsze wnioski:

  • Zaleta: duża skalowalność. ma niski nakład pracy
  • Wada: duża rywalizacja o zasoby; brak kontroli bezpieczeństwa dla każdego najemcy

Ten wzorzec najlepiej sprawdza się w następujących sytuacjach:

  • Aplikacje wewnętrzne przeznaczone dla różnych działów, w których ścisła izolacja zabezpieczeń danych nie stanowi istotnego problemu w porównaniu z łatwością obsługi.
  • Maksymalne udostępnianie zasobów dla najemców korzystających z bezpłatnych funkcji aplikacji przy jednoczesnym minimalizowaniu obsługi administracyjnej zasobów.

Wzorce zarządzania danymi i cykl życia najemców

W poniższej tabeli porównano różne wzorce zarządzania danymi we wszystkich kryteriach.

Instancja Baza danych Schemat Tabela
izolacja, Ukończone Ukończone Niski Najniższa
Zwinność Niski Umiarkowana Umiarkowana Najwyższe
Łatwość obsługi Wysoki Wysoki Niski Niski
Skala Wysoki Ograniczona Potencjalnie bardzo ograniczony Wysoki
Skuteczność* Wysoki Umiarkowana Umiarkowana Potencjalnie wysoki
Przepisy i zgodność Najwyższe Wysoki Niski Niski

* Skuteczność zależy w dużym stopniu od projektu schematu i sprawdzonych metod dotyczących zapytań. Podane tu wartości są tylko średnimi oczekiwaniami.

Najlepszymi wzorcami zarządzania danymi w przypadku konkretnej aplikacji dla wielu najemców są te, które spełniają większość jej wymagań na podstawie kryteriów. Jeśli określone kryterium nie jest wymagane, możesz zignorować wiersz, w którym się znajduje.

Połączone wzorce zarządzania danymi

Często wystarczy jeden wzorzec zarządzania danymi, aby spełnić wymagania aplikacji obejmującej wielu najemców. W takim przypadku projekt może przyjmować jeden wzorzec zarządzania danymi.

Niektóre aplikacje obsługujące wielu najemców wymagają jednak stosowania kilku wzorców zarządzania danymi jednocześnie - na przykład aplikacji obsługującej wiele najemców, która obsługuje poziomy bezpłatne, standardowe i klasy korporacyjne.

  • Poziom bezpłatny:

    • Musi być opłacalny
    • Musi mieć górny limit danych
    • Zwykle obsługuje ograniczoną funkcjonalność
    • Wzorzec zarządzania danymi w tabeli jest dobrym kandydatem na dowolny poziom
      • Zarządzanie najemcami jest proste
      • Nie musisz tworzyć konkretnych ani wyłącznych zasobów dla najemców
  • Poziom zwykły:

    • To dobre rozwiązanie dla klientów, którzy nie mają wyraźnie określonych wymagań dotyczących skalowania lub izolowania
    • Wzorzec zarządzania danymi schematu lub wzorzec zarządzania danymi bazy danych to dobre rozwiązanie w zakresie standardowej
      • Tabele i indeksy są dostępne tylko dla najemcy
      • Tworzenie kopii zapasowej jest łatwe we wzorcu zarządzania danymi w bazie danych
      • Kopia zapasowa nie jest obsługiwana dla wzorca zarządzania danymi schematu
        • Kopia zapasowa najemcy musi być zaimplementowana jako narzędzie poza Spanner
  • Poziom korporacyjny:

    • Zazwyczaj jest to zaawansowany poziom z pełną niezależnością we wszystkich aspektach
    • Najemca ma specjalne zasoby, które obejmują dedykowane skalowanie i pełną izolację
    • Wzorzec zarządzania danymi instancji jest odpowiedni dla warstwy biznesowej

Sprawdzoną metodą jest zachowanie różnych wzorców zarządzania danymi w różnych bazach danych. Chociaż w bazie danych Spanner można łączyć różne wzorce zarządzania danymi, utrudnia to wdrażanie logiki dostępu i operacji w całym cyklu życia.

W sekcji Projekt aplikacji opisano kilka kwestii związanych z projektowaniem aplikacji dla wielu najemców, które mają zastosowanie przy stosowaniu jednego wzorca zarządzania danymi lub kilku wzorców zarządzania danymi.

Zarządzanie cyklem życia najemców

Najemcy mają cykl życia. Dlatego musisz zaimplementować odpowiednie operacje zarządzania w aplikacji obsługującej wiele najemców. Oprócz podstawowych czynności związanych z tworzeniem, aktualizowaniem i usuwaniem najemców rozważ następujące dodatkowe operacje związane z danymi:

  • Eksportowanie danych najemcy:

    • Podczas usuwania najemcy najlepiej jest najpierw wyeksportować jego dane, a być może nawet udostępnić mu zbiór danych.
    • Jeśli korzystasz z tabeli lub schematu zarządzania danymi schematu, system aplikacji obsługujący wiele najemców musi zaimplementować eksport lub zmapować go na funkcję bazy danych (eksport bazy danych).
  • Tworzenie kopii zapasowej danych najemcy:

    • Jeśli używasz wzorca zarządzania danymi instancji lub bazy danych i tworzysz kopie zapasowe danych dla poszczególnych najemców, użyj funkcji eksportowania lub tworzenia kopii zapasowej bazy danych.
    • Gdy używasz schematu lub tabeli do zarządzania danymi i tworzysz kopie zapasowe danych dla poszczególnych najemców, ta aplikacja musi być zaimplementowana. Baza danych Spanner nie może określić, które dane należą do danego najemcy.
  • Przenoszenie danych najemcy:

    • Przenoszenie najemcy z jednego wzorca zarządzania danymi do innego (lub przenoszenie go w obrębie tego samego wzorca zarządzania danymi między instancjami lub bazami danych) wymaga wyodrębnienia danych z wzorca zarządzania danymi w tabeli i wstawienia ich do wzorca zarządzania danymi w bazie danych.

    • Innym sposobem na przeniesienie najemców jest złagodzenie sytuacji, w której panuje hałaśliwa sytuacja.

Projekt aplikacji

Podczas projektowania aplikacji dla wielu najemców zastosuj logikę biznesową uwzględniającą najemcę. Oznacza to, że za każdym razem, gdy aplikacja uruchamia logikę biznesową, musi znajdować się w kontekście znanego najemcy.

Z punktu widzenia bazy danych projekt aplikacji oznacza, że każde zapytanie musi być zgodne z wzorcem zarządzania danymi, w którym znajduje się najemca. W poniższych sekcjach omówiono główne zagadnienia związane z projektowaniem aplikacji dla wielu najemców.

Dynamiczne połączenie z najemcą i konfiguracja zapytania

Dynamiczne mapowanie danych najemców na żądania aplikacji najemców korzysta z konfiguracji mapowania:

  • W przypadku wzorców zarządzania danymi bazy danych lub wzorców zarządzania instancjami ciąg połączenia jest wystarczający do uzyskania dostępu do danych najemcy.
  • W przypadku wzorców zarządzania danymi schematu należy określić prawidłowe nazwy tabel.
  • W przypadku wzorców zarządzania danymi w tabeli zapytania muszą być wykonywane względem bazy danych. Użyj odpowiednich prognoz, by pobrać dane konkretnego najemcy.

Najemca może mieszkać w dowolnym z czterech wzorców zarządzania danymi. Poniższa implementacja mapowania dotyczy konfiguracji połączenia dla ogólnego przypadku aplikacji obsługującej wiele najemców, która korzysta jednocześnie ze wszystkich wzorców zarządzania danymi. Gdy dany najemca korzysta z jednego wzorca, niektóre aplikacje obsługujące wielu najemców używają jednego wzorca zarządzania danymi dla wszystkich najemców. Ten przypadek jest domyślnie omówiony przez następujące mapowanie.

Jeśli najemca korzysta z logiki biznesowej (na przykład pracownik loguje się przy użyciu identyfikatora najemcy), musi ona określić wzorzec zarządzania danymi najemcy, lokalizację danych dla danego identyfikatora najemcy i opcjonalnie nazwę tabeli. konwencja (dla wzorca schematu).

Ta logika aplikacji wymaga mapowania wzorców zarządzania najemcą i danymi. W poniższym przykładzie kodu connection string odnosi się do bazy danych, w której znajdują się dane najemcy. Przykład identyfikuje instancję Spanner i bazę danych. W przypadku instancji wzorców zarządzania danymi i bazy danych wystarczy, że aplikacja nawiąże połączenia i wykona zapytania:

tenant id -> (data management pattern,
             database connection string,
             [table_prefix])

Wzorzec do zarządzania danymi schematów i tabel jest wymagany.

Schemat zarządzania danymi schematu

W przypadku wzorca zarządzania danymi schematu w tej samej bazie danych znajduje się kilku najemców. Każdy najemca ma własny zestaw tabel. Tabele są rozróżniane według nazw. Która tabela należy do którego najemcy jest decydująca?

Jednym z nich jest poprzedzenie nazw tabel identyfikatorami najemców - na przykład tabela EMPLOYEE ma nazwę T356_EMPLOYEE dla najemcy o identyfikatorze 356. Przed wysłaniem zapytania do bazy danych zwróconej przez mapowanie aplikacja musi poprzedzić każdą tabelę prefiksem Ttenant ID.

Innym sposobem jest dołączenie table_prefix do mapowania używanego w zapytaniu, by znaleźć odpowiednie tabele dla najemcy.

Możliwa jest też metoda mieszana: jeśli wzorzec zarządzania danymi to wzorzec schematu, a prefiks tabeli jest pusty, zostanie zastosowane domyślne mapowanie (nazwy tabel z identyfikatorami najemców).

Wzorzec zarządzania danymi w tabeli

Wzorzec zarządzania tabelą wymaga podobnego projektu. Ten wzorzec obejmuje jeden schemat. Dane najemców są przechowywane jako wiersze. Aby uzyskać dostęp do danych, dołącz do każdego zapytania odpowiedni orzecznik i wybierz odpowiedniego najemcę.

Jednym ze sposobów na znalezienie odpowiedniego najemcy jest umieszczenie w każdej tabeli kolumny o nazwie TENANT. Wartość kolumny to tenant ID. Każde zapytanie musi dołączyć orzeczenie AND TENANT = tenant ID do istniejącej klauzuli WHERE lub dodać klauzulę WHERE z orzeczeniem AND TENANT = tenant ID.

Aby można było nawiązać połączenie z bazy danych i utworzyć odpowiednie zapytania, identyfikator aplikacji musi być dostępny w logice aplikacji. Może być przekazywany jako parametr lub zapisywany jako kontekst wątku.

Niektóre operacje w cyklu życia wymagają zmodyfikowania konfiguracji odwzorowania dzierżawcy na dane - na przykład po przeniesieniu dzierżawcy między wzorcami zarządzania danymi musisz zaktualizować wzorzec zarządzania danymi i ciąg połączenia z bazy danych. Konieczne może być również zaktualizowanie prefiksu tabeli.

Generowanie zapytań i atrybucja

Podstawową zasadą aplikacji dla wielu najemców jest to, że kilku najemców może współdzielić jeden zasób w chmurze. Powyższe wzorce zarządzania danymi należą do tej kategorii, z wyjątkiem sytuacji, w której do jednej instancji Spanner jest przypisany jeden najemca.

Udostępnianie zasobów to nie tylko udostępnianie danych. Udostępniane jest też monitorowanie i rejestrowanie - na przykład we wzorcu zarządzania danymi w tabeli i schemacie zarządzania danymi wszystkie zapytania dla wszystkich najemców są rejestrowane w tym samym dzienniku kontrolnym.

Jeśli zapytanie jest rejestrowane, tekst zapytania musi zostać sprawdzony w celu określenia, dla którego najemcy zostało ono wykonane. We wzorcu zarządzania danymi w tabeli musisz przeanalizować orzeczenie. We wzorcu zarządzania danymi schematu musisz przeanalizować jedną z nazw tabel.

We wzorcu zarządzania danymi bazy danych lub wzorcu zarządzania danymi instancji tekst zapytania nie zawiera żadnych informacji o najemcy. Aby uzyskać informacje o najemcach dla tych wzorców, prześlij zapytanie do tabeli odwzorowania dzierżawionych danych.

Analizowanie dzienników i zapytań byłoby łatwiejsze dzięki określeniu najemcy danego zapytania bez analizowania jego tekstu. Jednym ze sposobów na jednolite zidentyfikowanie najemcy zapytania we wszystkich wzorcach zarządzania danymi jest dodanie komentarza do tekstu zapytania zawierającego parametr tenant ID i (opcjonalnie) element label.

Poniższe zapytanie pozwala wybrać wszystkie dane pracowników najemcy wskazanego przez TENANT 356. Aby uniknąć analizowania składni SQL i wyodrębniania identyfikatora najemcy z prognozy, zostanie on dodany jako komentarz. Komentarz można wyodrębnić bez analizowania składni SQL.

select * from EMPLOYEE
  -- TENANT 356
  where TENANT = 'T356';

lub

select * from T356_EMPLOYEE;
  -- TENANT 356

W tym projekcie każde zapytanie dla najemcy jest przypisywane do tego najemcy niezależnie od wzorca zarządzania danymi. Jeśli najemca zostanie przeniesiony z jednego wzorca zarządzania danymi na inny, tekst zapytania może się zmienić, ale atrybucja pozostanie taka sama w tekście zapytania.

Powyższy przykładowy kod to tylko jedna metoda. Inną metodą jest wstawienie obiektu JSON jako komentarza zamiast etykiety i wartości:

select * from T356_EMPLOYEE;
  -- {"TENANT": 356}

Czynności związane z dostępem najemcy

W zależności od założeń projektowych aplikacja obsługująca wielu najemców może bezpośrednio wdrożyć opisane wcześniej operacje cyklu życia danych lub utworzyć oddzielne narzędzie do zarządzania najemcami.

Niezależnie od strategii implementacji operacje w cyklu życia mogą być uruchamiane w tym samym czasie, gdy logika aplikacji nie jest uruchomiona - na przykład podczas przenoszenia danych z jednego wzorca do zarządzania danymi logika aplikacji nie może być uruchomiona, ponieważ dane w jednej bazie danych. Jeśli dane nie znajdują się w jednej bazie danych, wymagają one dwóch dodatkowych działań z perspektywy aplikacji:

  • Zatrzymywanie najemcy: wyłącza dostęp do całej aplikacji przy jednoczesnym zezwoleniu na cykl życia danych.
  • Początek najemcy: logika aplikacji może uzyskiwać dostęp do danych najemcy, gdy operacje cyklu życia, które zakłócają działanie logiki aplikacji, są wyłączone.

Chociaż nie jest to często używane, awaryjne wyłączenie najemcy może być kolejnym ważnym etapem cyklu życia. Użyj tego wyłączenia, jeśli podejrzewasz, że doszło do naruszenia, i musisz zabronić wszystkim dostępu do danych najemcy - nie tylko logiki aplikacji, ale również operacji w cyklu życia. Naruszenie może pochodzić z bazy danych lub poza nią.

Dostępna jest również odpowiednia operacja cykliczna, która usuwa stan alarmowy. Taka operacja może wymagać, by co najmniej dwóch administratorów zalogowało się jednocześnie, aby wdrożyć wzajemną kontrolę.

Izolacja aplikacji,

Różne wzorce zarządzania danymi obsługują różne stopnie izolowania danych najemcy. Od poziomu najbardziej oddalonego (instancji) do poziomu najniższego poziomu (tabela) można stosować różne stopnie izolacji.

W kontekście aplikacji obejmującej wielu najemców należy podjąć podobną decyzję o wdrożeniu: czy wszyscy najemcy mają dostęp do swoich danych (w zależności od możliwych wzorców zarządzania) przy użyciu tego samego wdrożenia aplikacji? Na przykład jeden klaster Kubernetes może obsługiwać wszystkich najemców, a gdy najemca uzyskuje dostęp do swoich danych, ten sam klaster uruchamia logikę biznesową.

Podobnie jak w przypadku wzorców zarządzania danymi, różni najemcy mogą być kierowani do różnych wdrożeń aplikacji. Duzi najemcy mogą mieć dostęp do wdrożenia aplikacji wyłącznie dla nich, natomiast mniejsi najemcy lub najemcy w warstwie bezpłatnej mają wspólne wdrożenie aplikacji.

Zamiast bezpośrednio porównywać wzorce zarządzania danymi omówione w tym artykule z odpowiednimi wzorcami zarządzania danymi aplikacji, możesz użyć wzorca zarządzania danymi bazy danych, aby wszyscy najemcy korzystali z jednego wdrożenia aplikacji. Wzorzec zarządzania bazami danych może być używany, a wszyscy najemcy korzystają z jednego wdrożenia aplikacji.

Korzystanie z wielu najemców jest ważnym wzorcem zarządzania projektowaniem aplikacji, zwłaszcza gdy wydajność zasobów jest bardzo ważna. Spanner obsługuje kilka wzorców zarządzania danymi - używaj go do wdrażania aplikacji dla wielu najemców. Dzięki bardzo dużej skalowalności i rygorystycznym gwarancjom jakości usług Spanner stanowi idealną bazę danych dla dużych wdrożeń obejmujących wielu najemców.

Co dalej?

  • Poznaj architekturę referencyjną, diagramy, samouczki i sprawdzone metody dotyczące Google Cloud. Zajrzyj do naszego Centrum architektury Cloud.