Udostępnij za pośrednictwem

Obsługa wielu dzierżaw i usługa Azure Cosmos DB

  • Artykuł

W tym artykule opisano funkcje usługi Azure Cosmos DB, których można używać w systemach wielodostępnych. Zawiera wskazówki i przykłady dotyczące korzystania z usługi Azure Cosmos DB w rozwiązaniu wielodostępnym.

Wymagania dotyczące wielu dzierżaw

Podczas planowania rozwiązania wielodostępnego masz dwa kluczowe wymagania:

  • Pomóż zapewnić silną izolację między dzierżawami i spełnić rygorystyczne wymagania dotyczące zabezpieczeń dla tych, którzy ich potrzebują.
  • Utrzymywanie niskich kosztów na dzierżawę. Jako dostawca upewnij się, że koszt uruchamiania aplikacji pozostaje zrównoważony w miarę skalowania.

Te dwa potrzeby mogą często powodować konflikty i wprowadzać kompromis, w którym należy określić priorytety jednej nad drugą. Wskazówki zawarte w tym artykule mogą pomóc lepiej zrozumieć kompromisy, które należy spełnić, aby spełnić te potrzeby. Ten artykuł ułatwia poruszanie się po tych zagadnieniach, dzięki czemu można podejmować świadome decyzje podczas projektowania rozwiązania wielodostępu.

Modele izolacji

Określ poziom izolacji, który jest potrzebny między dzierżawami. Usługa Azure Cosmos DB obsługuje szereg modeli izolacji, ale w przypadku większości rozwiązań zalecamy użycie jednej z następujących strategii:

  • Klucz partycji na dzierżawę jest często używany w przypadku w pełni wielodostępnych rozwiązań, takich jak rozwiązania typu oprogramowanie jako usługa (B2C SaaS, business-to-consumer software as a service).
  • Konto bazy danych na dzierżawę jest często używane w przypadku rozwiązań SaaS typu business-to-business (B2B).

Aby wybrać najbardziej odpowiedni model izolacji, rozważ model biznesowy i wymagania dzierżaw. Na przykład silna izolacja wydajności może nie być priorytetem dla niektórych modeli B2C, w których firma sprzedaje produkt lub usługę bezpośrednio do pojedynczego klienta. Jednak modele B2B mogą określać priorytety silnej izolacji zabezpieczeń i wydajności i mogą wymagać, aby dzierżawcy mieli własne konto aprowizowanej bazy danych.

Można również połączyć wiele modeli, aby dopasować je do różnych potrzeb klientów. Załóżmy na przykład, że tworzysz rozwiązanie SaaS B2B, które sprzedajesz klientom korporacyjnym, i udostępniasz bezpłatną wersję próbną dla potencjalnych nowych klientów. Możesz wdrożyć oddzielne konto bazy danych dla płatnych dzierżaw przedsiębiorstwa, które wymagają silnych gwarancji bezpieczeństwa i izolacji. Możesz również udostępnić konto bazy danych i używać kluczy partycji do izolowania klientów w wersji próbnej.

Model partition-key-per-tenant i model database-account-per-tenant to najbardziej typowe modele izolacji dla rozwiązań wielodostępnych. Te modele zapewniają najlepszą równowagę między izolacją dzierżawy a wydajnością kosztów.

Model partycjonowania na dzierżawę

Jeśli izolujesz dzierżawy według klucza partycji, przepływność jest współdzielona między dzierżawami i zarządzana w tym samym kontenerze.

Uwaga

Jednostka żądania (RU) to logiczna abstrakcja kosztów operacji bazy danych lub zapytania. Zazwyczaj dla obciążenia aprowizujesz zdefiniowaną liczbę jednostek żądań na sekundę (RU/s), która jest nazywana przepływnością.

