Prevayler
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

Prevayler PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on
  • Presentation posted in: General

Prevayler. Agenda. Einführung Persistenzhaltungs-Konzepte Einsatzarten von Datenbanken Object Prevalence Konzepte Prevayler Konzepte Datensicherheit Performanz Fazit. Einführung. Persistenzhaltung für objektorientierte Programme Verwendung von RDBMS und O/R-Mapping

Download Presentation

Prevayler

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Prevayler

Prevayler


Agenda

Agenda

  • Einführung

  • Persistenzhaltungs-Konzepte

    • Einsatzarten von Datenbanken

  • Object Prevalence

    • Konzepte

  • Prevayler

    • Konzepte

    • Datensicherheit

    • Performanz

  • Fazit


Einf hrung

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


Persistenzhaltung einsatzarten von datenbanken

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


Persistenzhaltung einsatzarten von datenbanken1

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


Persistenzhaltung einsatzarten von datenbanken2

Persistenzhaltung – Einsatzarten von Datenbanken

  • Integration Database [Fowler]

    • Wird von mehrerenApplikationen genutzt

    • Dient der Daten-Integrationzwischen 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


Persistenzhaltung einsatzarten von datenbanken3

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


Object prevalence

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


Object prevalence1

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


Object prevalence2

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


Prevayler1

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


Prevayler konzepte

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


Prevayler konzepte1

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 Snapshotsauf Datenstruktur-statt Objekt-/Page-Ebene

      Gegensatz zu RDBMS


Prevayler konzepte2

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;

}


Prevayler konzepte3

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 {

publicvoid executeOn(

Object prevalentSystem,

Date executionTime);

}


Prevayler datensicherheit

Prevayler – Datensicherheit

  • Snapshots

    • Gesamter Objektbaum wird serialisiert

      • Standard: Java Object Serialization

      • Alle Objekte, nicht nur ‚dirty‘ Objekte werden serialisiert

    • Ablauf

      • Objektbaum sperren

      • Objektbaum serialisieren und speichern

      • Objektbaum entsperren

      • Snapshot als vollständig markieren

      • 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


Prevayler datensicherheit1

Prevayler – Datensicherheit

  • Transaktionsverarbeitung

    • Ablauf

      • Test auf Serialisierbarkeit des Transaction-Objekts

      • Approval durch Censor

      • Eintrag in Transaction Log

      • 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


Prevayler datensicherheit2

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


Prevayler datensicherheit3

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


Prevayler datensicherheit4

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


Prevayler performanz

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


Prevayler performanz1

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


Prevayler schemaevolution

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:

      • Snapshot mit alten Klassen laden

      • Datenstruktur mit neuen Klassen erzeugen

      • Snapshot erzeugen

         Sehr aufwändig, erfordert Downtime


Fazit

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

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


  • Login