prevayler
Download
Skip this Video
Download Presentation
Prevayler

Loading in 2 Seconds...

play fullscreen
1 / 25

Prevayler - PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Prevayler' - karleigh-walls


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
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
ad