Świadczenia

  • Efektywność kosztowa: wszystkie dzierżawy są umieszczane w jednym kontenerze, który jest podzielony na partycje według identyfikatora dzierżawy. Takie podejście ma tylko jeden zasób rozliczany, który aprowizuje i współużytuje jednostki RU między wieloma dzierżawami. Ten model jest zwykle bardziej ekonomiczny i łatwiejszy w zarządzaniu niż posiadanie oddzielnych kont dla każdej dzierżawy.

  • Uproszczone zarządzanie: masz mniej kont usługi Azure Cosmos DB do zarządzania.

Kompromisy

  • Rywalizacja o zasoby: współdzielona przepływność (RU/s) między dzierżawami, które znajdują się w tym samym kontenerze, może prowadzić do rywalizacji podczas szczytowego użycia. Ta rywalizacja może tworzyć hałaśliwe problemy sąsiadów i wyzwania związane z wydajnością, jeśli dzierżawcy mają wysokie lub nakładające się obciążenia. Użyj tego modelu izolacji dla obciążeń, które wymagają gwarantowanych jednostek RU w jednej dzierżawie i mogą współdzielić przepływność.

  • Ograniczona izolacja: takie podejście zapewnia izolację logiczną, a nie izolację fizyczną. Może nie spełniać rygorystycznych wymagań izolacji z perspektywy wydajności lub zabezpieczeń.

  • Mniejsza elastyczność: nie można dostosowywać funkcji na poziomie konta, takich jak replikacja geograficzna, przywracanie do punktu w czasie i klucze zarządzane przez klienta, dla każdej dzierżawy, jeśli izolujesz według klucza partycji lub bazy danych lub kontenera.

Funkcje usługi Azure Cosmos DB na potrzeby wielodostępności

  • Kontrolowanie przepływności: Eksploruj funkcje, które mogą pomóc w kontrolowaniu problemu z hałaśliwym sąsiadem, gdy używasz klucza partycji do izolowania dzierżaw. Korzystanie z funkcji, takich jak reallokacja przepływności, pojemność serii i kontrola przepływności w zestawie SDK języka Java.

  • Hierarchiczne klucze partycji: użyj usługi Azure Cosmos DB, aby każda partycja logiczna mogła zwiększyć rozmiar do 20 GB. Jeśli masz jedną dzierżawę, która musi przechowywać ponad 20 GB danych, rozważ rozłożenie danych na wiele partycji logicznych. Na przykład zamiast pojedynczego klucza Contosopartycji programu można dystrybuować klucze partycji, tworząc wiele kluczy partycji dla dzierżawy, takich jak Contoso1 i Contoso2.

    Podczas wykonywania zapytań dotyczących danych dla dzierżawy można użyć WHERE IN klauzuli , aby dopasować wszystkie klucze partycji. Możesz również użyć hierarchicznych kluczy partycji, aby zapewnić duże dzierżawy z magazynem większym niż 20 GB, jeśli masz wysoką kardynalność dzierżaw. W tej metodzie nie trzeba używać syntetycznych kluczy partycji ani wielu wartości klucza partycji na dzierżawę.

    Załóżmy, że masz obciążenie, które izoluje dzierżawy według klucza partycji. Jedna dzierżawa, Contoso, jest większa i większa niż inne, i nadal rośnie rozmiar. Aby uniknąć ryzyka braku możliwości pozyskiwania większej ilości danych dla tej dzierżawy, możesz użyć hierarchicznych kluczy partycji. Określ TenantID jako pierwszy klucz poziomu, a następnie dodaj drugi poziom, taki jak UserId. Jeśli przewidujesz kombinację i UserID w celu utworzenia TenantID partycji logicznych przekraczających limit 20 GB, możesz podzielić partycje dalej na inny poziom, na przykład SessionID. Zapytania, które określają oba TenantID te elementy i TenantID UserID są skutecznie kierowane tylko do podzbioru partycji fizycznych zawierających odpowiednie dane, co pozwala uniknąć pełnego zapytania fan-out. Jeśli kontener ma 1000 partycji fizycznych, ale określona TenantId wartość jest tylko na pięciu partycjach fizycznych, zapytanie jest kierowane do mniejszej liczby odpowiednich partycji fizycznych.

    Jeśli pierwszy poziom nie ma wystarczająco wysokiej kardynalności i osiągniesz limit partycji logicznej 20 GB dla klucza partycji, rozważ użycie syntetycznego klucza partycji zamiast klucza partycji hierarchicznej.

