Python. Quetsch deine Objekte nicht in Tabellen - leg sie in eine Objektdatenbank. gocept gmbh & co. kg. ZODB eine native Objektdatenbank für.

Transkript

1 Quetsch deine Objekte nicht in Tabellen - leg sie in eine Objektdatenbank. gocept gmbh & co. kg November 16, 2010

2 /me, Software-Entwickler Mitgründer von gocept (Zope-Beratung, -Entwicklung, -Hosting) Kernentwickler verschiedener Zope-Projekte (inkl. Zope Toolkit und ZODB) Vorsitzender der DZUG, Vorstandsmitglied der Zope Foundation

3 Inhalt

4 ZODB ist die Zope Object Database eine Objektdatenbank.

5 Einführung Objekt-orientierte Anwendungen arbeiten mit Objekten. Diese Objekte gehen verloren, wenn das Programm beendet wird. Ein Programm muss die Daten seiner Objekte vor Beendigung speichern. Objekte müssen von einem Programm, beim nächsten Start, neu erzeugt und in den alten Zustand versetzt werden.

6 Einführung Die ZODB automatisiert den Vorgang des Speicherns von Objektzuständen über die Lebensdauer des Prozesses hinaus und kümmert sich darum Objekte wiederzubeleben. Anwendungsentwickler erstellen und ändern Objekte wie bisher, aber ohne sich groß darum kümmern zu müssen wie ihre Daten physisch gespeichert und geladen werden.

7 Beispiel Angenommen, wir haben folgende Klasse: c l a s s Account ( P e r s i s t e n t ) : def i n i t ( s e l f ) : s e l f. b a l a n c e = 0. 0 def d e p o s i t ( s e l f, amount ) : a s s e r t amount > 0 s e l f. b a l a n c e += amount def cash ( s e l f, amount ) : a s s e r t amount < s e l f. b a l a n c e s e l f. b a l a n c e = amount (Demo im interaktiven Interpreter, example1)

8 Beispiel Rückblick Was ist im Beispiel passiert? Die Datenbank hat ein Dictionary-artiges Wurzel-Objekt. Wir haben ein neues Objekt instantiiert und in der Wurzel gespeichert. transaction.commit() macht Änderungen persistent. transaction.abort() macht Änderungen rückgängig so als wenn der Prozess ohne commit beendet worden wäre. Erinnerung: ZODB ist eine kein RDBMS hinter dem Vorhang.

9 Beispiel Boilerplate Im Beispiel wurden ein paar Sachen versteckt. Das Objekt root war einfach da. Hier ist der Code: from ZODB.DB import DB c o n n e c t i o n = DB( /tmp/ example1. f s ). open ( ) r o o t = c o n n e c t i o n. r o o t ( )

10 Beispiel Boilerplate Der Code benutzt eine verkürzte Schreibweise. Was wirklich passiert: from ZODB. F i l e S t o r a g e import F i l e S t o r a g e from ZODB.DB import DB s t o r a g e = F i l e S t o r a g e ( /tmp/ example1. f s ) db = DB( /tmp/ example1. f s ) c o n n e c t i o n = db. open ( ) r o o t = c o n n e c t i o n. r o o t ( )

11 Architektur Wir brauchen 6 Zeilen Code um die ZODB zu initialisieren. Warum? Zwei Aspekte: Datenbankarchitektur Transaktionsmanagement

12 Architektur Datenbankarchitektur Die Datenbank besteht aus 3 Elementen: einem Wurzelobjekt, einer Datenbank und einem Speicher. Das Wurzelobjekt ist der Einstiegspunkt in die Datenbank, von dem aus alle Objekte navigierbar sind. Navigation erfolgt durch Interaktion mit den Objekten: durch Attributzugriff oder Methodenaufruf. Die Datenbank enthält das Wurzelobjekt und stellt die logische Schicht des DBMS-Modells dar: Objekte werden geladen und gespeichert und in serialisierter Form an die darunterliegende Schicht geleitet. Der Speicher (Storage) ist die physische DBMS-Schicht und speichert die serialisierten Daten auf einem Medium.

13 Architektur Transaktionsmanagement Die Architektur der Transaktionen definiert zwei Elemente: eine Transaktion und eine Datenbankverbindung. Das Wurzelobjekt wird nicht direkt aus der Datenbank geholt. Wir brauchen zuerst eine Datenbankverbindung deren root() -Methode wir aufrufen. Eine Verbindung ist mit einer Transaktion assoziiert und jedes Objekt, das aus dieser Verbindung geladen wird, nimmt an dieser Transaktion teil. Hinweis: es gibt noch einige interne Mechanismen die die Transaktionskoordination über mehrere Datenbanken erlaubt.

