Multi-Tenant-Datenbankdesign: ERD-Ansätze für gemeinsam genutzte Systeme

Die Gestaltung einer Datenbankarchitektur für eine Multi-Tenant-Umgebung erfordert sorgfältige Überlegungen zu Datenisolation, Skalierbarkeit und Wartungsaufwand. Das Entity-Relationship-Diagramm (ERD) dient als Bauplan für diese Entscheidungen und bestimmt, wie die Daten über die verschiedenen Kunden hinweg strukturiert werden. Die Wahl des richtigen Ansatzes beeinflusst Leistung, Sicherheit und die Fähigkeit, das System im Laufe der Zeit weiterzuentwickeln. Dieser Leitfaden untersucht die primären architektonischen Muster, ihre Auswirkungen auf das ERD und die damit verbundenen Kompromisse bei jeder Strategie.

🔍 Verständnis von Multi-Tenancy in der Datenmodellierung

Multi-Tenancy ermöglicht es einer einzelnen Softwareinstanz, mehrere Kunden zu bedienen, die oft als Mandanten bezeichnet werden. Im Kontext der Datenbankgestaltung besteht die zentrale Herausforderung darin, zu entscheiden, wie die Mandantendaten getrennt werden können, ohne die Effizienz zu beeinträchtigen. Das ERD muss diese Trennungsgränzen klar widerspiegeln.

• Mandant: Ein einzelner Kunde oder eine Organisation, die das System nutzt.
• Gemeinsames System: Die Anwendungslogik und möglicherweise die zugrundeliegende Infrastruktur.
• Datenisolation: Sicherstellen, dass ein Mandant nicht auf die Daten eines anderen zugreifen kann.

Die Gestaltungsentscheidungen drehen sich hauptsächlich um die Frage, wo die Isolationsgrenze verläuft. Gibt es sie auf Datenbankebene, auf Schemaebene oder auf Zeilenebene? Jede Wahl erfordert eine spezifische ERD-Struktur.

🏗️ Strategie 1: Datenbank pro Mandant

Bei diesem Modell erhält jeder Mandant eine dedizierte Datenbankinstanz. Dies bietet das höchste Maß an Isolation und Sicherheit. Aus Sicht des ERD bleibt das Schema in allen Datenbanken identisch, die physische Trennung ist jedoch absolut.

📊 ERD-Struktur

Das ERD-Diagramm für eine einzelne Mandantendatenbank sieht identisch aus wie ein herkömmliches Ein-Mandanten-Design. Es besteht kein Bedarf für eineMandanten_IDSpalte, da die Datenbankgrenze selbst als Filter fungiert.

• Tabellenstruktur:Tabellen enthalten nur Daten, die für den jeweiligen Mandanten relevant sind.
• Fremdschlüssel:Die Standard-Referenzintegrität gilt ohne Kenntnis des Mandanten.
• Indizes:Optimiert für das spezifische Datenvolumen dieses Mandanten.

✅ Vorteile

• Vollständige Isolation:Ein Sicherheitsvorfall in einer Datenbank beeinträchtigt die anderen nicht.
• Anpassungsfähigkeit:Schema-Änderungen können auf bestimmte Mandanten angewendet werden, ohne andere zu beeinflussen.
• Leistung:Kein Wettbewerb mit anderen Mandanten im selben Verbindungs-Pool oder bei der Festplatten-I/O.

❌ Nachteile

• Kosten: Hohe Infrastrukturkosten aufgrund mehrerer Instanzen.
• Wartung: Schema-Updates erfordern die Bereitstellung auf jeder Datenbankinstanz.
• Komplexität: Das Verwalten von Verbindungen und der Orchestrierung wird bei Skalierung schwierig.

🏗️ Strategie 2: Schema pro Mandant

Diese Herangehensweise liegt zwischen den beiden vorherigen. Jeder Mandant erhält ein eigenes Schema auf demselben Datenbankserver. Dadurch sinkt der Aufwand für die Verwaltung mehrerer Datenbankverbindungen, während die logische Trennung erhalten bleibt.

📊 ERD-Struktur

Die ERD bleibt mit dem Ein-Mandanten-Modell konsistent, aber der Namensraum ändert sich. Tabellen existieren innerhalb eines bestimmten Schema-Namensraums anstelle des öffentlichen Namensraums.

