Multi-Tenant-Datenbanken - Abteilung Datenbanken Leipzig ...
Multi-Tenant-Datenbanken - Abteilung Datenbanken Leipzig ...
Multi-Tenant-Datenbanken - Abteilung Datenbanken Leipzig ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Universität <strong>Leipzig</strong><br />
Fakultät für Mathematik und Informatik<br />
Institut für Informatik<br />
Professur Datenbanksysteme<br />
Seminararbeit<br />
<strong>Multi</strong>-<strong>Tenant</strong>-<strong>Datenbanken</strong> für SaaS<br />
(Schema Management)<br />
Betreuerin: Sabine Maßmann<br />
Bearbeiter: Hendrik Kerkhoff<br />
Nürnberger Str. 20<br />
04103 <strong>Leipzig</strong><br />
Matr.-Nr: 1501624<br />
MSc. 1. Semester<br />
Eingereicht am: 24.01.2010
Inhaltsverzeichnis I<br />
Inhaltsverzeichnis<br />
Abkürzungsverzeichnis II<br />
1 Einleitung 1<br />
1.1 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
2 Grundlagen 3<br />
2.1 Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.2 Anforderungen an <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong> . . . . . . . . . . . . . 3<br />
2.3 Einsatzszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 6<br />
3.1 Shared Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.2 Shared Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.3 Shared Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.3.1 Private Table Layout . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3.3.2 Basic Table Layout . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3.3.3 Extension Table Layout . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.3.4 Universal Table Layout . . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.3.5 Pivot Table Layout . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.3.6 Chunk Table Layout . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.3.7 Chunk Folding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
3.4 Beispiel: force.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
4 Ausblick 15<br />
Abbildungsverzeichnis III<br />
Verzeichnis der Listings IV<br />
Literaturverzeichnis V
Inhaltsverzeichnis II<br />
Abkürzungsverzeichnis<br />
CRM . . . . . . . . . . Customer Relationship Management<br />
DBS . . . . . . . . . . . Datenbanksystem<br />
ERP . . . . . . . . . . . Enterprise Resource Planning<br />
ID . . . . . . . . . . . . . Identifikationsnummer<br />
QTL . . . . . . . . . . . Query Transformation Layer<br />
SaaS . . . . . . . . . . . Software as a Service<br />
SLA . . . . . . . . . . . Service Level Agreements<br />
TCO . . . . . . . . . . . Total Cost of Ownerchip
1 Einleitung 1<br />
1 Einleitung<br />
In seinem Blog 1 stellt Robert Warfield die These auf, dass Unternehmen durch den<br />
Einsatz von Software as a Service im Vergleich zu klassischer Software bis zu 16% ih-<br />
rer Kosten einsparen können [War07]. Dies wird durch Mehrmandantenfähigkeit (engl.<br />
<strong>Multi</strong>-Tenancy) erreicht: Mehrere Kunden nutzen gemeinsam ein Softwaresystem, wel-<br />
ches von einem Serviceanbieter bereitgestellt wird. Hierdurch sinken die Kosten, die<br />
für das Betreiben notwendig sind.<br />
1.1 Ziel der Arbeit<br />
Diese Arbeit soll Möglichkeiten zeigen und erläutern, wie <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong><br />
implementiert werden können. Da für den performanten und somit kostensparenden<br />
Betrieb einer Mehrmandanten-Datenbank eine möglichst hohe Konsolidierung (“Ver-<br />
einheitlichung”) benötigt wird, werden verschiedene Möglichkeiten gezeigt, diese zu<br />
erreichen, ohne dabei auf flexibele Datenbankschemas für die Mandanten verzichten zu<br />
müssen.<br />
1.2 Aufbau der Arbeit<br />
In Kapitel 2 werden die Grundlagen zu Software as a Service erklärt und die An-<br />
forderungen an <strong>Multi</strong>-Tenancy-<strong>Datenbanken</strong> erläutert sowie mögliche Einsatzszenari-<br />
en skizziert. Kapitel 3 beleuchtet die drei Grundmöglichkeiten für den Aufbau einer<br />
Mehrmandantendatenbank. Hierbei liegt der Schwerpunkt auf den verschiedenen An-<br />
sätzen zum Schema-Mapping in der Shared Table-Methode. Zudem wird anhand der<br />
Plattform Force.com die Umsetzung und Optimierung in der Praxis gezeigt.<br />
1 http://smoothspan.wordpress.com/
1 Einleitung 2<br />
Im Ausblick (Kapitel 4) werden Methoden und Techniken vorgestellt, mit denen For-<br />
scher der Technischen Universität München sowie der SAP AG die Umsetzung einer<br />
reinen <strong>Multi</strong>-Tenancy Datenbank planen.
2 Grundlagen 3<br />
2 Grundlagen<br />
In diesem Kapitel wird zunächst das Konzept von Software as a Service erläutert. Im<br />
Anschluss werden Anforderungen an eine <strong>Multi</strong>-Tenancy Datenbank für Software as a<br />
Service beschrieben sowie mögliche Einsatzszenarien beschrieben.<br />
2.1 Software as a Service<br />
Software as a Service (SaaS) ist ein Geschäftsmodell, in dem Software nicht als Produkt<br />
an Kunden verkauft wird, sondern als Dienstleistung für viele Kunden bereitgestellt<br />
wird [BHS08, S. 88]. Ziel hierbei ist es, die Total Cost of Ownerchip (TCO) im Vergleich<br />
zu den Kosten von “on-premises” Lösungen, also vom Kunden selbst betriebene Softwa-<br />
re, zu senken [AJKS09, S. 881]. Um dieses zu erreichen wird die Software vielen Kunden<br />
zur Verfügung gestellt, was dazu führt, dass Kosten wie Thirdparty-Softwarelizenzen,<br />
Hardwarekosten und Kosten für die Administration auf die Mandanten verteilt werden<br />
und somit im Durchschnitt sinken.<br />
Bei der Nutzung von SaaS sind häufig Service Level Agreements (SLA) Bestandteil<br />
der Verträge. In diesen werden nicht-funktionale Anforderungen wie die Kosten für die<br />
Nutung der Services sowie Anforderungen an Verfügbarkeit und Performanz festgelegt<br />
[Pap08].<br />
2.2 Anforderungen an <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong><br />
Bob Warfield, Mitgründer von SmoothSpan und Author von mehreren Artikeln zum<br />
Thema SaaS, leitet in einem seiner Blog-Artikel eine Definition für <strong>Multi</strong>-Tenancy<br />
her:<br />
“<strong>Multi</strong>tenancy is the ability to run multiple customers on a single soft-<br />
ware instance installed on multiple servers to increase resource utilization
2 Grundlagen 4<br />
by allowing load balancing among tenants, and to reduce operational com-<br />
plexity and cost in managing the software to deliver the service. <strong>Tenant</strong>s<br />
on a multitenant system can operate as though they have an instance of<br />
the software entirely to themselves which is completely secure and insulated<br />
from any impact by other tenants.” [War07]<br />
Diese Definition beschreibt <strong>Multi</strong>-Tenancy Systeme aus Sicht von Serviceanbieter sowie<br />
der Mandanten. Die Mandaten werden in [AJPK09] weiter unterschieden zwischen<br />
Kunde und Anwendungsentwickler. Für den Kunden sind “hohe Verfügbarkeit bei hoher<br />
Datensicherheit” zentrale Aspekte eines <strong>Multi</strong>-Tenancy Systems. Die Anforderungen<br />
der Anwendungsentwickler sind “einfache, aber mächtige Funktionsmodelle”.<br />
Eine gemeinsame Instanz wächst aus der Anforderung heraus, dass die operationale<br />
Komplexität minimiert werden soll. Da der Ressourcenbedarf einzelner Instanzen<br />
auf Shared Machine Systemen zu hoch ist, wird gefordert, dass es eine gemeinsame<br />
Datenbankinstanz für mehrere Mandanten gibt.<br />
Isolation der Mandanten ist notwendig für die geforderte Sicherheit und dient der<br />
Herstellung von Transparenz für die Mandanten. Für die Kunden soll das <strong>Multi</strong>-<br />
Tenancy System aussehen, als hätten sie eine eigene Datenbankinstanz.<br />
Schemaflexibilität muss gewährleistet werden. Insbesondere ist es notwendig, Sche-<br />
maänderungen während der Laufzeit durchzuführen, da aufgrund der Transpa-<br />
renzforderung für andere Mandanten das Gesamtsystem online bleiben muss. Je-<br />
doch dürfen Änderungen die Performanz des Systems nicht beeinflussen. Um<br />
dieses zu gewährleisten müssen gegebenenfalls temporäre Tabellen mit dem neu-<br />
en Schema erstellt werden und zu einem Zeitpunkt mit niedriger Last permanent<br />
einbunden werden.<br />
Hohe Verfügbarkeit ist für das Anwendungsgebiet von SaaS notwendige Bedingung,<br />
da im Rahmen von Service Level Agreements meist Vereinbarungen über die<br />
Verfügbarkeit getroffen werden.<br />
2.3 Einsatzszenarien<br />
Durch die steigende Komplexität von Anwendungen sinkt die mögliche Konsolidierung<br />
der Mandaten und somit die Anzahl der Mandanten, die durch ein <strong>Multi</strong>-Tenancy<br />
System gehandhabt werden können [AGJ + 08]. Einfache Software, wie E-Mail Plattfor-
2 Grundlagen 5<br />
men, bieten den Kunden keine oder nur sehr beschränkte Anpassungungen der Softwa-<br />
re. Somit werden erweiterbare Datenstrukturen kaum benötigt und es reichen einfache<br />
und einheitliche Schemas für die Nutzer der Software.<br />
Enterprise Resource Planning (ERP) Systeme hingegen haben eine hohe Komplexität.<br />
Es werden viele Erweiterungen und Anpassungen benötigt, um die Geschäftsprozesse<br />
der Mandanten umzusetzen. Die benötigten Ressourcen, auch hinsichtlich der Lauf-<br />
zeit von einzelnen Operationen, sind um ein Vielfaches höher, als das einer E-Mail-<br />
Plattform. Dieser Zusammenhang ist in Abbildung 2.1 schematisch dargestellt.<br />
Durch Rechner mit mehr Ressourcen ist es möglich, die Anzahl der Mandanten zu ver-<br />
vielfachen. Daher ist der Einsatz von Clustern, welche relativ niedrige Hardwarekosten<br />
haben, für den Einsatz für <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong> sehr gut geeignet.<br />
Größe des<br />
Rechners<br />
Mainframe<br />
Blade-<br />
Server<br />
10.000 1.000<br />
10.000 1.000 100<br />
10.000 1.000 100 10<br />
E-Mail Kollaborationsplattformen<br />
CRM ERP<br />
Komplexität der<br />
Anwendung<br />
Abbildung 2.1: Mandanten pro Datenbank (in Anlehnung an [AGJ + 08, S. 1196])<br />
Hauptanwendung finden <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong> bei Systemen mit mittlerer Kom-<br />
plexität [AGJ + 08, S. 1196]. Beispiele hierfür sind Kollaborationsplattformen wie Goo-<br />
gle Docs 2 , Conject 3 und Microsofts Office Live 4 . Die SaaS-Plattform salesforce.com 5<br />
(siehe hierzu auch Abschnitt 3.4) bietet Customer Relationship Management (CRM)<br />
Software unter Verwendung von <strong>Multi</strong>-Tenancy <strong>Datenbanken</strong> an.<br />
2 http://docs.google.com/<br />
3 http://www.conject.com/<br />
4 http://www.officelive.com/<br />
5 http://www.salesforce.com/
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 6<br />
3 <strong>Multi</strong>-Tenancy mit aktuellen<br />
<strong>Datenbanken</strong><br />
In diesem Kapitel werden drei Möglichkeiten vorgestellt, Mehrmandanten-Fähigkeit<br />
in aktuelle Datenbanksysteme zu integrieren. Bei dem Shared Machine Ansatz erhält<br />
jeder Mandant eine eigene Datenbankinstanz auf einem gemeinsamen Computer. Teilen<br />
sich alle Mandaten eine Datenbankinstanz, wobei jeder Mandant sein eigenes Schema<br />
erhält, spricht man von Shared Process.<br />
Der Schwerpunkt dieses Kapitels liegt auf dem Shared Table Ansatz. In Abschnitt 3.3<br />
werden mehrere Techniken vorgestellt, um das Teilen einer gemeinsamen Tabellenstruk-<br />
tur für alle Mandanten zu ermöglichen.<br />
Mandant Mandant Mandant Mandant Mandant Mandant Mandant Mandant Mandant<br />
Schema Schema Schema<br />
DB DB DB<br />
Computer / Cluster / Grid<br />
Schema Schema Schema<br />
DB<br />
Computer / Cluster / Grid<br />
Schema<br />
DB<br />
Computer / Cluster / Grid<br />
a) Shared Machine b) Shared Process c) Shared Table<br />
Isolation<br />
Ressourcenteilung<br />
Abbildung 3.1: Shared Machine, Shared Process und Shared Table (in Anlehnung an<br />
[JA07a, S. 1198])
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 7<br />
3.1 Shared Machine<br />
Jeder Mandant erhält bei Shared Machine seine eigene Datenbankinstanz auf einer ge-<br />
meinsamen Maschine. Dieser Ansatz ist leicht umzusetzen, da hier keine Modifikationen<br />
an dem Datenbanksystem vorgenommen werden müssen. Alle Mandanten sind bis auf<br />
den gleichen Computer voneinander isoliert (vgl. Abbildung 3.1). Jedoch wirkt sich die-<br />
se Isolation negativ auf die Ressourcennutzung aus: Jede Datenbankinstanz benötigt<br />
Speicher für die Grundfunktionen. Aufgrund dieses hohen Speicherbedarfs skaliert der<br />
Shared Machine Ansatz nur bis circa zehn Instanzen pro Rechner [JA07b]. Zudem kann<br />
der Administrationsaufwand nicht gesenkt werden. Daher eignet sich dieser Ansatz nur<br />
bedingt für die Verwendung als <strong>Multi</strong>-Tenancy Datenbank für SaaS.<br />
3.2 Shared Process<br />
Abbildung 3.1 b) zeigt schematisch den Shared Process Ansatz: Jeder Mandant erhält<br />
hier ein eigenes Schema, welches auf einer gemeinsamen Datenbankinstanz läuft. Durch<br />
die Möglichkeit der physisch getrennten Speicherung der Daten der einzelnen Mandan-<br />
ten ist die Migration von Mandanten auf andere Server sowie die Implementierung von<br />
Load-Balancing einfach zu realisieren [JA07b]. Die physische und logische Trennung<br />
der Daten muss hierbei auf Anwendungsebene vorgenommen werden.<br />
Durch die gemeinsame Nutzung einer Instanz wird lediglich für die verschiedenen Sche-<br />
mas und Daten der Mandanten, jedoch nicht für mehrere Instanzen des Datenbank-<br />
systems Speicher benötigt. Wenn die Anzahl der Tabellen pro Mandant auf wenige<br />
beschränkt ist, skaliert dieser Ansatz für bis zu 1000 aktiver Mandanten pro Server<br />
[JA07b]. Daher ist er gut für kleine und mittlere SaaS-Anwendungen geeignet.<br />
3.3 Shared Table<br />
Durch die Verwendung des Shared Table Ansatzes können die meisten Einsparungen<br />
hinsichtlich Hardwarekosten gemacht werden. Jedoch müssen zusätzliche Erweiterun-<br />
gen am Datenbanksystem implementiert werden: Da alle Mandanten die gleichen Ta-<br />
bellen nutzen muss eine Zwischenschicht, die Query-Transformation-Schicht (QTL)<br />
(siehe Abbildung 3.2) entwickelt werden [AGJ + 08]. Diese sorgt dafür, dass für die<br />
Mandanten das physische Schema transparent ist. Jeder Mandant hat ein eigenes, lo-
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 8<br />
gisches Schema. Die QTL wandelt die Anfragen um und mappt diese auf das physische<br />
Datenbankschema. Hierbei muss zudem sichergestellt werden, dass nur die Daten des<br />
Mandanten angefragt werden. Die Ergebnisse werden dann wieder passend zu dem<br />
logischen Schema des Mandanten umgewandelt.<br />
Mandant<br />
1<br />
Software<br />
logisches<br />
Schema<br />
Mandant<br />
2<br />
logisches<br />
Schema<br />
Mandant<br />
3<br />
Software Software<br />
logisches<br />
Schema<br />
Query Transformation Schicht<br />
physisches Schema<br />
Datenbank<br />
Betriebsystem<br />
Hardware<br />
Abbildung 3.2: Query Transformation Layer (selbsterstellte Grafik)<br />
Die Datenmigration für einzelne Mandanten ist nicht problemlos möglich, kann jedoch<br />
auf Kosten zusätzlicher Abfragen durchgeführt werden.<br />
Es gibt verschiedene Tabellen-Layouts, die den Shared Table Ansatz ermöglichen. Al-<br />
le diese Ansätze sind hierbei Kompromisse zwischen Performanz, Funktionaliät und<br />
Flexibilität.<br />
In den folgenden Abschnitten werden diese Layouts dargestellt und erläutert. Die Bei-<br />
spiele hierfür entstammen dem Paper [AGJ + 08]. Es wurde ein Szenario mit drei Man-<br />
danten gewählt. Der Mandant mit der ID 17 stammt aus dem Gesundheitsbereich,<br />
Mandant 42 hat eine Erweiterung im Bereich der Automobilindustrie. Mandant 35 hat<br />
keine Erweiterungen.
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 9<br />
3.3.1 Private Table Layout<br />
Beim Private Table Layout erhält jeder Mandant eigene Tabellen. Diese werden le-<br />
diglich umbenannt, um zu gewährleisten das ein bestimmter Tabellenname nicht nur<br />
von einem Mandanten genutzt werden kann. Hierzu werden in den Meta-Daten des<br />
Datenbanksystems bzw. des Query-Transformation-Layers Mapping Daten gehalten.<br />
Eine Konsolidierung der Mandanten findet hier nicht statt.<br />
Abbildung 3.3 zeigt ein Schema mit privaten Tabellen. Die Tabellen sind hier nach<br />
“Account” sowie der Mandanten-ID benannt. Wenn diese Tabellen für alle Mandan-<br />
ten “Account” heißen, so muss bei der Abfrage ein Mapping von AccountXX <br />
Account durchgeführt werden, wobei XX die Mandanten-ID repräsentiert.<br />
Abbildung 3.3: Private Table Layout (aus [AGJ + 08, S. 1198])<br />
3.3.2 Basic Table Layout<br />
Da sich die Mandanten alle Tabellen beim Basic Table Layout teilen, ist es nicht mög-<br />
lich, mandantenspezifische Erweiterungen zu handhaben. Die Datensätze der jeweiligen<br />
Mandanten werden durch eine hinzugefügte <strong>Tenant</strong>-Spalte unterschieden (siehe Abbil-<br />
dung 3.4).<br />
Das Basic Table Layout eignet sich lediglich für angebotene Software, in der keine<br />
Erweiterungen benötigt werden, wie z.B. Webmail oder Blogs.<br />
Account<br />
<strong>Tenant</strong> Aid Name<br />
17 1 Acme<br />
17 2 Gump<br />
35 1 Ball<br />
42 1 Big<br />
Abbildung 3.4: Basic Table Layout (selbsterstellte Grafik)
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 10<br />
3.3.3 Extension Table Layout<br />
Beim Extension Table Layout werden mandantenspezifische Erweiterungen in zusätzli-<br />
chen Tabellen gespeichert. Alle Tabellen erhalten eine Spalte mit der ID des Mandanten<br />
sowie eine Spalte durch welche der Datensatz identifiziert wird. Durch die Mandanten-<br />
ID ist es möglich, dass mehrere Mandanten eine Erweiterung nutzen. Die Datensatz-IDs<br />
sind notwendig, um die Tabellen durch einen JOIN zum logischen Datenbankschema<br />
zurückzuführen. Abbildung 3.5 zeigt das Schema einer Extension Table.<br />
Durch die Fragmentierung in mehrere Tabellen entstehen zusätzliche Schreib-/Lesezugriffe,<br />
da nicht sichergestellt werden kann, dass zusammengehörige Reihen zusammenhängend<br />
in den Speicher geschrieben werden.<br />
1 SELECT Aid, Name, Hospital, Beds FROM<br />
2 (SELECT Aid, Name, Hospital, Beds<br />
3 FROM AccountExt a, HealthcareAccount h<br />
4 WHERE a.Row = h.Row AND a.<strong>Tenant</strong> = 17 AND h.<strong>Tenant</strong> = 17)<br />
5 AS Account17<br />
Listing 3.1: Transformierte SQL Anfrage für Extension Table Layout<br />
Listing 3.1 zeigt eine Anfrage an die Daten. Hierbei wird eine JOIN-Verknüpfung zwi-<br />
schen den Tabellen AccountExt und Healthcare Account durchgeführt. Das Ergebnis<br />
wird in einer Tabelle mit dem Namen “Account17” ausgegeben.<br />
Abbildung 3.5: Extension Table Layout (aus [AGJ + 08, S. 1198]))<br />
3.3.4 Universal Table Layout<br />
Das Univeral Table Layout hat nur eine Tabelle, in der sämtliche Daten gespeichert<br />
werden. Um dies zu ermöglichen wird eine Table-Spalte eingeführt, mit der die ein-<br />
zelnen Tabellen des logischen Schemas unterschieden werden. Die Daten werden beim<br />
Universal Table Layout in Spalten mit einem universellem Datentyp, wie z.B. VAR-<br />
CHAR, gespeichert.
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 11<br />
Um Flexibilität zu gewährleisten, muss die Anzahl der Spalten sehr breit gewählt wer-<br />
den. Hierduch entstehen viele Zellen mit NULL-Werten, welche zwar von den meisten<br />
Datenbanksystemen effizient verwaltet werden, aber dennoch einen Speicher-Overhead<br />
erzeugen. Zusätzlich muss das DBS Meta-Daten halten, in denen die Datentypen so-<br />
wie die logischen Namen der Spalten in Abhängigkeit der jeweiligen logischen Tabelle<br />
gespeichert werden.<br />
Ein großer Nachteil vom Universal Table Layout ist, dass die Indizierung nicht prakti-<br />
kabel ist.<br />
Abbildung 3.6: Universal Table Layout (aus [AGJ + 08, S. 1198])<br />
3.3.5 Pivot Table Layout<br />
Beim Pivot Table Layout werden neben der Mandanten- und Tabellen-Spalte Reihen-<br />
sowie Spalten-Werte eingefügt. Jeder Wert eines Datensatzes in der logischen Tabelle<br />
wird hier in einem eigenen Datensatz gespeichert. Hierduch sind für die Rückführung<br />
einer n-Spaltigen Tabelle n − 1 Join-Verknüpfungen notwendig. Jedoch entfällt im Ver-<br />
gleich zu Universal Tables die Speicherung von NULL-Werten.<br />
Die Daten selbst können hierbei entweder als variabler Datentyp VARCHAR gespei-<br />
chert werden oder man führt für jeden Datentyp eine eigene Pivot-Tabelle ein (siehe<br />
Abbildung 3.7), wodurch das Casten der Datentypen entfällt. Um Indizies zu unter-<br />
stützen können zusätzliche Index-Tabellen für jeden Datentyp eingeführt werden.<br />
3.3.6 Chunk Table Layout<br />
Die Datensätze werden in Chunks, also “Datenblöcke” untergliedert. Mehrere dieser<br />
Chunks bilden gemeinsam einen logischen Datensatz. Dazu wird beim Chunk-Table-<br />
Layout neben Spalten für <strong>Tenant</strong>, Tabelle und Reihe eine Chunk-Nummer vergeben.<br />
Physische Zeilen mit gleicher <strong>Tenant</strong>-ID, gleicher Tabellennummer und gleicher Rei-
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 12<br />
1 SELECT Beds FROM<br />
2 (SELECT s.Str as Hospital, i.Int as Beds<br />
3 FROM PivotStr s, PivotInt i<br />
4 WHERE s.<strong>Tenant</strong> = 17<br />
5 AND i.<strong>Tenant</strong> = 17<br />
6 AND s.Table = 0<br />
7 AND s.Col = 2<br />
8 AND i.Table = 0<br />
9 AND i.Col = 3<br />
10 AND s.Row = i.Row)<br />
11 WHERE Hospital=’State’<br />
Listing 3.2: Transformierte SQL Anfrage für Pivot Table Layout<br />
Abbildung 3.7: Pivot Table Layout (aus [AGJ + 08, S. 1198])<br />
he gehören zu einem logischen Datensatz, sortiert nach den inkrementierten Chunk-<br />
Nummern. In Abbildung 3.8 sind dieses beispielsweise die ersten beiden Zeilen.<br />
In einem Chunk werden verschiedene Attribute mit verschiedenen Datentypen, wahl-<br />
weise mit Indizierung, gespeichert. Hierdurch ist es möglich, häufig zusammen auftre-<br />
tende Werte zu gruppieren, wodurch die Schreib-/Lesezugriffe optimiert werden kön-<br />
nen.<br />
Abbildung 3.8: Chunk Table Layout (aus [AGJ + 08, S. 1198])
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 13<br />
Im Vergleich zu Pivot Tabellen wird hier nur eine Tabelle benötigt, wodurch der Auf-<br />
wand für die Rekonstruktion der logischen Tabellen geringer ausfällt. Die Anfrage-<br />
Transformation ist jedoch komplexer. Dieses wird leicht aus einem Beispiel ersicht-<br />
lich: Für das Auflösen der Spaltennamen wird beim Pivot Table Layout ein Map-<br />
ping <strong>Tenant</strong>, Table, Col -> Spaltenname benötigt. Hingegen beim Chunk<br />
Table Layout <strong>Tenant</strong>, Table, Chunk -> Int1 = Spaltenname1 | Str1 =<br />
Spaltenname2. Die Spalten in der physischen Schicht müssen hier nochmal zugeord-<br />
net werden.<br />
3.3.7 Chunk Folding<br />
In [AGJ + 08] stellen die Autoren eine weitere Schema-Mapping Technik vor: Chunk<br />
Folding. Es werden die Techniken des Extension Tables mit denen der Chunk Tables<br />
kombiniert. Abbildung 3.9 zeigt ein Schema für Chunk Folding. Hierbei gibt es eine<br />
(oder auch mehrere) gemeinsame Tabelle, die von allen (oder vielen) Mandanten ge-<br />
nutzt werden sowie eine Erweiterungstabelle deren Struktur dem Chunk Table Layout<br />
entspricht.<br />
Abbildung 3.9: Chunk Folding (aus [AGJ + 08, S. 1198])<br />
Durch diese Kombination wird erreicht, dass häufig genutzte Attribute in herkömmli-<br />
chen Tabellen gespeichert werden, wodurch erhöhter I/O- sowie Transformationsauf-<br />
wand beim Zugriff auf Attribute dieser Tabelle entfällt. Durch Variation der Breite<br />
der Chunk-Tabelle wird diese zu einer Mischform von Universal Table Layout und<br />
Chunk Table Layout: Die Breite kann so optimiert werden, dass z.B. 80% der logischen<br />
Datensätze in einen Chunk passen. Tabellen mit vielen Attributen werden hingegen<br />
in zwei oder mehr Chunks verteilt. Dadurch wird der Aufwand, mandantenspezifische<br />
Erweiterungen zu Laden und Verarbeiten, gering gehalten.
3 <strong>Multi</strong>-Tenancy mit aktuellen <strong>Datenbanken</strong> 14<br />
3.4 Beispiel: force.com<br />
Die Plattform Salesforce.com, Anbieter von Customer Relationship Management (CRM),<br />
sowie deren Tochter-Plattform Force.com, eine Entwicklungsumgebung für die Entwick-<br />
lung von Cloud-basierter Software, nutzen <strong>Multi</strong>-Tenancy für die Datenhaltung. Das<br />
Datenbankschema zeigt Abbildung 3.10. Es handelt sich hierbei um ein Universal Table<br />
Layout mit mehreren Erweiterungen zur Optimierung sowie Flexibilisierung.<br />
Metadaten<br />
Objects<br />
# GUID<br />
OrgID<br />
ObjID<br />
ObjName<br />
Fields<br />
# GUID<br />
OrgID<br />
ObjID<br />
FieldName<br />
Datatype<br />
isIndexed<br />
FieldNum<br />
...weitere...<br />
Datentabellen Spezielle Pivot Tabellen<br />
Data<br />
# GUID<br />
OrgID<br />
ObjID<br />
Name<br />
Value0<br />
Value1<br />
...<br />
Value500<br />
Clobs<br />
Character Large Objects<br />
bis zu 32.000 Zeichen<br />
Indexes<br />
# OrgID<br />
# ObjID<br />
# FieldNum<br />
GUID<br />
StringValue<br />
NumValue<br />
DateValue<br />
Relationships<br />
OrgID<br />
ObjID<br />
GUID<br />
RelationID<br />
TargetObjID<br />
...weitere...<br />
Abbildung 3.10: Force.com Datenbankschema (in Anlehnung an [For08])<br />
Mithilfe von Pivot-Tabellen werden beispielsweise Indizierungen ermöglicht. Die Ind-<br />
exes Tabelle enthält hierfür neben Schlüsseln, die das zu indizierende Objekt referen-<br />
zieren, Spalten mit verschiedenen Datentypen. Über diese wird die Indizierung durch-<br />
geführt. Zudem gibt es Tabellen für Relationen zwischen den Objekten, eine Tabelle<br />
für Unique-Werte, History-Tracking Tabellen und viele weitere [For08].<br />
In Metadaten-Tabellen werden Informationen über die gespeicherten Objekte (Objects-<br />
Tabelle) sowie Meta-Informationen über die einzelnen Werte in der Datentabelle gespei-<br />
chert. Mit diesen Informationen kann das logische Schema der Mandanten aus diesem<br />
physischem Schema rekonstruiert werden.
4 Ausblick 15<br />
4 Ausblick<br />
In ihrer Arbeit [AJPK09] stellen Aulbach et al. ein Modell für die Implementierung<br />
einer “echten” <strong>Multi</strong>-<strong>Tenant</strong>-fähigen Datenbank vor. Dieses soll mithilfe von Grid-<br />
Technologien sowie Virtualisierung ermöglicht werden.<br />
Abbildung 4.1: <strong>Multi</strong>-Tenancy DBMS (aus [AJPK09])<br />
Die Authoren wollen hierfür ein Grid-Cluster verwenden, wobei auf die einzelnen Kno-<br />
ten die <strong>Datenbanken</strong> der Mandaten aus einem Archiv-Speicher geladen werden (vgl.<br />
Abbildung 4.1). Je nach Auslastung soll dieser Vorgang dynamisch erfolgen. Bei hoher<br />
Last werden die <strong>Datenbanken</strong> auf andere Knoten repliziert. Hierbei werden zunächst<br />
die veralteten Abbilder aus dem Archivspeicher kopiert und anschließend durch einen<br />
Roll-Forward mithilfe von Log-Dateien aktualisiert [AJPK09].<br />
Durch <strong>Tenant</strong> Swizzling, einer von den Autoren entwickelten Technik, die sich an “das<br />
Pointer Swizzling in objekt-orientierten DBMS” [AJPK09] anlehnt, wird ein schneller<br />
Datenzugriff gewährleistet: Die Daten im Hauptspeicher werden von den Daten des<br />
Archivspeichers vollkommen getrennt, wodurch Lese- und Schreibzugriffe auf langsa-<br />
men Festplattenspeicher entfallen. Dieses wird durch Pointer ermöglicht, die jeweils auf<br />
referenzierende Objekte zeigen. Sollen diese Objekte persistiert werden, so müssen die<br />
Pointer aufgeflöst und durch entsprechende Referenzierungen per ID ersetzt werden.<br />
Durch den Einsatz dieser Techniken sollen Probleme der “klassischen” <strong>Multi</strong>-Tenancy-<br />
Lösungen hinsichtlich Isolation und Ressourcenverwaltung gelöst werden. Eine Umset-<br />
zung dieses Entwurfs ist geplant [AJPK09].
Abbildungsverzeichnis III<br />
Abbildungsverzeichnis<br />
2.1 Mandanten pro Datenbank (in Anlehnung an [AGJ + 08, S. 1196]) . . . . 5<br />
3.1 Shared Machine, Shared Process und Shared Table (in Anlehnung an<br />
[JA07a, S. 1198]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
3.2 Query Transformation Layer (selbsterstellte Grafik) . . . . . . . . . . . 8<br />
3.3 Private Table Layout (aus [AGJ + 08, S. 1198]) . . . . . . . . . . . . . . 9<br />
3.4 Basic Table Layout (selbsterstellte Grafik) . . . . . . . . . . . . . . . . 9<br />
3.5 Extension Table Layout (aus [AGJ + 08, S. 1198])) . . . . . . . . . . . . 10<br />
3.6 Universal Table Layout (aus [AGJ + 08, S. 1198]) . . . . . . . . . . . . . 11<br />
3.7 Pivot Table Layout (aus [AGJ + 08, S. 1198]) . . . . . . . . . . . . . . . 12<br />
3.8 Chunk Table Layout (aus [AGJ + 08, S. 1198]) . . . . . . . . . . . . . . 12<br />
3.9 Chunk Folding (aus [AGJ + 08, S. 1198]) . . . . . . . . . . . . . . . . . . 13<br />
3.10 Force.com Datenbankschema (in Anlehnung an [For08]) . . . . . . . . . 14<br />
4.1 <strong>Multi</strong>-Tenancy DBMS (aus [AJPK09]) . . . . . . . . . . . . . . . . . . 15
Verzeichnis der Listings IV<br />
Verzeichnis der Listings<br />
3.1 Transformierte SQL Anfrage für Extension Table Layout . . . . . . . . 10<br />
3.2 Transformierte SQL Anfrage für Pivot Table Layout . . . . . . . . . . . 12
Literaturverzeichnis V<br />
Literaturverzeichnis<br />
[AGJ + 08] S. Aulbach, T. Grust, D. Jacobs, A. Kemper, and J. Rittinger. <strong>Multi</strong>-tenant<br />
databases for software as a service: schema-mapping techniques. In Procee-<br />
dings of the 2008 ACM SIGMOD international conference on Management<br />
of data, pages 1195–1206. ACM New York, NY, USA, 2008.<br />
[AJKS09] S. Aulbach, D. Jacobs, A. Kemper, and M. Seibold. A comparison of flexible<br />
schemas for software as a service. In Proceedings of the 35th SIGMOD in-<br />
ternational conference on Management of data, pages 881–888. ACM, 2009.<br />
[AJPK09] S. Aulbach, D. Jacobs, J. Primsch, and A. Kemper. Anforderun-<br />
gen an Datenbanksysteme für <strong>Multi</strong>-Tenancy-und Software-as-a-Service-<br />
Applikationen. BTW 2009 - Proceedings, 2009. http://131.159.16.<br />
103/research/publications/conferences/btw2009-mtd.pdf.<br />
[BHS08] W. Beinhauer, M. Herr, and A. Schmidt. SOA für agile Unternehmen: Ser-<br />
viceorientierte Architekturen verstehen, einführen und nutzen. Symposion<br />
Publishing GmbH, 2008.<br />
[For08] Force.com. The force.com multitenant achitecture. Whi-<br />
tepaper, 2008. http://www.apexdevnet.com/media/<br />
ForcedotcomBookLibrary/Force.com_<strong>Multi</strong>tenancy_WP_<br />
101508.pdf.<br />
[JA07a] D. Jacobs and S. Aulbach. Ruminations on multi-tenant databases.<br />
BTW, 2007. Vortragsfolien, http://www.btw2007.de/vortraege/<br />
JacobsAulbach.pdf.<br />
[JA07b] D. Jacobs and S. Aulbach. Ruminations on multi-tenant databases. In BTW<br />
Proceedings. Citeseer, 2007.<br />
[Pap08] M.P. Papazoglou. Web services: principles and technology. Pearson Prentice<br />
Hall, 2008.<br />
[War07] Robert Warfield. <strong>Multi</strong>tenancy can have a 16:1 cost advantage over single-<br />
tenant, 2007. http://smoothspan.wordpress.com/2007/10/28/<br />
multitenancy-can-have-a-161-cost-advantage-over-single<br />
-tenant/.