Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Das Konzept des Mandanten mit mehreren Mandanten in Azure Data Explorer bezieht sich auf die Bereitstellung verschiedener Mandanten und das Speichern ihrer Daten in einem einzigen Cluster.
Von Bedeutung
Eine mehrinstanzenfähige Lösung kann auch in der Real-Time Intelligence-Aufgabe von Microsoft Fabric mit KQL-Datenbanken innerhalb eines Eventhouse erstellt werden.
Ein Mandant kann einen Kunden, eine Benutzergruppe oder beliebige Klassifizierungen von Benutzern darstellen, bei denen Daten entlang der Mandantengrenzen getrennt werden müssen. Sie können auch ein Szenario mit mehreren Ebenen haben, z. B. mehrere Anwendungen, die jeweils über mehrere Mandanten verfügen. In diesem Artikel wird dieses Szenario nicht behandelt, aber es gelten ähnliche Prinzipien.
Ein wichtiger Faktor ist die Art und Weise, wie Endbenutzer auf ihre Mandantendaten zugreifen. Wenn Nutzer direkt auf Azure Data Explorer zugreifen, muss die Zugriffssteuerung in Azure Data Explorer konfiguriert werden, um die Ansicht des Nutzers auf seine eigenen Daten zu beschränken. Wenn eine Proxyanwendung im Azure-Daten-Explorer auf ihre Daten zugreift, kann die Anwendung die Isolation ausführen.
In diesem Artikel werden einige Bereitstellungsarchitekturen beschrieben und Merkmale für jede Architektur angegeben. Mithilfe der Merkmale können Sie entscheiden, welche Architektur für Ihre Lösung am besten geeignet ist.
Lauter Nachbar
Im Allgemeinen bedeutet die Gemeinsame Nutzung eines Clusters zwischen vielen Mandanten unabhängig von der verwendeten Architektur, dass unterschiedliche Mandanten die Ressourcen des Clusters gemeinsam nutzen. Dies kann zu dem 'noisy neighbor' Antipattern führen.
Wenn ein Mandant beispielsweise viele rechenintensive Abfragen oder Erfassungen ausführt, werden andere Mandanten wahrscheinlich durch Ressourcenhunger beeinträchtigt. Dies kann mithilfe von Workloadgruppen abgemildert werden. Sie können auch Richtlinien verwenden, um das Zwischenspeichern und den gesamten Speicher zu steuern.
Architekturübersicht
In den nächsten Abschnitten werden die Bereitstellungsarchitekturen ausführlich erläutert. In diesem Abschnitt werden die Architekturen gegenübergesetzt, um die Entscheidungsfindung zu erleichtern.
| Architecture | Strengths |
|---|---|
| Ein Mandant pro Datenbank | - Mandantenisolation: Kein Proxy nötig – Kann unterschiedliche Richtlinien haben, z. B. Aufbewahrungsrichtlinien, pro Mandant - Flexibilität bei der Schemaentwicklung pro Mandant - Einfache und schnelle Entfernung von Mandantendaten |
| Eine Tabelle für viele Nutzer | - Effiziente Datenkonsolidierung und -umfangsverwaltung - Vereinfachte Schemaentwicklung - Am besten geeignet für materialisierte Ansichten - Ideal für die Partitionierung |
| Ein Mandant pro Tabelle in einer einzelnen Datenbank | Nicht empfohlen |
Architektur: Ein Mandant pro Datenbank
Dies ist eine beliebte und gerade Architektur. Jeder Mandant erhält eine eigene Datenbank. Jede Datenbank weist dasselbe Schema auf.
Die Merkmale dieser Architektur sind:
Bereitstellen eines neuen Mandanten: Erfordert das Erstellen einer neuen Datenbank und das Bereitstellen von Schemaentitäten .
Entfernen eines Mandanten: Erfordert das Löschen der Datenbank. Das Löschen einer Datenbank kann in ein paar Sekunden erfolgen. Verbraucht kleine und konstante Ressourcen, die nicht linear mit dem Datenvolume des Mandanten sind.
Aktualisierungen von Datenbankschemas: Jeder Mandant kann zu unterschiedlichen Zeiten unabhängig aktualisiert werden. Anwendungen, die auf die Datenbanken zugreifen, müssen die Version jeder Datenbank kennen, mit der sie interagieren.
Aufbewahrungs- und Zwischenspeicherungsrichtlinien: Jeder Mandant kann über eigene eindeutige Richtlinien verfügen, mit denen Sie ihren Kunden benutzerdefinierte Aufbewahrungs- und Zwischenspeicherungsrichtlinien bereitstellen können.
Sicherheitsgrenze pro Mandant:
- Für mehrinstanzenfähige Anwendung (Proxy): Konfigurieren Sie Ihre Anwendung so, dass sie auf die relevante Datenbank ausgerichtet ist. Verwenden Sie Zugriffsbeschränkungen für Abfragen, um datenbankübergreifende Abfragen zu verbieten.
- Für Benutzer mit direktem Zugriff: Benutzern kann der Zugriff auf Datenbankebene gewährt werden. Wenn Benutzer direkten Zugriff auf ihre Datenbank erhalten, wird eine Abhängigkeit für die Implementierungsdetails erstellt, wodurch es schwierig ist, die Implementierung zu ändern. Daher wird dringend empfohlen, den Proxyansatz für den Zugriff auf die Datenbank zu verwenden.
Aggregieren von Daten aus mehreren Mandanten im großen Maßstab: Verwenden Sie den Vereinigungsoperator, um Daten aus mehreren Datenbanken zusammenzuführen. Diese Methode kann jedoch umständlich werden, da die Anzahl der Mandanten steigt. Obwohl das Aggregieren von Daten aus mehreren Mandanten ein Entwurfsziel aus Sicht des Mandanten sein könnte, ist es möglicherweise von Interesse, dass der Lösungsbesitzer Daten aus allen Mandanten aggregiert, um Statistiken zu sammeln.
Fragmentierung von Datenblöcken: Jeder Mandant, der ein paar Datensätze pro Datenbanktabelle speichert, führt zur Erstellung kleiner Datenblöcke, die später zusammengeführt werden müssen. Dies führt zu höheren Kosten für die Extent-Verwaltung. Daher empfehlen wir dringend die Verwendung von Streaming-Ingestion, wie Event Hubs oder Event Grid-Ingestion. Um Streaming-Ingestion zu nutzen, müssen Sie sicherstellen, dass diese auf dem Cluster und der Tabelle aktiviert ist.
Materialisierte Ansichten und Partitionierungsrichtlinien. Da sich die Anzahl der Mandanten erhöht, ist es wichtig zu beachten, dass es Grenzwerte für die Anzahl der materialisierten Ansichten und Partitionsrichtlinien gibt, die ein Cluster effizient verwalten kann.
Ereignisraster- und Event Hubs-Datenverbindungen: Diese Datenverbindungen werden pro Datenbank erstellt. Daher erfordert diese Architektur eine Datenverbindung und eine Event Grid- oder Event Hubs-Instanz pro Mandant, wodurch die Verwaltungskomplexität erhöht wird. Erwägen Sie die Verwendung des Ereignisroutings für Event Hubs und Event Grid.
Architektur: Eine Tabelle für viele Mieter
Diese Architektur ist aggressiver in der Konsolidierung, wobei eine einzelne Datenbank für alle Mandanten verwendet wird. Jede Tabelle in der Datenbank verfügt über eine Spalte "Mandanten-ID " oder eine entsprechende Spalte, die das Filtern nach daten eines einzelnen Mandanten ermöglicht. Sie können Tabellen nach Mandant partitionieren , um die Abfrageleistung zu verbessern, da die meisten Abfragen wahrscheinlich nach Mandant filtern. Wenn möglich, sollten Sie eine Partition mit einer anderen Spalte unter Verwendung eines zusammengesetzten Partitionsschlüssels in Betracht ziehen. Sie können z. B. einen zusammengesetzten Partitionsschlüssel erstellen, der die Mandanten-ID und die Werte einer anderen Spalte verkettet.
Die Merkmale dieser Architektur sind:
Bereitstellen eines neuen Mandanten: Die Bereitstellung eines neuen Mandanten erfordert keine Datenbankerstellung oder Schemaanpassung. Die neue Mandanten-ID wird in neuen Datensätzen verwendet.
Entfernen eines Mandanten: Erfordert ein vorläufiges Löschen oder Löschen der Mandantendaten. Sie können mehrere Bereinigungen zusammenfassen, zum Beispiel am Ende der Woche, um die Auswirkungen auf den Ressourcenverbrauch zu begrenzen.
Aktualisierungen von Datenbankschemas: Das Schema aller Mandanten wird gleichzeitig aktualisiert. Da alle Mandanten Tabellenschemas gemeinsam nutzen, ändert das Ändern von Tabellenschemas alle Mandanten gleichzeitig.
Aufbewahrungs- und Zwischenspeicherungsrichtlinien: Die Richtlinien sind für alle Mandanten identisch, da sie alle die gleiche Tabelle verwenden.
Sicherheitsgrenze pro Mandant:
- Für mehrinstanzenfähige Anwendung (Proxy): Verwenden Sie die Restrict-Anweisung.
- Für Benutzer mit direktem Zugriff: Verwenden Sie die Sicherheitsrichtlinie auf Zeilenebene, und machen Sie sich mit ihren Einschränkungen vertraut. Wenn Benutzer direkten Zugriff auf ihre Datenbank erhalten, wird eine Abhängigkeit für die Implementierungsdetails erstellt, wodurch es schwierig ist, die Implementierung zu ändern. Daher wird dringend empfohlen, den Proxyansatz für den Zugriff auf die Datenbank zu verwenden.
Aggregieren von Daten aus mehreren Mandanten im großen Maßstab: Benutzer mit ausreichenden Zugriffsberechtigungen können eine Standardaggregationsabfrage für die Daten mehrerer Mandanten ausführen.
Extents-Fragmentierung: Da alle Mandanten Daten in derselben Tabelle aufnehmen, können Daten in der Regel konsolidiert und effizient in einem oder wenigen Bereichen erfasst werden.
Materialisierte Ansichten und Partitionierungsrichtlinie: Diese können für eine mehrinstanzenfähige Tabelle verwendet werden. Sie können die Leistung verbessern, indem Sie nach der Mandanten-ID oder einer gleichwertigen Spalte partitionieren. Weitere Informationen finden Sie unter Szenarien für Partitionsrichtlinien.
Event Grid und Event Hubs-Datenverbindungen: Sie konsolidieren Datenverbindungen, da Daten für alle Mandanten in einer Tabelle gesammelt werden.
Architektur: Ein Mandant pro Tabelle in einer einzelnen Datenbank
Diese Architektur ist eine Kombination aus den vorherigen Architekturen, bei denen die Daten aller Mandanten in einer einzigen Datenbank gespeichert werden, jedoch in separaten Tabellen. Diese Architektur erfasst nicht alle Vorteile der anderen Architekturen.
Obwohl die Daten jedes Mandanten getrennt sind, befinden sie sich alle im gleichen Sicherheitskontext derselben Datenbank. Wie bei der Multidatenbankarchitektur kann diese Architektur zu einer Fragmentierung führen. Der Tabellenname ist für jeden Mandanten unterschiedlich, daher müssen die Abfragen für jeden Mandanten angepasst werden.