1 Objektorientierte Datenbank ZODB [toc]

• Turbo-Pascal heißt nun Delphi und ist objektorientiert.
• Visual Basic ist es inzwischen auch.
• Perl ist es ebenfalls.
• Aus C wurde C++.
• Lisp, Java und natürlich Python sind objektorientierte Programmiersprachen

2 Begriffsdefinition [toc]

1. Objektorientiert:
   Was heißt eigentlich "Objektorientiert"? Das wichtigste Merkmal ist, dass Methoden und Daten zusammengefasst werden. Im folgenden ein Beispiel in der Syntax der Programmiersprache Python:

   class Benutzer:
       def __init__(self, id, name, vorname): # Konstruktor
           self.id=id
           self.name=name
           self.vorname=vorname
           self.warenkorb=[]
   
       def zuWarenkorb(self, ware):
           self.warenkorb.append(ware)
       
       def warenkorbBestellen(self):
           bestellung=[]
           bestellung_wert=0
           for ware in self.warenkorb:
              self.bestellung.append(ware)
              bestellung.append(ware)
              bestellung_ware+=ware.preis

2. Datenbank:
   Was versteht man unter einer Datenbank? Eine Datenbank speichert Daten, so dass sie nach dem Neustart des Rechners wieder verfügbar sind. Das Dateisystem kann somit als eine einfache hierarchische Datenbank angesehen werden.

3 Never change a running system [toc]

4 Grundlagen [toc]

4.1 Serialisieren [toc]

4.2 Endloslange Select-Statements [toc]

4.3 Transaktionen [toc]

• A: Atomar. Transaktionen werden ganz oder garnicht durchgeführt.
• C: Consistency. Die Konsistenz der Daten muss nach der Transaktion gewährleistet sein.
• I: Isolation. Führt ein Thread eine Transaktion durch, darf ein zweiter Thread die geänderten Daten erst sehen, wenn die Transaktion abgeschlossen ist.
• D: Durability. Stürzt der Rechner während dem Betrieb ab, dürfen keine Daten verloren gehen.

5 ZODB [toc]

5.1 Installation [toc]

 cd ZODB???
 python setup.py --prefix=$HOME install

export PYTHONPATH=$HOME/lib/python2.2/site-packages

5.2 Beispiel [toc]

 gesuchterNuzter=userdb.get(12345)

5.3 _p_changed=1 [toc]

 myNutzer.warenkorb.append(ware)
 myNutzer._p_changed=1

5.4 BTrees [toc]

# Schreibend:
mybtree[key]=value

# Lesend:
value=mybtree.get(key)
if value:
    # Der Schlüssel existiert
else:
    # Der Schlüssel existiert nicht

# Testen, ob die BTree-Struktur korrekt ist:
for key in mybtree.keys():
    if not mybtree.has_key(key):
        raise("BTree is insane: key not found: %s" % key)

5.5 Subtransaction [toc]

i=0
while 1:
    i++
    data=get_data_from_somewhere()
    myzodb.addData(data)
    if i>100000:
        #Subtransaktion auf Platte schreiben
        get_transaction().commit(1)
        i=0

5.6 Primär-Schlüssel und Indizes [toc]

 mybtree[id]=object_1
 mybtree[id]=object_X # object_1 wird überschrieben

 for nutzer in userdb.values():
     if nutzer.name=="Meier":
         print "ID: %s" % nutzer.id

class BenutzerContainer:
    def __init__(self):
        self.indexName=OOBTree()  

    def setName(self, name, id):
        # Alten Namen löschen
        old_name_dict=self.indexName[name]
        del(old_name_dict[id])

        # Neuen Namen indizieren
        new_name_dict=self.indexName.setdefault(name, {})
        new_name_dict[id]=1

5.7 Update von Objekten in der ZODB [toc]

class BenutzerContainer:
    def update(self):
        for user in self.users:
            if type(user.email)==type(""):
                user.email=[user.email]
                user._p_changed=1

5.8 Lang laufende Transaktionen [toc]

i=0
for objektid, object in root.objects.items():
    i+=1
    if i%10000==0:
        get_transaction().commit() # Bei einem readonly Zugriff abort()
        connection.sync()
    ...

