A. Göbel, Prof. Dr. K. Küspert Friedrich-Schiller-Universität Fakultät für Mathematik und Informatik Seminar am Lehrstuhl für Datenbanken und Informationssysteme Software as a Service, Cloud Computing und aktuelle Entwicklungen Flexible Schemata für Cloud-Anwendungen SoSe 2010 Michael Zenker 8. Fachsemster, WiInf
Agenda Einführung und Motivation Vorstellung und Bewertung verschiedener Ansätze für flexible Schemata Beispiel: die Force.com-Architektur Michael Zenker Folie 2
Einführung Ziele von SaaS und Cloud Computing Senkung der Costs of Ownership (im Vergleich zu klassischer Software on Premises) Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Wie? Kosten (Lizenzen, Hardware-, Administrationskosten) auf mehrere Mandanten verteilen Multi-Tenancy Michael Zenker Folie 3
Senkung der Kosten I Konsolidierung mehrerer Mandanten auf Hardware- und z.t. auch auf logischer Ebene dadurch bessere Auslastung der Systeme 3 Möglichkeiten: Quelle: Multi-Tenant-Datenbanken für SaaS (Schema Management) Michael Zenker Folie 4
Shared Table Ansatz zusätzliche Schicht zwischen logischen Schemas der Mandanten und physischen Schema Query Transformation Layer (QTL) durch Abbildung Isolation (Transparenz) gewährleistet Quelle: Multi-Tenant-Datenbanken für SaaS (Schema Management) Michael Zenker Folie 5
Senkung der Kosten II Grad der Konsolidierung (Anzahl der Mandaten pro DB) ist abhängig von: der Komplexität der Anwendung Potential der verfügbaren Ressourcen Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Michael Zenker Folie 6
Anforderungen an Multi Tenancy Datenbanken Konsolidierung Hohe Verfügbarkeit Isolation (Sicherheit und Transparenz) Flexibilität (Erweiterbarkeit) unterschiedlichen Anforderungen der Mandaten gerecht werden Schemaänderungen im laufenden Betrieb Michael Zenker Folie 7
Agenda Einführung und Motivation Vorstellung und Bewertung verschiedener Ansätze für flexible Schemata Beispiel: die Force.com-Architektur Michael Zenker Folie 8
Ein Beispiel 3 Mandanten: Mandant 17 aus Gesundheitsbereich Attribute: Aid (Integer) Name (String) Hospital (String) Beds (Integer) Mandant 42 aus Automobilindustrie Attribute: Aid (Integer) Name (String) Dealers (Integer) Mandant 35 (ohne Erweiterung) Attribute: Aid (Integer) Name (String) Michael Zenker Folie 9
Private Table Layout (Shared Process) jeder Mandant erhält eigene Tabelle SELECT Beds FROM Account 17 WHERE Hospital= State ; + einfachster Weg zur Erweiterung + Im Prinzip kein (bzw. nur bedingt) QTL nötig + keine zusätzlichen Meta-Daten - keine Konsolidierung möglich Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques für (mittel-) große Anwendungen (wenige Mandanten nutzen volle Ressourcenkapazität) Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Michael Zenker Folie 10
Basic Table Layout + nur eine Tabelle + sehr gute Konsolidierung + im Prinzip kein (bzw. nur bedingt) QTL nötig + als Meta-Daten nur Mandanten-ID für Zuordnung Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques - keine Erweiterung möglich für kleine/einfache Anwendungen (geringer Anpassungsbedarf) Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Michael Zenker Folie 11
Extension Table Layout eine Basistabelle für häufigen Attribute) und Erweiterungstabellen für zusätzliche Attribute + einfacher Weg zur Erweiterung bedingte Konsolidierung (in Basistabelle und bei gemeinsam nutzbaren Erweiterungstabellen) - mit zunehmender Mandantenanzahl steigt auch Tabellenanzahl - QTL nötig ( Rekonstruktionsaufwand: Join entlang der Zeilenfragmente) - neben Mandanten-ID auch Row in den Meta-Daten Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Query Transformation SELECT Beds FROM (SELECT h.hospital AS Hospital, h.beds AS Beds FROM Account Ext a, Healthcare Account h WHERE a.row = h.row AND a.tenant = 17 AND h.tenant = 17) AS Account 17 WHERE Hospital= State Michael Zenker Folie 12
XML Table Layout Erweiterung der Basistabelle um eine Spalte mit zusätzlichen Attributen als XML Dokument Zugriff auf zusätzliche Attribute via XPath, XQuery + Keine Null-Werte + sehr gute Erweiterung und Konsolidierung Noch nicht von allen Systemen unterstützt Schlechtere Performance durch höheren Aufwand (Casting untypisierter Daten, zusätzliche Transformation des XML, etc.) Quelle: A Comparison of Flexible Schemas for Software as a Service Query Transformation SELECT e.beds AS Beds FROM Account a, XMLTABLE( i/ext PASSING a.ext_xml AS i COLUMNS Beds INTEGER PATH beds, Hospital VARCHAR(15) PATH hospital ) AS e WHERE a.tenant =17 AND e.hospital= State Michael Zenker Folie 13
Universal Table Layout eine (sehr breit) Tabelle (Spalten vom Datentyp VARCHAR um Flexibilität zu gewährleisten) n-te Spalte einer logischen (Mandanten-) Tabelle abgebildet auf n-te Spalte der Universal-Table + Erweiterung, insbesondere Online- Modifikation ohne DDL + sehr gute Konsolidierung - zusätzliche Meta-Daten für Datentypen, Spaltennamen/ -zuordnung - Nachteile durch unpraktikable Indizierung, Castings (QTL), viele NULL-Werte Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Query Transformation SELECT CAST(Col4 AS int) AS Beds FROM Universal WHERE Tenant=17 AND Table=0 AND Col3= State Michael Zenker Folie 14
Pivot Table Layout entweder eine Tabelle mit flexiblen Datentyp VARCHAR; besser für jeden Datentyp eine Tabelle (erspart Casting) + sehr gute Konsolidierung und Erweiterungsmöglichkeiten (ohne DDL) + keine NULL-Werte + gut geeignet für selektives Lesen weniger Spalten - viel Meta-Daten-Overhead - viele Joins zur Rekonstruktion der logischen (Mandanten) Tabellen (komplexe QTL) Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Query Transformation SELECT Beds FROM (SELECT s.str. AS Hospital, i.int AS Beds FROM Pivot str s, Pivot int i WHERE s.tenant = 17 AND i.tenant = 17 AND s.table = 0 AND s.col = 2 AND i.table = 0 AND i.col=3 And s.row = i.row) AS Account 17 WHERE Hospital= State Michael Zenker Folie 15
Chunk Table Layout ähnlich Pivot-Table; unterteilt logische Tabellen in Chunks (häufig zusammen auftretende Attribute werden gruppiert) Mehrer Chunks bilden eine Row + sehr gute Konsolidierung und Erweiterungsmöglichkeiten (ohne DDL) + weniger Joins als Pivot-Table + guter Kompromiss zwischen Universal und Pivot Table Layout (höhere Flexibilität) - viel Meta-Daten-Overhead - komplexere QTL auf Kosten von Flexibilität (kein direktes Mapping beim Auflösen der Spaltennamen wie bei Pivot Table Layout ) Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Query Transformation SELECT Beds FROM (SELECT Str1 AS Hospital, Int1 AS Beds FROM Chunk int str WHERE Tenant = 17 AND Table = 0 AND Chunk = 1) AS Account 17 WHERE Hospital= State Michael Zenker Folie 16
Chunk Folding Kombination aus Extension- und Chunk Table Layout speichert häufig vorkommende Attribute in gewöhnlichen Tabellen und den Rest in Chunk Tables Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques + Nachteile der beiden Ansätze reduziert (weniger QTL, weniger Tabellen) + sehr gute Konsolidierung und Erweiterbarkeit + gute Performance Meta-Daten-Overhead Quelle: Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques Query Transformation SELECT Beds FROM (SELECT Str1 AS Hospital, Int1 AS Beds FROM Chunk Row WHERE Tenant = 17 AND Table = 0 AND Chunk = 0) AS Account 17 WHERE Hospital= State Michael Zenker Folie 17
Vergleich der Schemata Private Table Basic Table Erweiterbarkeit Konsolidierung QTL- Aufwand Meta- Daten besondere Vorteile/Nachteile + -- ++ ++ - fehlende Konsolidierung -- ++ ++ ++ - fehlende Erweiterbarkeit Extension - Konsolidierung nur + o o + Table teilweise XML Table ++ ++ -- ++ - nicht von allen Systemen unterstüzt - z.t. schlechte Performance Universal Table ++ ++ - -- - keine Indizierung - viele Null-Werte Pivot Table ++ ++ -- -- - keine Null-Werte - viele Joins Chunk Table ++ ++ - - - nur eine Tabelle Chunk Folding ++ ++ - o - gute Kompromisslösung Michael Zenker Folie 18
Agenda Einführung und Motivation Vorstellung und Bewertung verschiedener Ansätze für flexible Schemata Beispiel: die Force.com-Architektur Michael Zenker Folie 19
Was ist Force.com Bestandteil von salesforce.com: Platform as a Service (PaaS) für SaaS Umgebung zum Erstellen und Betreiben von SaaS-Anwendungen Entwicklung Web-basierter Geschätfsanwendungen (und betreiben auf salesforce.com Cloudanbieter für CRM-Sofware ) Entwickelte applications können über Marktplatz AppExchange vertrieben werden (z.t. kostenlos) Entwicklungswerkzeuge und Programmierumgebung in bekannten Programmiersprachen oder Java-ähnlichem Apex Mehr als 47.000 Kunden (Stand: 2008) Metadaten-Architektur Michael Zenker Folie 20
Metadaten-Architektur Komponenten (Formulare, Berichte, Tabellen, Zugangsrechte, etc.) abstrakt in Form von Metadaten gehalten virtuelle Anwendungskomponenten werden durch die Runtime-Engine aus Metadaten erstellt Quelle: The Force.com Multitenant Architecture Michael Zenker Folie 21
Datenbankschema Tabellendefinition als Metadaten (Daten über die Daten selbst) beschrieben Datenhaltung aufgebaut aus einer Menge von Metadaten-, Daten- und Pivottabellen Quelle: The Force.com Multitenant Architecture Michael Zenker Folie 22
Objects-, Fields- und Datatable Metadaten-Tabellen: Beschreibung der Tabellen (keine Einordnung in vorgestellte Schemata) Objects-Table: Metadaten beschreiben Tabellen einer Organisation für die Anwendung Fields-Table: Metadaten beschreiben Spalten bzw. Attribute der Tabellen Data-Table: Universal Table Layout (alle Spalten vom Typ VARCHAR) Funktion zum Konvertieren der Datentypen (z.b. TO_NUMBER) Tatsächliche Daten der Mandanten beliebige Anpassung der Spalten (zulassen NULL-Werte, Integritätsregeln, etc.) Quelle: The Force.com Multitenant Architecture Michael Zenker Folie 23
Pivottables I Clobs-Table: für jede Row eine Attribut mit viel Text (bis zu 32.000 Zeichen) Index-Table: für schnellen Zugriff auf Rows (Nicht praktikabel für universalen Spalten in Data-Table, wegen unterschiedlichen Datentypen und NULL-Werte) Quelle: The Force.com Multitenant Architecture UniqueFields Table: für Attribute die keine Duplikate enthalten dürfen (Force.com gibt entsprechende Fehlermeldung falls vorhandener Wert eingefügt werden soll) Michael Zenker Folie 24
Pivottables II Relationships-Table: Optimierung von Joins; Wahrung referentieller Integrität selbst durch sog. relationship - Datentypen Quelle: The Force.com Multitenant Architecture FallbackIndex-Table: beinhaltet Namen aller Objekte für sog. fall-back Suchen (2. Suchmechanismus, falls externe search engine ausgelastet/nicht verfügbar) NameDenorm-Table: enthält ObjID und Name jeder Objekt-Instanz für Verlinkungen von Objekt-Referenzierungen History Tracking-Table: Speicherung von änderungsrelevanten Informationen der Daten für jedes Feld (alte und neue Werte, Datum, etc.) Michael Zenker Folie 25
Individualisierung/Anpassungsmöglichkeiten viele Anpassungen mit Zeigen-und-Klicken-Anpassungstools Komplexere Anpassungen mit Toolkits für gängige Programmiersprachen (Jave, C++, etc.) eigene Programmiersprache Apex (javaähnlich mit Einbindung von DB- Anweisungen) Michael Zenker Folie 26
Zusammenfassung um Kosten zu Senken Konsolidierung notwendig trotz Konsolidierung Erweiterbarkeit gewährleisten Flexible Schemata bei allen Layouts sowohl Vor- als auch Nachteile Chunk Folding sehr gute Kompromisslösung Trotz erheblicher Nachteile Universal Table oft in Praxis eingesetzt (vor allem in Verbindung mit anderen Layouts) Force.com Force.com äußerst erfolgreich: Force.com ist erste und zur Zeit ausgereifteste, universelle, mehrmandantenfähige Entwicklungsplattform für Internet-Anwendungen auf dem Markt. (Stand: 2008, The Force.com Multitenant Architecture) Michael Zenker Folie 27
Quellen Aulbach S., Grust T., Jacobs D., Kemper A., Rittinger J. (2008): Multi- Tenant Databases for Software as a Service: Schema-Mapping Techniques Aulbach S., Jacobs D., Kemper A., Seibold M. (2009): A Comparison of Flexible Schemas for Software as a Service Force.com (2008): The Force.com Multitenant Architecture www.salesforce.com (Abruf: Juni 2010) Jacob D., Stefan Aulbach S. (2009): Ruminations on Multi-Tenant Databases O. Günther, W. Karl, R. Lienhart, K. Zeppenfeld (2010): Cloud Computing: Web-basierte dynamische IT-Services Michael Zenker Folie 28
Fragen? Danke für Ihre Aufmerksamkeit!