Johannes Passing, 17.01.2006 Prevayler. HPI, Seminar Advanced Database Technology - WS2005/2006 2...

Johannes Passing, 17.01.2006

Prevayler

HPI, Seminar Advanced Database Technology - WS2005/2006 2

Agenda

EinführungPersistenzhaltungs-Konzepte

Einsatzarten von DatenbankenObject Prevalence

KonzeptePrevayler

Konzepte

Datensicherheit

PerformanzFazit


Einführung

Persistenzhaltung für objektorientierte Programme

Verwendung von RDBMS und O/R-MappingObjektmodell und relationales Modell

sehr unterschiedlichMapping idR nicht transparentMapping 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

Foo

«interface»IBar

Bar

1 *

O/R-Mapping

ACID

ACIDFoo

«interface»IBar

Bar

1 *


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

Applikation



Application Database (2)

Interoperabilität hat geringen StellenwertIn-Process-Implementierung möglich

Kein externer Zugriff notwendig (ODBC etc)

Typische Anwendungen3 Schichten-Systeme

Datenbank durch Applikation verkapselt (EJB, COM+, WebServices etc)

Desktop-Anwendungen

Kein externer Zugriff notwendig

Datenbank wird an Applikation angepasstDatenbank ist Mittel, Applikations-Daten persistent zu halten



Integration Database [Fowler]

Wird von mehrerenApplikationen genutzt

Dient der Daten-Integrationzwischen Applikationen

Schema muss allen Applikationen gerecht werdenGenerelles, oftmals komplexes Schema

Hohe Schemastabilität notwendig

Hoher Stellenwert von Konsistenzsicherung auf Datenbank-Ebene

Einsatz von Trigger, Constraints, Stored Procedures

Applikation Applikation Applikation



Integration Database (2)

Hoher Stellenwert von InteroperabilitätNetzwerkzugriff erforderlich

Meist separate Maschine für Datenbank

Schnittstellen wie ODBC, JDBC, OLEDB notwendig

Typische AnwendungenERP-Systeme

OLTP-Systeme

Applikation wird an Datenbank angepasstApplikation ist Mittel zum Zugriff auf die Datenbank und deren

Modifizierung


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ührtGründer des Prevayler-Projektes


Object PrevalenceKonzepte

Alle Daten werden in einer einzigen Datenstruktur abgelegt

Gesamte Datenstruktur befindet sich im ArbeitsspeicherPrämissen:

Es steht stets genug Arbeitsspeicher zur VerfügungRAM-Preise sinken stetigDurch 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


Object Prevalence

Konzepte (2)

Periodischer Snapshot der DatenstrukturAbspeicherung auf persistentem Medium

Zugriff auf Datenstruktur geschieht indirekt Command-Pattern

Write Ahead Log für modifizierende ZugriffeLog beinhaltet Modifizierungen seit letztem Snapshot

Abspeicherung auf persistentem Medium

Startup/RecoveryEinlesen des letzten Snapshots

Log wird eingespielt


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-Angaben9000 mal schnellere Abfragen als Oracle (über JDBC)

3000 mal schnellere Abfragen als MySQL (über JDBC)

kein TPC-C o.ä. verfügbar


Prevayler – Konzepte

Datenstruktur

Objektbaum als Datenstruktur Keine Einschränkung bzgl. Implementierung

Enthält sämtliche Business-Objekte

Es existiert ein einziges Wurzel-ObjektAlle weiteren Objekte sind über Wurzel-Objekt erreichbar

wird als PrevalentSystem bezeichnet

Objektbaum muss serialisierbar seinImplementierung von java.io.Serializable oder java.io.Externalizable

Zur Snapshot-Erzeugung



Datenzugriff

Zugriffe nur durch Command-Objekte Lesen: Query-Objekt

Schreiben: Transaction-Objekt

Nur programmatischer Zugriff möglichKeine Query Language o.ä.

Prevayler ‚weiß‘ nicht, was Transactions/Queries tatsächlich tun

Synchronisation und Snapshotsauf Datenstruktur-statt Objekt-/Page-Ebene

Gegensatz zu RDBMS

Command (DML)

Pages

RDBMS

Objects

Command (Transaction)

Prevayler



Datenzugriff (2)

Alle Zugriffe werden seriell ausgeführtWährend Ausführung wird gesamte Datenstruktur gesperrt

Lesender ZugriffImplementierung 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;

}



Datenzugriff (3)

Modifizierender ZugriffImplementierung 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);

}


Prevayler – DatensicherheitSnapshots

