1 / 25

Prevayler

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

karleigh-walls
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prevayler

  2. Agenda • Einführung • Persistenzhaltungs-Konzepte • Einsatzarten von Datenbanken • Object Prevalence • Konzepte • Prevayler • Konzepte • Datensicherheit • Performanz • Fazit

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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; }

  15. 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); }

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

More Related