Model bazy danych na dzierżawę

W przypadku izolowania dzierżaw według konta bazy danych każda dzierżawa ma własną przepływność aprowizowaną na poziomie bazy danych lub na poziomie kontenera.

Świadczenia

  • Wysoka izolacja: takie podejście pozwala uniknąć rywalizacji lub interferencji z powodu dedykowanych kont i kontenerów usługi Azure Cosmos DB, które aprowizowały jednostki RU na unikatową dzierżawę.

  • Niestandardowe umowy dotyczące poziomu usług (SLA): każda dzierżawa ma własne konto, dzięki czemu można zapewnić określone dostosowane zasoby, umowy SLA dostępne dla klientów i gwarancje, ponieważ można niezależnie dostroić konto bazy danych każdej dzierżawy na potrzeby przepływności.

  • Zwiększone zabezpieczenia: Izolacja danych fizycznych pomaga zapewnić niezawodne zabezpieczenia, ponieważ klienci mogą włączyć klucze zarządzane przez klienta na poziomie konta na dzierżawę. Dane każdej dzierżawy są izolowane według konta, a nie w tym samym kontenerze.

  • Elastyczność: Dzierżawcy mogą w razie potrzeby włączyć funkcje na poziomie konta, takie jak replikacja geograficzna, przywracanie do punktu w czasie i klucze zarządzane przez klienta.

Kompromisy

  • Zwiększone zarządzanie: takie podejście jest bardziej złożone, ponieważ zarządzasz wieloma kontami usługi Azure Cosmos DB.

  • Wyższe koszty: więcej kont oznacza, że musisz aprowizować przepływność dla każdego zasobu, takiego jak bazy danych lub kontenery, w ramach konta dla każdej dzierżawy. Za każdym razem, gdy zasób aprowizuje jednostki RU, koszty usługi Azure Cosmos DB rosną.

  • Ograniczenia zapytań: wszystkie dzierżawy znajdują się na różnych kontach, więc aplikacje, które wysyłają zapytania do wielu dzierżaw, wymagają wielu wywołań w ramach logiki aplikacji.

Funkcje usługi Azure Cosmos DB na potrzeby wielodostępności

  • Funkcje zabezpieczeń: ten model zapewnia zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem kontroli dostępu opartej na rolach platformy Azure. Ten model zapewnia również izolację zabezpieczeń szyfrowania bazy danych na poziomie dzierżawy za pośrednictwem kluczy zarządzanych przez klienta.

  • Konfiguracja niestandardowa: możesz skonfigurować lokalizację konta bazy danych zgodnie z wymaganiami dzierżawy. Możesz również dostosować konfigurację funkcji usługi Azure Cosmos DB, takich jak replikacja geograficzna i klucze szyfrowania zarządzane przez klienta, zgodnie z wymaganiami każdej dzierżawy.

W przypadku korzystania z dedykowanego konta usługi Azure Cosmos DB na dzierżawę należy wziąć pod uwagę maksymalną liczbę kont usługi Azure Cosmos DB na subskrypcję platformy Azure.

Pełna lista modeli izolacji