14 Funktionsübersicht Beliebige -Objekte speicherbar, aber Spezialtypen einige Anwendungsfälle (BTrees), nur wenige Ausnahmen (sockets, files) Voll ACID-kompatible Transaktionen Verschiedene Storages: FileStorage, MappingStorage, DemoStorage, ZEO, RelStorage,... Unterstützung Datensatztransformation (Z.B. Kompression) Savepoints innerhalb von Transaktionen Inkrementelle Backups Undo / Time Travel Application-level conflict resolution Clustering / Fan-out-Szenarien Object-Caching

15 Anwendungsentwicklung Schauen wir uns etwas genauer an, wie man mit der ZODB arbeitet: Installation Konfiguration Persistente objects Transaktions-API Tests

16 Installation Die ZODB ist als -Egg verfügbar und kann via PyPI installiert werden: $ e a s y i n s t a l l ZODB3... $ python >>> import ZODB

17 Konfiguration Wenn man Datenbanken über die API direkt aus -Code öffnet, machen wir unsere Anwendung von einer spezifischen Konfiguration abhängig: >>> from ZODB. F i l e S t o r a g e. F i l e S t o r a g e \... import F i l e S t o r a g e >>> s t o r a g e = F i l e S t o r a g e ( example. f s ) >>> from ZODB.DB import DB >>> d a t a b a s e = DB( s t o r a g e ) >>> c o n n e c t i o n = d a t a b a s e. open ( ) >>> c o n n e c t i o n. r o o t ( ) {}

18 Konfiguration Besser ist es, eine Konfigurationsdatei zu schreiben: <zodb> < f i l e s t o r a g e> path /tmp/ example. f s </ f i l e s t o r a g e> </ zodb> Und dann databasefromurl() zu benutzen: >>> from ZODB. c o n f i g import databasefromurl >>> db = databasefromurl (... / zodb. c o n f ) >>> c o n n e c t i o n = db. open ( ) >>> c o n n e c t i o n. r o o t ( ) {}

19 Persistente Objekte (Fast) jedes beliebige Objekt kann in der Datenbank gespeichert werden. Aber: Zustandsänderungen beliebiger Objekte werden von der Transaktion nicht automatisch bemerkt. Die Basisklasse Persistent bemerkt Änderungen und informiert die Transaktion. Klassen sollten von Persistent abgeleitet werden, wenn ihre Objekte veränderlich sind. Für Listen, Dictionaries, Sets und BTrees gibt es angepasste Implementierungen.

20 Persistente Objekte - Blobs Ein Speziallfall von nicht-serialisierbaren Objekten sind Dateien. Es gibt zwei klassische Ansätze Dateien in der ZODB zu speichern: Strings (ineffizient bzgl. Hauptspeicher) oder verlinkte Listen von Datenblöcken (ineffizient bzgl. Cache-Verhalten). Seit ZODB 3.8 gibt es Blobs, die ein natürliches API bzgl. Dateien erlauben. (Demo, example 2)

21 Transaktions-API Die Transaktions-API stellt 5 Methoden bereit: begin() commit() abort() doom() savepoint(optimistic=false)

22 Transaktionen Beginnen Jede Connection hat immer eine assoziierte Transaktion, selbst wenn wir begin nicht aufrufen. Bevor eine Anwendung anfängt Objekte zu verändern können wir explizit eine neue Transaktion anfordern (dadurch werden auch neue Änderungen sichtbar). Wenn bereits eine Transaktion besteht, wird diese abgebrochen. >>> t r a n s a c t i o n. b e g i n ( )

23 Transaktionen Committen Wenn alle unsere Operationen erfolgreich waren und wir die Ergebnisse zusammen dauerhaft speichern wollen, können wir unsere Transaktion committen: >>> t r a n s a c t i o n. commit ( )

24 Transaktionen Abbrechen Anstatt eine Transaktion zu comitten können wir sie auch abbrechen und dadurch alle Änderungen rückgängig machen: >>> r o o t [ banana ]. p r i c e 1. 2 >>> r o o t [ banana ]. p r i c e = 1. 5 >>> r o o t [ banana ]. p r i c e 1. 5 >>> t r a n s a c t i o n. a b o r t ( ) >>> r o o t [ banana ]. p r i c e 1. 2