• Tabellennamen: Standard-Namenskonventionen (z. B. benutzer, bestellungen).
• Schemanamen: Eindeutige Bezeichner (z. B. schema_mandant_a, schema_mandant_b).
• Verbindung: Die Anwendung verbindet sich mit dem spezifischen Schema des aktiven Mandanten.

✅ Vorteile

• Isolation: Stärkere Isolation als bei gemeinsam genutzten Schemamodellen.
• Verwaltung: Einfacher zu verwalten als separate Datenbankinstanzen.
• Sicherung: Kann einzelne Schemas unabhängig wiederherstellen oder sichern.

❌ Nachteile

• Ressourcenverbrauch: Verbraucht immer noch mehr Ressourcen als ein vollständig geteilter Modell.
• Abfragekomplexität:Die Aggregation von Daten über mehrere Mandanten erfordert dynamisches Schema-Switching.
• Schema-Drift:Die Synchronisierung von Schemas über viele Mandanten hinweg ist aufwendig.

🏗️ Strategie 3: Gemeinsame Datenbank, gemeinsames Schema

Dies ist der häufigste Ansatz für SaaS-Anwendungen. Alle Mandanten teilen sich dieselbe Datenbank und dieselben Tabellen. Die Datengetrenntheit wird logisch über eine eindeutige Kennzeichnungs-Spalte erreicht.

📊 ERD-Struktur

Das ERD muss explizit eine tenant_idSpalte in jeder Tabelle enthalten, die mandantenbezogene Daten speichert. Diese Spalte fungiert als Partitionsschlüssel.

• Kerntabellen: Benutzer, Bestellungen, Produkte enthalten alle eine tenant_id.
• Gemeinsame Tabellen: Tabellen wie Rollen oder Berechtigungenkönnen über alle Mandanten hinweg geteilt werden.
• Einschränkungen: Fremdschlüssel müssen möglicherweise eingeschränkt werden, um sicherzustellen, dass die Referenzintegrität im Kontext des Mandanten erhalten bleibt.

✅ Vorteile

• Kosteneffizienz:Niedrigste Infrastrukturkosten.
• Wartung:Schemaänderungen wirken sich sofort auf alle Mandanten aus.
• Analytik:Einfacher, Daten für systemweite Berichterstattung zu aggregieren.

❌ Nachteile

• Komplexe Abfragen: Jede Abfrage erfordert eine Filterung nach tenant_id.
• Leistung: Hohe Konkurrenzrisiken, wenn ein Mandant übermäßige Ressourcen verbraucht.
• Sicherheit: Höheres Risiko von Logikfehlern, die zu Datenlecks führen können.

🏗️ Strategie 4: Hybrid-Modell

Ein hybrider Ansatz kombiniert Elemente der oben genannten Strategien. Zum Beispiel ein gemeinsames Schema für Standarddaten, aber ein eigenständiges Schema für Premium-Tarife oder spezifische hochwertige Mandanten.

📊 ERD-Struktur

Das ERD wird komplexer und unterscheidet zwischen gemeinsam genutzten Tabellen und mandantenbezogenen Tabellen.

• Globale Tabellen: Speichern von Konfigurationen oder gemeinsam genutzten Metadaten.
• Mandantentabellen: Speichern von Benutzerdaten mit einer tenant_id oder in separaten Schemas.
• Verknüpfung: Join-Operationen müssen den Bereich der Daten berücksichtigen.

🛡️ Datenisolation und Sicherheitsüberlegungen

Unabhängig von der gewählten Strategie ist die Datenisolation von entscheidender Bedeutung. Das ERD muss Mechanismen unterstützen, die ein versehentliches Datenzugreifen verhindern.

🔒 Sicherheit auf Zeilenebene

Bei einem gemeinsamen Schema-Modell können Sicherheitsrichtlinien auf Zeilenebene (RLS) definiert werden. Die Datenbankengine beschränkt den Zugriff auf Zeilen, bei denen die tenant_id mit dem authentifizierten Kontext übereinstimmt.

• Implementierung: Richtlinien erzwingen Prüfungen bei jeder SELECT, UPDATE, und DELETE Operation.
• Vorteil: Verhindert, dass Fehler auf Anwendungsebene zu Datenlecks führen.
• Auswirkung auf das ERD: Erfordert explizite tenant_id Spalten in allen relevanten Tabellen.