Zapotrzebowanie na obciążenie Klucz partycji na dzierżawę (zalecane) Kontener na dzierżawę (współdzielona przepływność) Kontener na dzierżawę (dedykowana przepływność) Baza danych dla każdego dzierżawcy Konto bazy danych na dzierżawę (zalecane)
Zapytania między dzierżawami Łatwe (kontener działa jako granica dla zapytań) Ostateczna Ostateczna Ostateczna Ostateczna
Gęstość dzierżawy Wysoki (najniższy koszt dzierżawy) Śred. Niski Niski Niski
Usuwanie danych dzierżawy Łatwe Łatwe (upuszczanie kontenera po opuszczeniu dzierżawy) Łatwe (upuszczanie kontenera po opuszczeniu dzierżawy) Łatwe (porzucanie bazy danych po opuszczeniu dzierżawy) Łatwe (porzucanie bazy danych po opuszczeniu dzierżawy)
Izolacja zabezpieczeń dostępu do danych Należy zaimplementować w aplikacji Kontrola dostępu oparta na rolach kontenera Kontrola dostępu oparta na rolach kontenera Kontrola dostępu oparta na rolach bazy danych RBAC
Replikacja geograficzna Replikacja geograficzna dla dzierżawy nie jest możliwa Grupowanie dzierżaw w ramach kont bazy danych na podstawie wymagań Grupowanie dzierżaw w ramach kont bazy danych na podstawie wymagań Grupowanie dzierżaw w ramach kont bazy danych na podstawie wymagań Grupowanie dzierżaw w ramach kont bazy danych na podstawie wymagań
Hałaśliwe zapobieganie sąsiadom Nie Nie. Tak Tak Tak
Opóźnienie tworzenia nowej dzierżawy Natychmiastowe Szybkie przetwarzanie Szybkie przetwarzanie Śred. Mała
Zalety modelowania danych Brak Kolokacja jednostki Kolokacja jednostki Wiele kontenerów do modelowania jednostek dzierżawy Wiele kontenerów i baz danych do modelowania dzierżaw
Encryption key Takie same dla wszystkich dzierżaw Takie same dla wszystkich dzierżaw Takie same dla wszystkich dzierżaw Takie same dla wszystkich dzierżaw Klucz zarządzany przez klienta na dzierżawę
Wymagania dotyczące przepływności >0 jednostek RU na dzierżawę >100 jednostek RU na dzierżawę >100 jednostek RU na dzierżawę (tylko z autoskalowaniem, w przeciwnym razie >400 jednostek RU na dzierżawę) >400 jednostek RU na dzierżawę >400 jednostek RU na dzierżawę
Przykładowy przypadek użycia Aplikacje B2C Oferta Standardowa dla aplikacji B2B Oferta Premium dla aplikacji B2B Oferta Premium dla aplikacji B2B Oferta Premium dla aplikacji B2B

Model kontenera na dzierżawę

Dla każdej dzierżawy można aprowizować dedykowane kontenery. Dedykowane kontenery działają dobrze, gdy można połączyć dane przechowywane dla dzierżawy w jednym kontenerze. Ten model zapewnia większą izolację wydajności niż model partition-key-per-tenant. Zapewnia również zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem kontroli dostępu opartej na rolach platformy Azure.

Jeśli używasz kontenera dla każdej dzierżawy, rozważ udostępnienie przepływności innym dzierżawcom przez aprowizowanie przepływności na poziomie bazy danych. Rozważ ograniczenia i limity minimalnej liczby jednostek RU dla bazy danych oraz maksymalną liczbę kontenerów w bazie danych. Należy również rozważyć, czy dzierżawcy wymagają gwarantowanego poziomu wydajności i czy są podatne na hałaśliwy problem sąsiada. Po udostępnieniu przepływności na poziomie bazy danych obciążenie lub magazyn we wszystkich kontenerach powinny być stosunkowo jednolite. W przeciwnym razie może wystąpić problem z hałaśliwym sąsiadem, jeśli masz co najmniej jedną dużą dzierżawę. W razie potrzeby zaplanuj grupowanie tych dzierżaw w różnych bazach danych opartych na wzorcach obciążeń.

Alternatywnie można aprowizować dedykowaną przepływność dla każdego kontenera. Takie podejście działa dobrze w przypadku większych dzierżaw i dzierżaw, które są zagrożone problemem hałaśliwego sąsiada. Jednak przepływność linii bazowej dla każdej dzierżawy jest wyższa, dlatego należy wziąć pod uwagę minimalne wymagania i implikacje kosztów tego modelu.