6 Storage-Typen [toc]

• DirectoryStorage:Pro Objekt werden die Daten in eine Datei geschrieben. Dass hat den Vorteil, dass dieser Storage nicht von Zeit zu Zeit komprimiert werden muss.
• BerkleyStorage:Die Objekte werden in einer BerkleyDB gespeichert. Dieser Storage Typ sollte nicht verwendet werden, da er zur Zeit nicht weiterentwickelt wird.
• ClientStorage:Die Daten werden auf einem Server gespeichert. Siehe ZEO.

7 ZEO [toc]

 storage=ClientStorage.ClientStorage(("myzeoserver.mydomain.de", 1975))
 db=DB(storage)

  Zeit    |  Aktion
 ------------------
 12:00:00 | Prozess 1 liest Daten (Start der Transaktion)
 12:01:00 | Prozess 2 liest Daten und ruft sofort "commit()" auf
 12:02:00 | Prozess 1 will die seit zwei Minuten bearbeiteten Daten speichern
          |  --> ConflictError, da die Daten inzwischen geändert wurden.

• Zwischen Start und Ende einer Transaktion sollte möglichst wenig Zeit vergehen.
• Batch-Input (Einlesen vieler gleichartiger Datensätze) sollte aufgeteilt werden. Ein Commit nach jeweils N Datensätzen ist sinnvoll.
• Wenn eine Transaktion aufgrund eines ConflictErrors misslingt, vor dem erneuten Versuch "sync()" aufrufen, damit der Datenbestand des ZEO-Clients aktualisiert wird.

8 ZODB und Webanwendungen [toc]

9 Features die ich nicht verwende [toc]

• Ape: Speichern der serialisierten Objekte in einer relationalen Datenbank. Aus meiner Sicht macht es die Anwendung komplexer und fehleranfälliger. FileStorage und ClientStorage gut getestet und stabil.
• Undo: ZODB unterstützt das Zurücknehmen von Transaktionen, was aus meiner Sicht keinen Sinn macht. Wenn man Fehler gemacht hat, muss man ein Backup der Datenbank benutzen und falls in der Anwendungs-Schicht eine Undo-Funktion benötigt wird, sollte man sich die selber programmieren.
• Versions: ZODB verwaltet in Zusammenhang mit der Undo-Funktionalität mehrere Versionen eines Objekts. Es ist möglich sich ältere Versionen eines Objekts aus der Datenbank zu holen. Es hat sich jedoch gezeigt, dass der Verlauf eines Objekts besser in der Anwendung anstatt in der ZODB verwaltet wird. ZODB Versions sollten nicht verwendet werden. Siehe auch: Mailingliste Juli 2004.
• Threads: ZODB unterstützt Threads, die Anwendung wird jedoch dadurch unnötig komplex. Besser ist es mit mehreren Worker-Prozessen zu arbeiten, die nur einmal eine Verbindung zur Datenbank aufbauen, und diese Verbindung wiederverwenden.

10 Eigene Erfahrungen [toc]

1. 2001: Mit Zope (Web Application Server): Per Web-Administiert
2. 2002: Kleine Arbeitsverwaltung (Workflow) mit Zope
3. 2003: Email-Archiv nur ZODB
4. 2003: Key-File Archiv nur ZODB

11 Nachteile [toc]

• Beim FileStorage werden die Daten in einer Datei gespeichert. Änderungen werden immer hinten angehängt, so dass die Datei stets größer wird. Von Zeit zu Zeit muss die Datei komprimiert werden.
• Python-Kenntnisse nötig. Man könnte auch mittels Java und Perl auf die ZODB zugreifen, doch um diese Wrapper zu installieren ist ein gewissen Python-Wissen unumgänglich.
• ZODB ist anfällig gegenüber rückwärtsgehenden Uhren. Da in jeder Transaction der aktuelle Zeitstempel gespeichert wird, kann es zu Problemen kommen, wenn man die Systemzeit zurückstellt.
• Klassen müssen in allen Modulen mit dem gleichen Namen angesprochen werden:

  # Schreibweise 1
  import myModule
  myc=myModule.MyClass()
  
  
  # Schreibweise 2
  from myModule import MyClass
  myc=MyClass()

  Während für normale Python-Anwendungen es keine Rolle spielt, ob die obere oder die untere Schreibweise verwendet wird, muss man bei persistenten Klassen in allen Modulen die gleiche Schreibweise verwenden.
