Schon länger bin ich am überlegen, wie man ein Browsergame ohne eine relationale Datenbank effizient umsetzen könnte. In meinen Augen, und darin bestätigen mich die jahrelangen Erfahrungen mit AirlineSim, sind sie einfach nicht für diese Art von Projekt geeignet. Schon vor längerem wurde ich daher auf Objektdatenbanken aufmerksam, die Objekte direkt und ohne jegliche Form von Meta-Information speichern und verwalten können. Der Gedanke ist extrem verlockend: Kein XML, keine Annotations, keine zeitraubende und fehleranfällige Konfiguration mehr. Einfach in Objekten programmieren, wie man sich das in einer objektorientierten Sprache wie Java vorstellt. Was mich allerdings immer skeptisch gestimmt hat war und ist die Frage nach der Performance. Wie gut kommt eine derartige Datenbank mit sehr großen Datenmengen und komplexen Objektgraphen klar? Die Datenbank von AirlineSim besteht zum gegenwärtigen Zeitpunkt aus etwa 80 Tabellen und speichert bereits nach recht kurzer Spielzeit eine Datenmenge im Bereich von mehreren hundert Megayte in Millionen von Datensätzen.

Der bekannteste Vetreter der Objektdatenbank in der Javawelt ist m.W. db4o, ein ehemals kommerzielles Projekt was jetzt unter der GPL weiterentwickelt wird. Heute bin ich über einen Blogeintrag gestolpert, der sich genau mit meiner Frage beschäftigt: Wie schnell ist db4o eigentlich? Die Ergebnisse eines Benchmarks, welches anhand einiger Testcases db4os Performance mit denen anderer, üblicher Datenbank-ORM-Kombinationen vergleicht, ist durchaus beeindruckend und nimmt mir etwas die Skepsis was dieses Thema betrifft. Das schlimme daran ist, dass es mir nun noch viel mehr unter den Nägeln brennt, mit dieser Library zu experimentieren und evt. das Aufkommenssystem in Form eines Prototyps unter db4o zu testen. Aber ich habe dazu keine Zeit! Kaum auszuhalten! Hätte der Tag nur 48 Stunden…

]]> http://www.lunikon.net/2007/05/26/kaum-auszuhalten/feed/ 0