Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Koncepcja wielodzierżawności w usłudze Azure Data Explorer odnosi się do obsługi różnych dzierżawców i przechowywania ich danych w jednym klastrze.
Ważna
Rozwiązanie wielodostępne można również zaprojektować w środowisku Microsoft Fabric Real-Time Intelligence, korzystając z baz danych KQL wewnątrz Eventhouse.
Podmiot może reprezentować klienta, grupę użytkowników lub wszelkie klasyfikacje użytkowników, w ramach których dane muszą być segregowane wzdłuż granic podmiotu. Można również mieć scenariusz wielopoziomowej wielodostępności, taki jak wiele aplikacji, z których każda ma wielu najemców. Ten artykuł nie obejmuje tego scenariusza, ale mają zastosowanie podobne zasady.
Ważnym czynnikiem jest sposób, w jaki użytkownicy końcowi uzyskują dostęp do danych dzierżawy. Gdy użytkownicy końcowi uzyskują bezpośredni dostęp do usługi Azure Data Explorer, należy skonfigurować kontrolę dostępu w usłudze Azure Data Explorer, aby odizolować widok użytkownika do własnych danych. Gdy aplikacja proxy uzyskuje dostęp do swoich danych w usłudze Azure Data Explorer, aplikacja może wykonać izolację.
W tym artykule opisano niektóre architektury wdrażania i przedstawiono cechy każdej z nich. Możesz użyć cech, aby pomóc w podjęciu decyzji, która architektura najlepiej sprawdza się w twoim rozwiązaniu.
Hałaśliwy sąsiad
Ogólnie rzecz biorąc, udostępnianie klastra między wieloma użytkownikami, niezależnie od stosowanej architektury, oznacza, że różni użytkownicy wspólnie korzystają z zasobów klastra. Może to prowadzić do antywzorca hałaśliwego sąsiada.
Jeśli na przykład najemca wykonuje wiele zapytań intensywnie korzystających z obliczeń lub operacji związanych z przetwarzaniem danych, inni najemcy mogą być narażeni na wyczerpanie zasobów. Można temu zapobiec za pomocą grup obciążeń. Możesz również użyć polityk do kontrolowania buforowania i ogólnego przechowywania.
Omówienie architektur
W następnych sekcjach szczegółowo omówiono architektury wdrażania. Ta sekcja porównuje architektury, aby ułatwić podejmowanie decyzji.
| Architecture | Strengths |
|---|---|
| Jeden najemca na bazę danych | - Izolacja najemców: brak potrzeby serwera pośredniczącego — Może mieć różne zasady, np. zasady dotyczące przechowywania, dla każdego klienta — Elastyczność ewolucji schematu danych dla każdego najemcy - Łatwe i szybkie usuwanie danych dzierżawy |
| Jedna tabela dla wielu najemców | - Efektywna konsolidacja danych i zarządzanie zakresem - Uproszczona ewolucja schematu - Najlepiej nadaje się do zmaterializowanych widoków - Idealne do partycjonowania |
| Jeden najemca na tabelę w pojedynczej bazie danych | Niezalecane |
Architektura: jeden użytkownik na bazę danych
Jest to popularna i prosta architektura. Każdy najemca otrzymuje własną bazę danych. Każda baza danych ma ten sam schemat.
Cechy tej architektury to:
Aprowizowanie nowego lokatora: wymaga utworzenia nowej bazy danych i wdrożenia na niej obiektów schematu.
Usuwanie dzierżawy: wymaga usunięcia bazy danych. Usunięcie bazy danych można wykonać w ciągu kilku sekund. Zużywa niewiele zasobów, a ich zużycie pozostaje stałe niezależnie od ilości danych u lokatora.
Aktualizacje schematów bazy danych: każdy tenant może być aktualizowany niezależnie w różnych momentach. Aplikacje, które uzyskują dostęp do baz danych, muszą mieć świadomość wersji każdej bazy danych, z którą wchodzą w interakcję.
Zasady przechowywania i buforowania: Każda dzierżawa może posiadać własne, unikatowe zasady, co umożliwia oferowanie klientom niestandardowych polityk przechowywania i buforowania.
Granica zabezpieczeń dla każdego najemcy:
- W przypadku aplikacji wielodostępnych (proxy): Skonfiguruj aplikację tak, aby ukierunkować ją na odpowiednią bazę danych. Ogranicz dostęp do zapytań, aby uniemożliwić wykonywanie zapytań między bazami danych.
- W przypadku użytkowników z bezpośrednim dostępem: użytkownicy mogą mieć dostęp na poziomie bazy danych. Zapewnienie użytkownikom bezpośredniego dostępu do bazy danych powoduje utworzenie zależności dla szczegółów implementacji, co utrudnia zmianę implementacji. W związku z tym zdecydowanie zalecamy użycie podejścia serwera proxy do uzyskiwania dostępu do bazy danych.
Agregowanie danych z wielu dzierżaw na dużą skalę: użyj operatora union do agregowania danych między bazami danych. Jednak ta metoda może stać się kłopotliwa w miarę wzrostu liczby dzierżaw. Mimo że agregowanie danych z wielu dzierżaw może być celem projektu z perspektywy dzierżawy, może być interesujące dla właściciela rozwiązania agregowanie danych ze wszystkich dzierżaw w celu zebrania statystyk.
Fragmentacja extentów: Każdy klient wprowadzający kilka rekordów na jedną tabelę bazy danych prowadzi do utworzenia małych extentów, które później należy scalić. Skutkuje to wyższym kosztem zarządzania zakresem. W związku z tym zdecydowanie zalecamy użycie przesyłania strumieniowego przyjmowania danych, takiego jak przyjmowanie danych przez Event Hubs lub Event Grid. Aby użyć ingestii strumieniowej, upewnij się, że jest włączona w klastrze i tabeli.
Zmaterializowane widoki i polityka partycjonowania. W miarę wzrostu liczby dzierżawców należy pamiętać, że istnieją limity liczby zmaterializowanych widoków i zasad partycji, które klaster może funkcjonować wydajnie.
Połączenia danych usługi Event Grid i Event Hubs: te połączenia danych są tworzone dla każdej bazy danych. W związku z tym ta architektura wymaga połączenia danych oraz instancji usługi Event Grid lub Event Hubs dla każdego dzierżawcy, co zwiększa kompleksowość zarządzania. Rozważ użycie routingu zdarzeń dla usług Event Hubs i Event Grid.
Architektura: jedna tabela dla wielu najemców
Ta architektura jest bardziej agresywna w konsolidacji poprzez użycie jednej wspólnej bazy danych dla wszystkich najemców. Każda tabela w bazie danych ma kolumnę Identyfikator najemcy lub równoważną, która umożliwia filtrowanie danych pojedynczego najemcy. Można partycjonować tabele według dzierżawców, aby zwiększyć wydajność zapytań, ponieważ większość zapytań najczęściej filtruje według dzierżawcy. Jeśli to możliwe, należy rozważyć podzielenie partycji z inną kolumną przy użyciu klucza partycji złożonej. Można na przykład utworzyć złożony klucz partycji, łącząc identyfikator dzierżawy i wartości z innych kolumn.
Cechy tej architektury to:
Aprowizowanie nowej dzierżawy: aprowizowanie nowej dzierżawy nie wymaga żadnego utworzenia bazy danych ani dostosowania schematu. Nowy identyfikator dla dzierżawcy jest używany w nowych rekordach.
Usuwanie dzierżawy: wymaga miękkiego usunięcia lub trwałego usunięcia danych dzierżawy. Można na przykład grupować razem wiele czyszczeń na koniec tygodnia, aby ograniczyć wpływ na zużycie zasobów.
Aktualizacje schematów bazy danych: Schematy wszystkich dzierżawców są aktualizowane w tym samym czasie. Ponieważ wszyscy najemcy współdzielą tabelę, zmiana schematów tabel zmienia jednocześnie wszystkich najemców.
Zasady przechowywania i buforowania: zasady są takie same dla wszystkich dzierżaw, ponieważ wszystkie współużytkują tę samą tabelę.
Granica zabezpieczeń dla każdego najemcy:
- W przypadku aplikacji wielodostępnych (proxy): użyj instrukcji Restrict
- W przypadku użytkowników z bezpośrednim dostępem: użyj zasad zabezpieczeń na poziomie wiersza i zapoznaj się z jej ograniczeniami. Zapewnienie użytkownikom bezpośredniego dostępu do bazy danych powoduje utworzenie zależności dla szczegółów implementacji, co utrudnia zmianę implementacji. W związku z tym zdecydowanie zalecamy użycie podejścia serwera proxy do uzyskiwania dostępu do bazy danych.
Agregowanie danych z wielu dzierżaw na dużą skalę: użytkownicy z wystarczającymi uprawnieniami dostępu mogą uruchamiać standardowe zapytanie agregacji na danych wielu dzierżaw.
Fragmentacja zakresów: ponieważ wszystkie dzierżawy pozyskiwają dane do tej samej tabeli, dane mogą być zwykle konsolidowane i efektywnie pozyskiwane w jednym lub kilku zakresach.
Zmaterializowane widoki i zasady partycjonowania: można ich używać w tabeli multitenant. Wydajność można poprawić, partycjonując według kolumny identyfikatora najemcy lub równoważnej. Aby uzyskać więcej informacji, zobacz Scenariusze dotyczące zasad partycji.
Połączenia danych usługi Event Grid i Event Hubs: Skonsolidowałeś połączenia danych, ponieważ dane dla wszystkich dzierżaw trafiają do jednej tabeli.
Architektura: jeden dzierżawca na tabelę w pojedynczej bazie danych
Ta architektura jest kombinacją poprzednich architektur, gdzie dane wszystkich użytkowników trafiają do jednej bazy danych, ale do oddzielnych tabel. Ta architektura nie może przechwycić wszystkich zalet innych architektur.
Chociaż dane każdego dzierżawcy są oddzielone, wszystkie znajdują się w tym samym kontekście bezpieczeństwa tej samej bazy danych. Podobnie jak architektura z wieloma bazami danych, ta architektura może prowadzić do fragmentacji zakresu. Nazwa tabeli jest inna dla każdego najemcy, dlatego zapytania muszą być dostosowane do każdego najemcy.