Hendrik Kerkhoff 1
(Schema-Management)
Seminar Cloud Data Management WS 09/10
Hendrik Kerkhoff 2
Anforderungen an eine Multi-Tenancy Datenbank
Erweiterung von klassischen Datenbanken Funktionsweise & Einsatzgebiete
Schema-Mapping Techniken
Performanz
Beispiel: Force.com
SaaS Multi-Tenancy DBS
Hendrik Kerkhoff 3
Multi-tenancy refers to the ability to run multiple customers on a single software instance installed
on multiple servers. This is done to increase resource utilization by allowing load
balancing among tenants, and to reduce operational complexity and cost in managing the
software to deliver the service.
From a customer’s perspective, multi-tenancy is transparent. The customer seems to have an
instance of the software entirely to themselves. Most importantly, the customer’s data is secure relative to other
customer’s data and customization can be employed to the degree the application
supports it without regard to what other tenants are doing.
[1] Bob Warfield
Hendrik Kerkhoff 4
• Private Table Layout
• Basic Table Layout
• Extension Table Layout
• Universal Table Layout
• Pivot Table Layout
• Chunk Table Layout
• Chunk Folding
Hendrik Kerkhoff 5
Mandanten erhalten eigenes, logisches Schema
Query Transformation Schicht (QTL) sorgt für Umwandlung der SQL Anfragen von logischem auf physisches Schema Metadaten
Mandanten-Prioritäten für SLAs leicht realisierbar, da QTL „vorgeschaltet“
Selbsterstellte Grafik
Hendrik Kerkhoff 6
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Cloud ? ?
Hendrik Kerkhoff 7
Vorteile: Jeder Mandant hat eigenes Datenbank-Schema
Leichte Realisierung von Erweiterungen Nur Umbenennung der Tabellen notwendig
Nachteile Hohe Isolation = Konsolidierung („Vereinheitlichbarkeit“) Hoher Speicherbedarf
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 8
Eine Tabelle für alle Mandanten
Nutzung der „Tenant ID“ zur Zuordnung der Daten
„Query Transformation Layer“ fügt „Tenant ID“ an SELECT Name FROM Account
SELECT Name FROM Account WHERE TenantID = 13
Account
17173542
1211
AcmeGumpBallBig
Tenant Aid Name
Selbsterstellte Grafik
Hendrik Kerkhoff 9
Vorteile: Einfache Implementierung
Geringer Speicherverbrauch
Gut geeignet für einfache Anwendungen wie
Blogs
Nachteile Keine mandantenabhängigen Erweiterungen
Hendrik Kerkhoff 10
Erweiterungen des Grundschemas durch zusätzliche Tabellen
Tentant-Spalte Notwendig, da mehrere Mandanten eine Erweiterung nutzen
können
Row-Spalte
Ermöglicht die Rekonstruktion der logischen Tabellen
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 11
Vorteile Nur Tabellen, die benötigt werden müssen gelesen werden
Performanz-Gewinn
Hohe Konsolidierung („Vereinheitlichbarkeit“)
Einfache Erweiterbarkeit
Nachteile Rekonstruktion der logischen Tabellen durch zusätzliche Join-
Operationen aufwändig
Zusätzlicher Schreib-/Leseaufwand da nicht sichergestellt werden kann, dass Reihen in gleichem Speicherbereich hinterlegt sind (hohe Fragmentierung)
Hendrik Kerkhoff 12
Tentant und Table Spalte
Mehrere generische Spalten Flexibeler Datentyp, z.B. VARCHAR
Mapping: Spalte „Col n“ = Spalte n in logischer Tabelle
Metadaten über Spaltentypen und logische Tabellen
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 13
Vorteile Rekonstruktionsaufwand gering, da alle Werte eines
Datensatzes zusammen
Problemlose Erweiterungen
Nachteile Datentypen müssen umgewandelt werden, nicht typsicher
Sehr breite Spalten notwendig
Viele NULL-Werte
Indizierung nicht praktikabel: entweder über alle Mandanten, oder gar nicht
Hendrik Kerkhoff 14
Tenant, Table, Row und Column-Spalte Jedes Feld in der logischen Tabelle wird zu eigenem Datensatz in Pivot-
Tabellen VARCHAR als Datentyp verteilte Universal Table Für jeden Datentyp eigene Tabelle
Keine Speicherung von NULL-Werten notwendig
Für Indizierung: neue Tabelle, z.B. PivotStrIndex
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 15
Vorteile Keine NULL-Werte
Problemlose Erweiterbarkeit
Wenig Metadaten notwendig
Nachteile Logische Tabelle mit N-Spalten erfordert (N-1) Joins zur
Rekonstruktion
Geringerer Aufwand bei wenigen Spalten
Hendrik Kerkhoff 16
Tentant, Table, Chunk und Row Spalten Chunks (=„Blöcke“) identifizieren Reihenfolge der Werte
Spalten mit verschiedenen Datentypen Spart Metadaten sowie Umwandlung der Daten Erlaubt das „sinnvolle“ Indizieren von Spalten
Durch das Ändern der Breite können Joins verringert werden – auf Kosten eventueller NULL-Werte
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 17
Vorteile Einfache Erweiterungen
Datentypen müssen nicht umgewandelt werden
Nur eine Tabelle im Speicher
Wenige Metadaten notwendig
Nachteile Viele Selbst-Joins
durch Haltung fast aller Daten im Arbeitsspeicher relativ geringe Kosten
Hohe Flexibilität bedeutet aufwendige Query-Transformation
Hendrik Kerkhoff 18
Mischung aus Extension Tables und Chunk Tables Oft / gemeinsam Benutzte Daten werden in einer Tabelle
gespeichert
Seltene Attribute werden in Chunk-Tabellen gespeichert
* Stefan Aulbach, Torsten Grust, Dean Jacobs, Alfons Kemper, Jan Rittinger: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques [2]
Hendrik Kerkhoff 19
Vorteile Hohe Konsolidierung
Eine Tabelle für gemeinsame Daten
Erweiterbarkeit
Typsicherheit gewährleistet
Nachteile Transformationsaufwand
Jedoch nicht größer als bei Chunk Tables
Hendrik Kerkhoff 20
• DB2 Datenbank auf 2.8Ghz Intel Xeon, 1GB Arbeitsspeicher, 2Gbit/s Ethernet Anbindung
• 10 Tabellen, 10.000 Mandanten (1.4MB Daten / Mandant)
• 4 KB pro Tabelle je Schema
• 8 KB für Benutzerdaten inkl. Indizierung
• verschiedene Anfragen (Select, Insert, Update) mit unterschiedlicher Komplexität
• Extension Table Layout ohne Erweiterungen
Hendrik Kerkhoff 21
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 22
Kosten für JOINs
[2] Aulbach et. Al: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques
Hendrik Kerkhoff 23
Isolation Konsoli-dierung
Erweiter-barkeit
Transformationsaufwand
Sonstiges
Private Table ++ -- o ++ - Hoher Speicherbedarf
Basic Table + ++ (o) -- ++ - Keine Erweiterungen
Extension Table + ++ ++ o - ggf. hoher Speicherbedarf
Universal Table o o o - - Viele NULL-Werte - Keine Indizierung - nicht Typsicher
Pivot Table o o ++ - - Viele JOINS
Chunk Table o o ++ o - Nur eine Tabelle - wenige Metadaten
Chunk Folding o + ++ o - Gute Mischung
Hendrik Kerkhoff 24
Von außen aufgesetzte Mandantenfähigkeit Nur Zwischenschicht kennt Verknüpfungen zwischen Daten
Datenbanken werden zu „Datentopf“
wenig Optimierung der Daten möglich
Durch wenige Tabellen bessere Ausnutzung des Arbeitsspeichers Allerdings müssen logische Strukturen durch Joins wieder
zusammengeführt werden
Modifikation der Kerntabellen schwierig Kompatibilität der Mandanten muss gewährleistet sein, muss
durch Versionierung hergestellt werden
Hendrik Kerkhoff 25
Software-Entwicklungsplattform als Dienst Entwicklung von beliebigen SaaS-Applikationen
Hosting von SaaS
Fertige Funktionalitäten Benutzerverwaltung
Datenmanagement
Workflows
Reporting
Multi-Tenant Datenbank Universal Table Layout
Optimierungen
Hendrik Kerkhoff 26
Datentabellen Metadaten Spez. Pivot Tabellen
[3] Salesforce.com: The Force.com Multitenant Architecture
Hendrik Kerkhoff 27
Hendrik Kerkhoff 28
Private Table Schema
Grid-Infrastruktur Geringe Hardwarekomplexität mit gemeinsamem
Archivspeicher
Replikation auf Mandantenebene zur Performanzsteigerung und Verfügbarkeit Eine globale Logging-Datei pro Mandant
Hendrik Kerkhoff 29
Hendrik Kerkhoff 30
1. Bob Warfield, SmoothSpan Blog 27th October 2007, http://smoothspan.wordpress.com/2007/10/28/multitenancy-can-have-a-161-cost-advantage-over-single-tenant/
2. Stefan Aulbach, Torsten Grust, Dean Jacobs, Alfons Kemper, Jan Rittinger: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques, SIGMOD’08, ACM 978-1-60558-102-6/08/0
3. Salesforce.com: The Force.com Multitenant Architecture, 2008, http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf
4. Stefan Aulbach, Dean Jacobs, Alfons Kemper, Michael Seibold: A Comparison of Flexible Schemas for Software as a Service, SIGMOD’09, ACM 978-1-60558-551-2/09/06
5. Dean Jacobs, Stefan Aulbach: Ruminations on Multi-Tenant Databases, BTW 2007, http://www.btw2007.de/paper/p514.pdf