• Die Daten in der ZODB sind unstrukturiert. Der Anwender muss selbst darauf achten, dass bei Veränderungen beim den Persistenten Klassen, auch alle Instanzen in der Datenbank geändert werden. Beispiel: Bei einer Klasse für Kundenkontakte wird das Feld "Telefonnummer" von einem String zu einer Liste von Strings (um mehrere Telefonnummern pro Kontakt speichern zu können). Sie müssen nun mit einem einmal laufenden Updatescript alle Kontakt Objekte in der Datenbank aktualisieren.
• Die Indizierung von Attributen muss man selbst übernehmen. Eine Abfragesprache existiert nicht. Um z.B. alle Kontakte zu finden, deren Postleitzahl 09112 ist, muss man in einem Pythonscript in einer Schleife alle Kontakte in der Datenbank überprüfen. Das ist nur performant, wenn wenige Objekte durchsucht werden müssen. Möchte man mit einem Index arbeiten, muss man ihn sich selbst programmieren. Das Mutterprojekt Zope bietet Indizes an, zieht aber einen "Rattenschwanz" an Abhängigkeiten mit sich. Bei einer relationalen Datenbank ist man mit SELECT * FROM ... WHERE ... schneller am Ziel.
• ZODB ist nicht verbreitet. Es ist ein Nischenprodukt, mit dem sich nur wenige gut auskennen. Für neue Webanwendung bin ich inzwischen zu dem Web Framework Django und der Datenbank PostgreSQL gewechselt.

12 FAQ [toc]

• Gibt es eine Abfragesprache, ähnlich wie SQL?
  ZODB verfügt über eine ausgereifte, vollständige Programmiersprache als Abfragesprache.
• Wie kommunizieren Client und Server?
  Wenn man FileStorage (default) verwendet gibt keinen Client und keinen Server. Man kann sich eine ZODB-Anwendung wie eine große objektorientierte Stored-Procedure vorstellen.
  
  Verwendet man ZEO kommunizieren der Client und der ZEO-Server über TCP oder über ein Unix-Socket.
• Ist der Quelltext auch in der Datenbank?
  Nein, der Quelltext wird nicht in der Datenbank gespeichert. Der Quelltext ist wie gewöhnlich im Dateisystem. Bei einem Backup der ZODB sollte man ebenfalls den Quelltext sichern, da die Datenbank nur in Zusammenhang mit dem Quelltext benutzbar ist.
• Gibt es ein Sprache zur Datendefinition
  Die Python-Klassen sind die Datendefinition.
• Warum verwendest du nicht Zope?
  
  • "Through the Web Development" ist langsam und nervig.
  • Es ist umständlich Python-Produkte mit Zope zu programmieren.
  • Ich benötige die von Zope zur Verfügung gestellte Oberfläche nicht
  • Implizit Acquisition ist fehleranfällig: Zope3 verwendet es auch nicht mehr.
  • KISS: Keep it Simple and Stupid. Die von ZODB bereitgestellte API ist einiges kleiner, als die von Zope. Der Nachteil, dass man Dinge wie Nutzerverwaltung selbst programmieren muss, ist für mich nicht bedeutend.
  • WEB-DAV hält nicht was es verspricht.

13 Links [toc]

• ZODB/ZEO Guide (Vorlage für diesen Vortrag)
• ZODB-Dev Mailingliste (Trotz des "dev" in dem Namen der Liste, werden Anfängerfragen gerne beantwortet)
• Meine Python-Einführung
• Lösen von ConflictErrors: ApplicationLevelConflictResolution
• Wer nicht mit mehreren Threads arbeiten muss, kann auch Durus ausprobieren. Es ist einfacher und kleiner als ZODB. Siehe auch Durus Vortrag von David Binger auf der PyCon 2005