Glossar
Multi-Tenancy
Auch: Mandantenfähigkeit
Ein System bedient mehrere Kunden auf derselben Infrastruktur, ohne dass die Daten des einen beim anderen auftauchen.
Die Entscheidung fällt zwischen geteilter Datenbank mit Kennzeichnung je Mandant, getrennten Schemata und getrennten Datenbanken. Sie bestimmt Betriebsaufwand, Kosten und wie schwer eine Migration einzelner Kunden später wird.
Mandantenfähigkeit betrifft nicht nur die Datenhaltung: Auch Hintergrundverarbeitung, Zwischenspeicher, Protokolle und Kennzahlen müssen den Mandanten kennen, sonst mischt es sich an unerwarteter Stelle.
Die geteilte Tabelle mit Mandantenspalte ist die günstigste Variante im Betrieb und die anspruchsvollste im Code, weil jede einzelne Abfrage die Spalte enthalten muss. Eine vergessene Bedingung liefert fremde Daten aus, und weder Übersetzer noch Test bemerken das, solange nur ein Mandant in der Testdatenbank liegt. Die Absicherung gehört deshalb unter den Anwendungscode: Zeilenbasierte Rechte in der Datenbank oder ein Zugriffslayer, an dem vorbei keine Abfrage möglich ist. Auf Disziplin zu setzen ist keine Absicherung, sondern eine Hoffnung.
Getrennte Schemata liegen in der Mitte: dieselbe Datenbankinstanz, aber je Mandant ein eigener Namensraum. Der Vorteil ist, dass eine falsche Abfrage nicht mehr quer über Kunden greifen kann. Der Preis sind Schemaänderungen, die auf hunderte Namensräume angewendet werden müssen, und Verbindungsverwaltung, die den Mandanten kennt.
Getrennte Datenbanken oder ganze Umgebungen sind die teuerste Variante und manchmal die einzig verkaufbare, etwa bei vertraglichen Anforderungen an Datenhaltung oder wenn ein einzelner Kunde die Last aller anderen übersteigt. Sie bringen ein zweites Problem mit: Ohne durchgehende Automatisierung wird aus jedem Neukunden ein manueller Einrichtungsvorgang, und nach dreißig Kunden ist das eine Vollzeitstelle.
Unabhängig von der Variante braucht ein Mehrmandantensystem eine Antwort auf den lauten Nachbarn. Ein Kunde, der einen Massenimport startet, darf nicht die Antwortzeiten aller anderen verschlechtern. Wirksam sind Kontingente je Mandant, getrennte Warteschlangen für Hintergrundarbeit und eine Obergrenze für teure Abfragen. Ohne diese Grenzen ist die erste Beschwerde nur eine Frage der Kundengröße.
Der letzte Punkt, der beim Entwurf regelmäßig fehlt: Ein Kunde wird irgendwann gehen oder in eine eigene Umgebung wollen. Wenn niemand sagen kann, wie man alle Daten eines Mandanten vollständig exportiert und danach löscht, wird aus dieser Anfrage ein mehrwöchiges Projekt, und die Löschpflicht ist zusätzlich eine rechtliche.
Woran Sie es erkennen
- Mehrere Kunden nutzen dieselbe Anwendung.
- Ein Kunde fragt, ob seine Daten getrennt liegen.
- Ein einzelner Kunde soll später in eine eigene Umgebung umziehen.
- Die Testdatenbank enthält nur einen Mandanten.
- Ein großer Kunde verschlechtert die Antwortzeiten der anderen.
Nicht zu verwechseln mit
- Single-Tenancy
- Je Kunde eine eigene Installation. Einfachste Trennung, höchster Betriebsaufwand, und jede Auslieferung wird ein Rollout über alle Umgebungen.
- Mandantenspalte
- Eine konkrete Umsetzungsform, nicht das Konzept. Sie trennt Daten nur so gut, wie die Abfragen sie berücksichtigen.
- Sharding
- Verteilung von Daten auf mehrere Knoten aus Lastgründen. Kann sich am Mandanten orientieren, verfolgt aber ein anderes Ziel als Trennung.
Wann es trägt
- Ein Produkt wird an viele Kunden verkauft, die sich funktional kaum unterscheiden.
- Betriebsaufwand und Kosten je Kunde sollen niedrig bleiben.
- Auslieferungen sollen alle Kunden gleichzeitig erreichen.
Wann nicht
- Wenn Verträge oder Regulierung getrennte Datenhaltung verlangen.
- Wenn einzelne Kunden eigene Erweiterungen im Datenmodell brauchen.
- Wenn ein einzelner Kunde die Last aller anderen zusammen übersteigt.
Wie man rangeht
- Trennungsgrad je Anforderung wählenGeteilte Tabelle, getrenntes Schema oder getrennte Datenbank. Der Vertrag entscheidet mit, nicht nur die Technik.
- Mandantenbezug erzwingen, nicht empfehlenZeilenbasierte Rechte in der Datenbank oder ein Zugriffslayer, an dem vorbei nichts geht. Disziplin ist keine Absicherung.
- Mandanten durch alle Schichten reichenZwischenspeicher, Warteschlangen, Hintergrundprozesse, Protokolle, Kennzahlen, Dateiablage. Jede Schicht, die ihn vergisst, ist die nächste Fundstelle.
- Mit mehreren Mandanten testenTestdaten mit mindestens zwei Kunden und ein Test, der prüft, dass Abfragen keine fremden Zeilen liefern. Ein Mandant in der Testdatenbank findet den Fehler nie.
- Grenzen gegen den lauten Nachbarn setzenKontingente je Mandant, getrennte Warteschlangen, Obergrenzen für teure Abfragen. Sonst bestimmt der größte Kunde die Antwortzeit aller.
- Export und Löschung von Anfang an bauenAlle Daten eines Mandanten herausgeben und danach vollständig löschen. Das kommt sicher, geschäftlich und rechtlich.
Häufig gefragt
Getrennte Datenbank oder geteilte Tabelle je Mandant?
Für die meisten SaaS-Produkte reicht die geteilte Tabelle mit Mandantenspalte, solange jede Abfrage sie zwingend enthält. Getrennte Datenbanken werden nötig, wenn Kunden es vertraglich verlangen oder wenn einzelne so groß werden, dass sie die anderen ausbremsen.
Wie verhindert man, dass eine Abfrage den Mandanten vergisst?
Indem man es unmöglich macht statt es zu verlangen. Zeilenbasierte Rechte in der Datenbank setzen die Bedingung serverseitig; ein verpflichtender Zugriffslayer setzt sie im Code. Zusätzlich ein Test mit zwei Mandanten, der fehlschlägt, sobald eine Abfrage fremde Zeilen liefert. Reine Vereinbarungen im Team halten dem ersten Termindruck nicht stand.
Was ist der laute Nachbar und was hilft dagegen?
Ein Kunde, dessen Last die Antwortzeiten aller anderen verschlechtert, etwa durch einen Massenimport oder einen sehr großen Bericht. Wirksam sind Kontingente je Mandant, eigene Warteschlangen für Hintergrundarbeit und Obergrenzen für teure Abfragen. Der Ausweg, den Kunden in eine eigene Umgebung zu verschieben, sollte vorbereitet sein, bevor er gebraucht wird.
Wie zieht man einen einzelnen Kunden später heraus?
Nur dann schmerzarm, wenn der Export je Mandant von Anfang an existiert und die Kennungen nicht global fortlaufend, sondern je Mandant eindeutig sind. Wer das nachträglich baut, sortiert Datensätze aus Tabellen, in denen Kunden über Fremdschlüssel verwoben sind, und braucht dafür Wochen.