25 Transaktionen Dooming Wenn wir eine Transaktion abbrechen sind sofort alle Änderungen weg. Manchmal will man sicherstellen, dass eine Transaktion nicht mehr committed werden kann, die Daten aber noch (zum Anzeigen von Fehlermeldungen) nicht verlieren. Die Funktion doom() erledigt genau das: >>> r o o t [ banana ]. p r i c e = 2. 0 >>> t r a n s a c t i o n. doom ( ) >>> r o o t [ banana ]. p r i c e 2. 0 >>> t r a n s a c t i o n. commit ( ) Traceback ( most r e c e n t c a l l l a s t ) :... DoomedTransaction >>> t r a n s a c t i o n. a b o r t ( )

26 Transaktionen Savepoints Transaktionen sind (per Definition) atomar. In einigen Situation (z.b. Stapelverarbeitung) ist es sinnvoll einige Daten am Stück zu verarbeiten, diesen Zustand zu halten, weitere Daten zu verarbeiten und ggfs. zu dem Zwischenergebnis zurückzukehren ohne den kompletten bisherigen Arbeitsstand zu verlieren oder zu speichern. Dabei helfen Savepoints. (Demo, example 1)

27 Undo Es gibt ZODB-Storages, die alte Revisionen speichern. Diese Storages haben ein API Undo und Redo auf Transaktionsebene: Die API sieht so aus: IDatabase.undoInfo() IDatabase.undoLog() IDatabase.undo()

28 Die ZODB kann an zwei Achsen skaliert werden: Transaktionen pro Zeiteinheit Anzahl Objekte in der Datenbank

29 Viele Transaktionen Viele Transaktionen sind hauptsächlich ein Problem von CPU-Zyklen und sync()-operationen. Zope Enterprise Objects (ZEO) sind eine Lösung: Sie stellen einen Netzwerkserver die ZODB bereit, der als virtueller Storage fungiert und mehrere -Prozesse mit der Anwendung auf die gleiche Datenbank zugreifen lässt. ZEO beinhaltet verteiltes Transaktionsmanagement, so dass die eigenen Anwendungen weiterhin auch mit anderen Transaktionssystemen integriert werden können.

30 Viele Objekte Viele Objekte handhaben zu können erfordert die Verwendung von Datenstrukturen, die effizient großen Kollektionen speichern und Möglichkeiten haben um Objekte abzufragen ohne alle Objekte der Kollektion zu materialisieren.

31 Große Kollektionen Die ZODB stellt verschiedene Formen von BTrees bereit, die wie Dictionaries (oder Listen oder Sets) arbeiten. Häufig verwendete Formen sind: IOBTree (Schlüssel sind Integer) und OOBTree (Schlüssel sind beliebige -Objekte). BTrees sind effizient, da das Laden eines Schlüssels aus der Kollektion nur O(logn) Operationen anfallen und nicht alle Objekte im Speicher sein müssen.

32 Objekte abfragen Hier hat die ZODB selbst keinen Mechanismus, erlaubt aber auf Basis von BTrees entsprechende Mechanismen zu bauen. Beispiele Implementationen: zope.index, zope.catalog. Der allgemeine Ansatz dieser Pakete ist, den Netzverbund von Objekten in eine Rechtecksform zu bringen, mit BTrees und Dokumentschlüssen effizient nach verschiedenen Gesichtspunkten zu indizieren und kombinierte Abfragen über verschiedene Indizes zu erlauben.

33 Die ZODB lässt sich mit sehr wenig Aufwand warten, ein paar Punkte sollte man aber beachten: Je nach benutztem Storage kann Packen notwendig sein. Upgrades Anwendungen müssen damit rechnen von einer alten Datenbank gestartet zu werden. Sicherung FileStorage erlaubt Hot-Snapshotting. Verfügbarkeit ZRS/ZEORaid

34 Die ZODB ist -Software und steht unter der ZPL, der BSD-artigen, GPL-kompatiblen Lizenz des Zope-Projektes. Der Zugang zum Quelltext ist unter svn://svn.zope.org/repos/main/zodb frei verfügbar. Entwickler sprechen sich auf der Mailingliste ab (Anmeldung über oder Gmane). Ihr seid herzlich willkommen, falls ihr experimentieren wollt!

35 Fragen Fragen?

36 Danke s Zuhören Ich hoffe es war informativ und interessant. Werbung: In Leipzig gibt es eine User Group ( die regelmäßig Treffen veranstaltet.