Jeśli model danych dzierżawy wymaga więcej niż jednej jednostki i jeśli wszystkie jednostki mogą współdzielić ten sam klucz partycji, możesz przenieść je w tym samym kontenerze. Jeśli jednak model danych dzierżawy jest bardziej złożony i wymaga jednostek, które nie mogą współużytkować tego samego klucza partycji, rozważ model bazy danych na dzierżawę lub konto bazy danych na dzierżawę. Aby uzyskać więcej informacji, zobacz Modelowanie i partycjonowanie danych w usłudze Azure Cosmos DB.

Zarządzanie cyklem życia jest zwykle prostsze podczas dedykowania kontenerów do dzierżaw. Dzierżawy można łatwo przenosić między modelami przepływności współużytkowanej i dedykowanej. W przypadku anulowania aprowizacji dzierżawy można szybko usunąć kontener.

Model bazy danych na dzierżawę

Możesz aprowizować bazy danych dla każdej dzierżawy na tym samym koncie bazy danych. Podobnie jak model kontenera na dzierżawę, ten model zapewnia większą izolację wydajności niż model partition-key-per-tenant. Zapewnia również zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem kontroli dostępu opartej na rolach platformy Azure.

Podobnie jak w modelu konta na dzierżawę, takie podejście zapewnia najwyższy poziom izolacji wydajności, ale zapewnia najniższą gęstość dzierżawy. Użyj tej opcji, jeśli każda dzierżawa wymaga bardziej skomplikowanego modelu danych niż jest to możliwe w modelu kontenera na dzierżawę. Możesz też postępować zgodnie z tym podejściem, jeśli tworzenie nowej dzierżawy musi być szybkie lub wolne od jakichkolwiek obciążeń z góry. W przypadku niektórych struktur tworzenia oprogramowania model bazy danych na dzierżawę może być jedynym poziomem izolacji wydajności obsługiwanej przez platformę. Takie struktury zwykle nie obsługują izolacji na poziomie jednostki (kontenera) i kolokacji jednostek.

Funkcje usługi Azure Cosmos DB, które obsługują wielodostępność

Partycjonowanie

Użyj partycji z kontenerami usługi Azure Cosmos DB, aby utworzyć kontenery współużytkujące wiele dzierżaw. Zazwyczaj używasz identyfikatora dzierżawy jako klucza partycji, ale możesz również rozważyć użycie wielu kluczy partycji dla jednej dzierżawy. Dobrze zaplanowana strategia partycjonowania skutecznie implementuje wzorzec fragmentowania. Gdy masz duże kontenery, usługa Azure Cosmos DB rozpowszechnia dzierżawy w wielu węzłach fizycznych, aby osiągnąć wysoki stopień skali.

Rozważ użycie hierarchicznych kluczy partycji, aby zwiększyć wydajność rozwiązania wielodostępnego. Użyj hierarchicznych kluczy partycji, aby utworzyć klucz partycji zawierający wiele wartości. Można na przykład użyć hierarchicznego klucza partycji, który zawiera identyfikator dzierżawy, taki jak identyfikator GUID o wysokiej kardynalności, aby umożliwić niemal nieograniczone skalowanie. Możesz też określić hierarchiczny klucz partycji, który zawiera właściwość, która często używa zapytań. Takie podejście pomaga uniknąć zapytań obejmujących wiele partycji. Użyj hierarchicznych kluczy partycji, aby skalować poza limit partycji logicznej 20 GB na wartość klucza partycji i ograniczyć kosztowne zapytania fan-out.

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

Zarządzanie jednostkami RU

Model cen usługi Azure Cosmos DB jest oparty na liczbie jednostek RU/s aprowizowania lub korzystania z nich. Usługa Azure Cosmos DB oferuje kilka opcji aprowizacji przepływności. W środowisku wielodostępnym wybór wpływa na wydajność i cenę zasobów usługi Azure Cosmos DB.

W przypadku dzierżaw, które wymagają gwarantowanej wydajności i izolacji zabezpieczeń, zalecamy izolowanie dzierżaw według konta bazy danych i przydzielanie jednostek RU do dzierżawy. W przypadku dzierżaw, które mają mniej rygorystyczne wymagania, zalecamy izolowanie dzierżaw według klucza partycji. Ten model umożliwia udostępnianie jednostek RU między dzierżawami i optymalizowanie kosztów dzierżawy.