🔒 Fremdschlüsselbeschränkungen

Die Sicherstellung der Referenzintegrität über mehrere Mandanten hinweg kann bei gemeinsamen Modellen schwierig sein. Ein Fremdschlüssel sollte idealerweise nicht auf eine Tabelle verweisen, die mehrere Mandanten umfasst, es sei denn, die Beziehung ist ausdrücklich global.

• Selbstreferenzierung: Wenn eine Tabelle sich selbst referenziert (z. B. parent_id), muss die tenant_id auf beiden Seiten übereinstimmen.
• Globale Referenzen: Tabellen wie Kategorien könnte global sein, was es ermöglicht, sie von jedem Mieter aus zu referenzieren.

⚡ Leistungs- und Skalierungsstrategien

Je mehr Mieter hinzukommen, desto kritischer wird die Leistung. Das ERD-Design beeinflusst direkt, wie gut das System skaliert.

📈 Indizierungsstrategien

Indizes sind entscheidend für die Abfrageleistung. In einer gemeinsamen Schema, sollte diemieter_idSpalte Teil des primären zusammengesetzten Schlüssels sein oder stark indiziert werden.

• Zusammengesetzte Indizes: (mieter_id, erstellt_am)ermöglicht eine effiziente Filterung nach Mieter und Zeit.
• Teilindizes:Indizes können nur für bestimmte Bedingungen erstellt werden, wodurch die Indexgröße reduziert wird.
• Vermeiden:Indizieren von Spalten, die bei der Mieterfilterung nicht helfen.

📦 Partitionierung

Die Tabellenpartitionierung kann helfen, große Datensätze zu verwalten. Die Daten können nachmieter_idoder nach Zeitbereichen innerhalb eines Mieters partitioniert werden.

• Bereichspartitionierung:Teilt die Daten basierend auf Datumsbereichen.
• Liste Partitionierung:Teilt die Daten basierend auf bestimmten Mieter-IDs.
• Verwaltung:Partitionen können abgetrennt oder archiviert werden, um die Leistung zu verbessern.

🔧 Wartung und Schema-Evolution

Software entwickelt sich weiter. Tabellen müssen hinzugefügt, Spalten geändert oder Typen geändert werden. Die gewählte Architektur bestimmt den Aufwand für diese Änderungen.

🔄 Schema-Updates

• Gemeinsames Schema:Ein einzelner Migrations-Skript aktualisiert das Schema für alle Mieter. Dies ist der einfachste Weg.
• Datenbank pro Mandant: Das Migrations-Skript muss für jede Datenbankinstanz ausgeführt werden. Automatisierung ist erforderlich.
• Schemas pro Mandant: Ähnlich wie Datenbank pro Mandant, jedoch innerhalb derselben Instanz verwaltet.

📝 Rückwärtskompatibilität

Stellen Sie bei der Änderung des ERD sicher, dass die Rückwärtskompatibilität gewährleistet ist, um Ausfallzeiten zu vermeiden.

• Spalten hinzufügen: Verwenden Sie zunächst nullable Spalten, füllen Sie anschließend die Daten auf und machen Sie sie dann nicht-null.
• Spalten löschen: Benennen Sie Spalten vor deren Löschung um, um Änderungen zu vermeiden, die die Funktionalität beeinträchtigen.
• Versionsverwaltung: Berücksichtigen Sie die Versionsverwaltung des Schemas selbst, wenn Mandanten Updates ablehnen können.

📋 Vergleich architektonischer Ansätze

Funktion	Datenbank pro Mandant	Schema pro Mandant	Geteiltes Schema
Isolation	Hoch	Mittel	Niedrig
Kosten	Hoch	Mittel	Niedrig
Wartung	Komplex	Mittel	Einfach
Abfrageleistung	Hoch (Keine Filterung)	Mittel	Variabel (Filterung erforderlich)
ERD-Komplexität	Einfach (Pro Datenbank)	Einfach (Pro Schema)	Komplex (tenant_id erforderlich)
Skalierbarkeit	Horizontal	Vertikal	Vertikal/Horizontal

✅ Best Practices-Checkliste

Stellen Sie vor der endgültigen Festlegung des ERD für ein Multi-Tenant-System sicher, dass die folgenden Kriterien erfüllt sind.

