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

  Email

  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