Gesamter Objektbaum wird serialisiertStandard: Java Object SerializationAlle Objekte, nicht nur ‚dirty‘ Objekte werden serialisiert

Ablauf1. Objektbaum sperren2. Objektbaum serialisieren und speichern3. Objektbaum entsperren4. Snapshot als vollständig markieren5. Transaction Log trunkieren, alte Snapshots löschen (optional)

Downtime während Serialisierung Kann durch Replikation vermieden werden

Periodische DurchführungIntervalldauer bestimmt Downtime und Recovery-Dauer


Prevayler – Datensicherheit

Transaktionsverarbeitung

Ablauf1. Test auf Serialisierbarkeit des Transaction-Objekts

2. Approval durch Censor

3. Eintrag in Transaction Log

4. Aufruf Transaction.executeOn()

Transaction-Command gilt als atomarAtomaritä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 werfenErgebnis hängt von verwendetem Censor ab



Transaktionsverarbeitung – Censors

Censors‚Genehmigen‘ Commands (Approval) vor Ausführung

LiberalTransactionCensorKeine Prüfung der Commands

Commands werden sofort auf Haupt-Datenstruktur ausgeführt

Wenn Fehler auftritt, muss dies von Command behandelt werden – sonst: inkonsistente Datenstruktur



Transaktionsverarbeitung – Censors (2)

StrictTransactionCensorCommand 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



ACID

Durability durch Snapshots und Logs sichergestellt

Isolation durch serielle Command-Ausführung

Entwickler muss Atomarität von Commands sicherstellenGgf. durch Kompensation

Sonst: Gefahr inkonsistenter Datenstruktur

Entwickler muss Konsistenz der Datenstruktur sicherstellenVor und nach erforgreicher/fehlerhafter Ausführung eines Commands muss Datenstruktur konsistent sein

Fehlerhafte Command-Implementierung kann gesamte Datenkonsistenz zerstören


Prevayler – Performanz

Allgemein

Vergleich mit RDBMS schwierigRDBMS 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 TransactionsProblematisch bei stark nebenläufigen Systemen

Problematisch auf SMP-Systemen

Weitere CPUs werden nicht optimal ausgenutzt

Problematisch bei langen TransaktionenLange Wartezeit auf Lock


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 notwendigWriteAhead-Logging

Bei StrictTransactionCensor:Zusätzlicher Overhead

Rollbacks teuer

Etwa gleiche Größenordnung wie RDBMS


Prevayler – SchemaevolutionSchemaevolution

Werden Klassen ausgetauscht, müssen diese mit Snapshot bzw. Transaction Log kompatibel sein

Sonst: Deserialisierung nicht mehr möglichBeispiel: Löschen/Hinzufügen eines Attributs

Einschränkungen hängen von Serialisierungsverfahren abStandard: Java Object Serialization

Sehr striktDurch serialVersionUID, transient fields, SerialPersistentFields und Externalizable lässt sich Serialisierung beeinflussenAbwärtskompatibilität häufig nicht realisierbar

Workaround:1. Snapshot mit alten Klassen laden2. Datenstruktur mit neuen Klassen erzeugen3. Snapshot erzeugen Sehr aufwändig, erfordert Downtime


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


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 http://radio.javaranch.com/frank/2004/12/27/1104152030000.html (10.11.2005)

[Evans] Evans, Huw: Why Object Serialization is Inappropriate for Providing Persistence in Java, Department of Computing Science, University of Glasgow

[Fowler] Fowler, Martin: Design Blikihttp://www.martinfowler.com/bliki/design.html (19.12.2005)

[Melton] Melton, Hayden: An Evaluation of Object Prevalence, Dept. of Electrical and Electronic Engineering, University of Auckland

[ON] Obermayer, Nathanael: ACID gratis, iX Ausgabe 02.2004

[Prevayler] Prevayler Homepage, http://www.prevayler.org

[Spille] Spille, Mike: Prevayler Revisitedhttp://www.pyrasun.com/mike/mt/archives/2004/12/25/15.02.00/index.html (10.11.2005)

[PT] Printezis, Tony: Garbage Collection in the Java HotSpot Virtual Machine, DevXhttp://www.devx.com/Java/Article/21977/0/ (10.01.2006)

[WE] Wolff, Eberhard: Die schnellste Datenbank der Welt, Java Magazin Ausgabe 06.2004

Johannes Passing, 17.01.2006 Prevayler. HPI, Seminar Advanced Database Technology - WS2005/2006 2...

Documents

Transcript of Johannes Passing, 17.01.2006 Prevayler. HPI, Seminar Advanced Database Technology - WS2005/2006 2...