• Definieren Sie den Tenant-Umfang: Identifizieren Sie klar, welche Daten zu einem Tenant gehören und welche global sind.
• Standardisieren Sie die Benennung: Verwenden Sie konsistente Benennungskonventionen für tenant_id Spalten in allen Tabellen.
• Setzen Sie Einschränkungen durch: Verwenden Sie Datenbankbeschränkungen, um den Zugriff auf Daten von anderen Tenants so weit wie möglich zu verhindern.
• Planen Sie für Churn: Gestalten Sie die Onboarding- und Offboarding-Prozesse für Tenants (Löschung oder Archivierung von Daten).
• Testen Sie die Isolation: Testen Sie regelmäßig, um sicherzustellen, dass ein Tenant die Daten eines anderen Tenants nicht abfragen kann.
• Dokumentieren Sie Beziehungen: Dokumentieren Sie die Fremdschlüsselbeziehungen im ERD-Dokument klar und eindeutig.
• Überwachen Sie die Leistung: Richten Sie Warnungen für langsame Abfragen ein, die auf tenant-spezifische Engpässe hindeuten könnten.

🧩 Umgang mit Randfälle

Realitätsnahe Szenarien führen oft zu Komplexitäten, die standardmäßige ERDs nicht sofort abdecken.

🔄 Tenant-Zusammenschluss

Manchmal verschmelzen zwei Mandanten zu einem. Bei einer gemeinsamen Schema-Struktur erfordert dies das Verschieben von Zeilen von einem tenant_id in einen anderen. Bei einem Datenbank- pro-Mandanten-Modell erfordert dies das Zusammenführen zweier gesamter Datenbanken.

• Datenkonsistenz: Stellen Sie sicher, dass während des Zusammenführens keine Daten verloren gehen.
• Duplikatvermeidung: Behandeln Sie doppelte Datensätze, die durch den Zusammenführungsprozess entstehen können.

📉 Mandantenfluktuation

Mandanten verlassen das System. Die Entscheidung, Daten zu löschen oder zu archivieren, beeinflusst das ERD.

• Weiche Löschungen: Fügen Sie eine is_deletedFlagge hinzu, um Daten für die Compliance zu bewahren.
• Harte Löschungen: Löschen Sie Zeilen vollständig. Stellen Sie sicher, dass kaskadierende Löschungen korrekt konfiguriert sind, um verwaiste Datensätze zu vermeiden.
• Archivierung: Verschieben Sie alte Mandantendaten in Tabellen für kalte Speicherung, während das Schema unverändert bleibt.

🔗 Integration mit der Anwendungslogik

Das ERD ist kein Eiland. Es muss nahtlos mit der Anwendungsschicht integriert werden.

• Middleware: Verwenden Sie Anwendungsebenen-Middleware, um tenant_id automatisch in jede Abfrage einzufügen.
• ORM-Konfiguration: Konfigurieren Sie Objekt-Relational-Mapping-Tools, um die Mandantensicht zu verwalten.
• API-Design: Stellen Sie sicher, dass API-Endpunkte den Mandantenkontext überprüfen, bevor sie Daten zurückgeben.

🎯 Abschließende Gedanken zum Design

Die Auswahl des geeigneten Datenbankdesigns für eine Multi-Tenant-Umgebung ist ein Ausgleich zwischen Isolation und Effizienz. Das ERD fungiert als Vertrag, der diese Grenzen definiert. Es gibt keine einzigartige perfekte Lösung; die Wahl hängt von den spezifischen Anforderungen an Sicherheit, Kosten und Skalierbarkeit ab. Durch das Verständnis der Auswirkungen jeder Strategie können Architekten Systeme entwickeln, die robust, skalierbar und sicher sind.

Die Fokussierung auf klare Datenmodellierungspraktiken stellt sicher, dass das System auch bei wachsender Anzahl an Mandanten wartbar bleibt. Regelmäßige Überprüfungen des ERD anhand realer Nutzungsmuster helfen, Engpässe oder Sicherheitslücken zu erkennen, bevor sie zu kritischen Problemen werden.

Letztendlich ist das Ziel ein Design, das das Geschäft unterstützt, ohne die Integrität der Daten zu gefährden. Sorgfältige Planung im ERD-Stadium verhindert kostspielige Umgestaltungen später.