Und wieder einmal ein Eintrag der Sorte "schöne Ideen, die es wert sind, ausprobiert zu werden, aber wohl nie implementiert werden, außer es findet sich jemand, der dem Andreas
$VIELGELD zuwirft":
mika und ich haben vor ein paar Tagen über das Problem der "database wedges" bei Subversion mit BDB-Backend und allgemein darüber, dass BDB scheisse ist, und immer wieder Datenverlust verursacht, diskutiert. Deswegen muss ein neues Backend her, das nichts mit der berüchtigten Berkeley DB zu tun hat.
Ich bin bei Recherchen dazu auf ein paar interessante Dinge gestoßen: einerseits gibt es
libjio, mit dem man transaktionsorientiert auf Dateien schreiben kann, was sich ziemlich nett anhört. Weiters bin ich auf
tdb gekommen, eine "Datenbank" ähnlich GDBM und BDB, jedoch ziemlich klein und mit Locking etc (naja, BDB kann das auch, aber GDBM nicht). Der Autor der libjio bietet auch einen Patch für tdb an, allerdings ist der ziemlich rudimentär, da er nicht die coolen libjio-Features nützt, sondern nur die Unix-I/O-Wrapper.
Meine Idee dazu ist, das ldbm-Backend von OpenLDAP dahingehend anzupassen, dass tdb als Alternative zu GDBM, NDBM, etc. verwendet werden kann, und tdb wiederum so zu erweitern, dass die libjio wesentlich besser integriert wird. Wenn das getan ist, und funktioniert, ist es natürlich interessant, sich die Performance dieses neuen Backend anzusehen, und mit dem BDB-Backend zu vergleichen, und dann die Robustheit bei großen Datenmengen und hoher Last über lange Zeit zu überprüfen. Bei mehr als 1000000 (in Worten: eine Million) Einträgen und hoher Last über mehrere Stunden ist mir bei Performance-Tests das BDB-Backend nämlich schon zweimal abgeraucht. Das ist übrigens auch meine negative Erfahrung mit BDB, neben den üblichen "database wedges" bei Subversion.
Auf jeden Fall: wer bereit ist, Geld für so eine Untersuchung auszugeben (wahrscheinlich eh keiner), möge sich bei mir melden.