Mehrere Clients; eine gehostete Anwendung. Sie beschreiben eine mandantenfähige Datenbank.
Wenn Sie eine Multi-Tenant-Datenbank erstellen, müssen Sie
berücksichtigen- Abfrage
- Kosten
- Datenisolierung und -schutz
- Wartung und
- Notfallwiederherstellung.
Multi-Tenant-Lösungen reichen von einer Datenbank pro Mandant (nichts gemeinsam genutzt) bis zu einer Zeile pro Mandant (alles gemeinsam genutzt).
„Nichts gemeinsam genutzt“, „separate Datenbank“ oder eine Datenbank pro Mandant
- Am teuersten pro Client. (Eine große Anzahl von Clients impliziert eine große Anzahl von Servern.)
- Höchster Grad an Datenisolation.
- Die Notfallwiederherstellung für einen einzelnen Mandanten ist einfach und unkompliziert.
- Wartung ist theoretisch schwieriger, da Änderungen in jeder Datenbank durchgeführt werden müssen. Aber Ihr dbms könnte problemlos das Ausführen gespeicherter Prozeduren in jeder Datenbank unterstützen. (SQL Server hat zum Beispiel eine undokumentierte gespeicherte Systemprozedur, sp_msforeachdb. Sie können wahrscheinlich Ihre eigene schreiben.) "Shared nothing" ist auch am einfachsten anpassbar, aber das wirft auch mehr Wartungsprobleme auf.
- Niedrigste Zeilenzahl pro Tabelle. Die Abfragegeschwindigkeit ist nahezu optimal.
„Alles gemeinsam genutzt“ oder „gemeinsames Schema“ oder „eine Datenbank pro Planet“
- Am günstigsten pro Mieter.
- Niedrigster Grad an Datenisolation. Jede Tabelle hat eine Spalte, die angibt, zu welchem Mandanten eine Zeile gehört. Da Mandantenzeilen in jeder Tabelle gemischt sind, ist es relativ einfach, versehentlich die Daten anderer Mandanten offenzulegen.
- Die Notfallwiederherstellung für einen einzelnen Mandanten ist relativ kompliziert; Sie müssen in vielen Tabellen einzelne Zeilen wiederherstellen.
- Die bauliche Instandhaltung ist einfacher, da sich alle Mieter die Tische teilen. Es erhöht jedoch die Kommunikationslast, da Sie jede Änderung mit jedem Mieter kommunizieren und koordinieren müssen. Es ist nicht einfach anpassbar.
- Höchste Zeilenanzahl pro Tabelle. Schnelle Abfragen sind schwieriger, hängen aber davon ab, wie viele Mandanten und wie viele Zeilen vorhanden sind. Sie könnten leicht in das VLDB-Territorium kippen.
Zwischen „nichts gemeinsam genutzt“ und „alles gemeinsam genutzt“ steht „gemeinsames Schema“.
"Gemeinsames Schema"
- Mieter teilen sich eine Datenbank, aber jeder Mandant hat sein eigenes benanntes Schema. Die Kosten fallen zwischen „nichts geteilt“ und „alles geteilt“; Große Systeme benötigen normalerweise weniger Server als "Shared Nothing", mehr Server als "Shared Everything".
- Viel bessere Isolation als "alles geteilt". Nicht ganz so viel Isolation wie "gemeinsames Nichts". (Sie können Berechtigungen für Schemas GEWÄHREN und WIDERRUFEN.)
- Die Notfallwiederherstellung für einen einzelnen Mandanten erfordert die Wiederherstellung eines von vielen Schemas. Dies ist entweder relativ einfach oder ziemlich schwierig, abhängig von Ihrem DBM.
- Wartung ist einfacher als "nichts gemeinsam genutzt"; nicht so einfach wie "alles teilen". Es ist relativ einfach, eine gespeicherte Prozedur zu schreiben, die in jedem Schema in einer Datenbank ausgeführt wird. Es ist einfacher, gemeinsame Tische unter Mietern zu teilen, als mit "shared nothing".
- Normalerweise mehr aktive Mandanten pro Server als "nichts gemeinsam genutzt", was bedeutet, dass sie mehr Ressourcen gemeinsam nutzen (degradieren). Aber nicht so schlimm wie "alles geteilt".
Microsoft hat einen guten Artikel über Mandantenfähige Architektur mit mehr Details. (Der Link führt nur zu einer Seite eines mehrseitigen Dokuments.)