Alternatywny model dzierżawy dla usługi Azure Cosmos DB obejmuje wdrażanie oddzielnych kontenerów dla każdej dzierżawy w ramach udostępnionej bazy danych. Użyj usługi Azure Cosmos DB, aby aprowizować jednostki RU dla bazy danych, aby wszystkie kontenery współużytkować jednostki RU. Jeśli obciążenia dzierżawy zwykle nie nakładają się na siebie, takie podejście może pomóc zmniejszyć koszty operacyjne. Jednak takie podejście jest podatne na hałaśliwy problem sąsiada, ponieważ kontener pojedynczej dzierżawy może zużywać nieproporcjonalną ilość współużytkowanych jednostek RU aprowizowania. Aby rozwiązać ten problem, najpierw zidentyfikuj hałaśliwe dzierżawy. Następnie możesz opcjonalnie ustawić aprowizowaną przepływność dla określonego kontenera. Inne kontenery w bazie danych nadal współdzielą swoją przepływność, ale dzierżawa hałaśliwy zużywa własną dedykowaną przepływność.

Usługa Azure Cosmos DB udostępnia również warstwę bezserwerową, która odpowiada obciążeniom, które mają sporadycznie lub nieprzewidywalny ruch. Alternatywnie możesz użyć skalowania automatycznego, aby skonfigurować zasady określające skalowanie aprowizowanej przepływności. Możesz również skorzystać z pojemności serii usługi Azure Cosmos DB, aby zmaksymalizować użycie aprowizowanej pojemności przepływności, która w przeciwnym razie jest ograniczona przez limity szybkości. W rozwiązaniu wielodostępnym możesz połączyć wszystkie te podejścia w celu obsługi różnych typów dzierżaw.

Uwaga

Podczas planowania konfiguracji usługi Azure Cosmos DB należy wziąć pod uwagę limity przydziału i limity usług.

Aby monitorować koszty skojarzone z każdą dzierżawą i zarządzać nimi, pamiętaj, że każda operacja korzystająca z interfejsu API usługi Azure Cosmos DB obejmuje zużyte jednostki RU. Te informacje umożliwiają agregowanie i porównywanie rzeczywistych jednostek RU używanych przez każdą dzierżawę. Następnie można zidentyfikować dzierżawy, które mają różne cechy wydajności.

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

Klucze zarządzane przez klienta

Niektóre dzierżawy mogą wymagać użycia własnych kluczy szyfrowania. Usługa Azure Cosmos DB udostępnia funkcję klucza zarządzanego przez klienta. Ta funkcja jest stosowana na poziomie konta usługi Azure Cosmos DB. Jeśli więc dzierżawy wymagają własnych kluczy szyfrowania, musisz użyć dedykowanych kont usługi Azure Cosmos DB do wdrożenia dzierżaw.

Aby uzyskać więcej informacji, zobacz Konfigurowanie kluczy zarządzanych przez klienta dla konta usługi Azure Cosmos DB przy użyciu usługi Azure Key Vault.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

  • Tara Bhatia | Menedżer programu, Azure Cosmos DB
  • Paul Burpo | Główny inżynier klienta, fasttrack dla platformy Azure
  • John Downs | Główny inżynier oprogramowania

Inni współautorzy:

  • Mark Brown | Główny menedżer pm, Azure Cosmos DB
  • Deborah Chen | Główny menedżer programu
  • Theo van Kraay | Starszy menedżer programu, Azure Cosmos DB
  • Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
  • Thomas Weiss | Główny menedżer programu
  • Vic Perdana | Architekt rozwiązań w chmurze, niezależnego dostawcy oprogramowania platformy Azure

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

Następne kroki

Dowiedz się więcej o wielodostępności i usłudze Azure Cosmos DB:

Zapoznaj się z innymi scenariuszami architektury usługi Azure Cosmos DB: