Johannes Passing, Prevayler

HPI, Seminar Advanced Database Technology - WS2005/ Agenda Einführung Persistenzhaltungs-Konzepte Einsatzarten von Datenbanken Object Prevalence Konzepte Prevayler Konzepte Datensicherheit Performanz Fazit

HPI, Seminar Advanced Database Technology - WS2005/ Einführung Persistenzhaltung für objektorientierte Programme Verwendung von RDBMS und O/R-Mapping Objektmodell und relationales Modell sehr unterschiedlich Mapping idR nicht transparent Mapping aufwändig und teuer Ideal: Objektmodell mit Geschäftsobjekten Objekte besitzen ACID-Eigenschaften Objekt-Implementierung entspricht der transienter Objekte Kein Mapping o.ä. notwendig Einfachere und schnellere Entwicklung

HPI, Seminar Advanced Database Technology - WS2005/ Persistenzhaltung – Einsatzarten von Datenbanken Application Database [Fowler] Exklusiv von einer einzigen Applikation verwendet Schema ist auf spezifische Anforderungen angepasst Evolutionäre Schemaentwicklung möglich Konsistenz kann von Applikation sichergestellt werden Trigger, Constraints etc. nicht unbedingt erforderlich Einfach verständliches Schema

HPI, Seminar Advanced Database Technology - WS2005/ Persistenzhaltung – Einsatzarten von Datenbanken Application Database (2) Interoperabilität hat geringen Stellenwert In-Process-Implementierung möglich Kein externer Zugriff notwendig (ODBC etc) Typische Anwendungen 3 Schichten-Systeme Datenbank durch Applikation verkapselt (EJB, COM+, WebServices etc) Desktop-Anwendungen Kein externer Zugriff notwendig Datenbank wird an Applikation angepasst Datenbank ist Mittel, Applikations-Daten persistent zu halten

HPI, Seminar Advanced Database Technology - WS2005/ Persistenzhaltung – Einsatzarten von Datenbanken Integration Database [Fowler] Wird von mehreren Applikationen genutzt Dient der Daten-Integration zwischen Applikationen Schema muss allen Applikationen gerecht werden Generelles, oftmals komplexes Schema Hohe Schemastabilität notwendig Hoher Stellenwert von Konsistenzsicherung auf Datenbank-Ebene Einsatz von Trigger, Constraints, Stored Procedures

HPI, Seminar Advanced Database Technology - WS2005/ Persistenzhaltung – Einsatzarten von Datenbanken Integration Database (2) Hoher Stellenwert von Interoperabilität Netzwerkzugriff erforderlich Meist separate Maschine für Datenbank Schnittstellen wie ODBC, JDBC, OLEDB notwendig Typische Anwendungen ERP-Systeme OLTP-Systeme Applikation wird an Datenbank angepasst Applikation ist Mittel zum Zugriff auf die Datenbank und deren Modifizierung

HPI, Seminar Advanced Database Technology - WS2005/ Object Prevalence Konzept, In-Memory Datenstrukturen mit ACID-Semantik zu versehen Erstmals 1987 von A. D. Birrell, M. B. Jones und E. P. Wobber in A Simple and Efficient Implementation for Small Databases veröffentlicht Name Object Prevalence von Klaus Wuestefeld eingeführt Gründer des Prevayler-Projektes

HPI, Seminar Advanced Database Technology - WS2005/ Object Prevalence Konzepte Alle Daten werden in einer einzigen Datenstruktur abgelegt Gesamte Datenstruktur befindet sich im Arbeitsspeicher Prämissen: Es steht stets genug Arbeitsspeicher zur Verfügung RAM-Preise sinken stetig Durch 64 Bit-Maschinen kann Adressknappheit umgangen werden In-process Ausführung Application Database Gegensatz zu RDBMS-Konzept – RDBMS ist so konzipiert, dass nicht alle Daten im Arbeitsspeicher gehalten werden müssen

HPI, Seminar Advanced Database Technology - WS2005/ Object Prevalence Konzepte (2) Periodischer Snapshot der Datenstruktur Abspeicherung auf persistentem Medium Zugriff auf Datenstruktur geschieht indirekt Command-Pattern Write Ahead Log für modifizierende Zugriffe Log beinhaltet Modifizierungen seit letztem Snapshot Abspeicherung auf persistentem Medium Startup/Recovery Einlesen des letzten Snapshots Log wird eingespielt

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler Projekt Prevayler Gegründet durch Klaus Wuestefeld Erste öffentliche Implementierung des Object Prevalence- Konzeptes Konzept nicht grundsätzlich neu, aber erstmals universell implementiert Implementiert in Java Open Source (BSD Lizenz) Erstes Release 2001 (noch unter LGPL) Inzwischen existieren weitere Implementierungen neben Prevayler Bekannt durch Performanz-Angaben 9000 mal schnellere Abfragen als Oracle (über JDBC) 3000 mal schnellere Abfragen als MySQL (über JDBC) kein TPC-C o.ä. verfügbar

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Konzepte Datenstruktur Objektbaum als Datenstruktur Keine Einschränkung bzgl. Implementierung Enthält sämtliche Business-Objekte Es existiert ein einziges Wurzel-Objekt Alle weiteren Objekte sind über Wurzel-Objekt erreichbar wird als PrevalentSystem bezeichnet Objektbaum muss serialisierbar sein Implementierung von java.io.Serializable oder java.io.Externalizable Zur Snapshot-Erzeugung

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Konzepte Datenzugriff Zugriffe nur durch Command-Objekte Lesen: Query-Objekt Schreiben: Transaction-Objekt Nur programmatischer Zugriff möglich Keine Query Language o.ä. Prevayler weiß nicht, was Transactions/Queries tatsächlich tun Synchronisation und Snapshots auf Datenstruktur- statt Objekt-/Page-Ebene Gegensatz zu RDBMS

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Konzepte Datenzugriff (2) Alle Zugriffe werden seriell ausgeführt Während Ausführung wird gesamte Datenstruktur gesperrt Lesender Zugriff Implementierung der Query-Schnittstelle Zugriffe werden nicht protokolliert Query-Objekte dürfen niemals Modifikationen ausführen public interface Query { public Object query( Object prevalentSystem, Date executionTime) throws Exception; }

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Konzepte Datenzugriff (3) Modifizierender Zugriff Implementierung der Transaction-Schnittstelle (bzw. TransactionWithQuery) Transaction-Objekt muss serialisierbar sein Wird vor Ausführung in Transaction Log serialisiert Verhalten muss deterministisch sein Während Startup/Recovery werden Commands erneut ausgefüht Externe Ressourcen dürfen idR nicht verwendet werden Prevayler-Zeit muss statt Systemzeit verwendet werden public interface Transaction extends java.io.Serializable { public void executeOn( Object prevalentSystem, Date executionTime); }

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Datensicherheit Snapshots Gesamter Objektbaum wird serialisiert Standard: Java Object Serialization Alle Objekte, nicht nur dirty Objekte werden serialisiert Ablauf 1.Objektbaum sperren 2.Objektbaum serialisieren und speichern 3.Objektbaum entsperren 4.Snapshot als vollständig markieren 5.Transaction Log trunkieren, alte Snapshots löschen (optional) Downtime während Serialisierung Kann durch Replikation vermieden werden Periodische Durchführung Intervalldauer bestimmt Downtime und Recovery-Dauer

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Datensicherheit Transaktionsverarbeitung Ablauf 1.Test auf Serialisierbarkeit des Transaction-Objekts 2.Approval durch Censor 3.Eintrag in Transaction Log 4.Aufruf Transaction.executeOn() Transaction-Command gilt als atomar Atomarität muss durch Command selbst sichergestellt werden Bei Fehler müssen alle Modifikationen rückgängig gemacht werden Aufwändig bei kompositen Aktionen Transaction.executeOn kann Exception werfen Ergebnis hängt von verwendetem Censor ab

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Datensicherheit Transaktionsverarbeitung – Censors Censors Genehmigen Commands (Approval) vor Ausführung LiberalTransactionCensor Keine Prüfung der Commands Commands werden sofort auf Haupt-Datenstruktur ausgeführt Wenn Fehler auftritt, muss dies von Command behandelt werden – sonst: inkonsistente Datenstruktur

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Datensicherheit Transaktionsverarbeitung – Censors (2) StrictTransactionCensor Command wird doppelt ausgeführt Command wird zunächst auf Kopie der Datenstruktur (Food Taster) ausgeführt Wenn erfolgreich: Ausführung auf Haupt-Datenstruktur Bei Fehler (Exception): Transaktion wird abgebrochen Kopie der Datenstruktur wird verworfen und neu erstellt Sehr teure Operation Konsequenz Höhere Konsistenz-Sicherheit Erhöhter Speicherbedarf und Ausführungszeit

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Datensicherheit ACID Durability durch Snapshots und Logs sichergestellt Isolation durch serielle Command-Ausführung Entwickler muss Atomarität von Commands sicherstellen Ggf. durch Kompensation Sonst: Gefahr inkonsistenter Datenstruktur Entwickler muss Konsistenz der Datenstruktur sicherstellen Vor und nach erforgreicher/fehlerhafter Ausführung eines Commands muss Datenstruktur konsistent sein Fehlerhafte Command-Implementierung kann gesamte Datenkonsistenz zerstören

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Performanz Allgemein Vergleich mit RDBMS schwierig RDBMS meist out-of-process Verwendung von ODBC/JDBC/etc Verfügbare Performanz-Messungen beziehen sich auf 1- Prozessor-Maschinen Flaschenhals Synchronisation Serielle Ausführung von Queries und Transactions Problematisch bei stark nebenläufigen Systemen Problematisch auf SMP-Systemen Weitere CPUs werden nicht optimal ausgenutzt Problematisch bei langen Transaktionen Lange Wartezeit auf Lock

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Performanz Lesender Zugriff Kein Zugriff auf persistenten Speicher notwendig Alle Daten befinden sich in Arbeitsspeicher Bei sinnvollem Einsatz von Hashtables etc sehr schneller Zugriff Minimaler Overhead Kann Größenordnungen schneller sein als RDBMS Modifizierender Zugriff Zugriff auf persistenten Speicher notwendig WriteAhead-Logging Bei StrictTransactionCensor: Zusätzlicher Overhead Rollbacks teuer Etwa gleiche Größenordnung wie RDBMS

HPI, Seminar Advanced Database Technology - WS2005/ Prevayler – Schemaevolution Schemaevolution Werden Klassen ausgetauscht, müssen diese mit Snapshot bzw. Transaction Log kompatibel sein Sonst: Deserialisierung nicht mehr möglich Beispiel: Löschen/Hinzufügen eines Attributs Einschränkungen hängen von Serialisierungsverfahren ab Standard: Java Object Serialization Sehr strikt Durch serialVersionUID, transient fields, SerialPersistentFields und Externalizable lässt sich Serialisierung beeinflussen Abwärtskompatibilität häufig nicht realisierbar Workaround: 1.Snapshot mit alten Klassen laden 2.Datenstruktur mit neuen Klassen erzeugen 3.Snapshot erzeugen Sehr aufwändig, erfordert Downtime

HPI, Seminar Advanced Database Technology - WS2005/ Fazit Einsatz Als Application Database für moderate Datenmengen Vornehmlich Lese-Zugriff auf Daten Verwendung Keinerlei O/R-Mapping notwendig Schnelle Entwicklung Hohe Transparenz für Geschäfts-Objekte Jedoch geringe Transparenz bei Datenzugriff (Query/Transaction-Modell proprietär) Performanz Hohe Lese-Performanz Nicht für stark nebenläufige oder SMP-Systeme ausgelegt Datensicherheit Erfordert Sorgfalt vom Entwickler Erreicht nicht die Sicherheit und Robustheit moderner RDBMS

HPI, Seminar Advanced Database Technology - WS2005/ Referenzen [RJW] Birrell, Andrew; Jones, Michael; Wobber, Edward: A Simple and Efficient Implementation for Small Databases, digital Systems Reseach Center, 1987 [Carver] Carver, Frank: Thoughts about Prevayler and Databases ( ) [Evans] Evans, Huw: Why Object Serialization is Inappropriate for Providing Persistence in Java, Department of Computing Science, University of Glasgow [Fowler] Fowler, Martin: Design Bliki ( ) [Melton] Melton, Hayden: An Evaluation of Object Prevalence, Dept. of Electrical and Electronic Engineering, University of Auckland [ON] Obermayer, Nathanael: ACID gratis, iX Ausgabe [Prevayler] Prevayler Homepage, [Spille] Spille, Mike: Prevayler Revisited ( ) [PT] Printezis, Tony: Garbage Collection in the Java HotSpot Virtual Machine, DevX ( ) [WE] Wolff, Eberhard: Die schnellste Datenbank der Welt, Java Magazin Ausgabe