Roché Compaan wrote:
I love the ZODB, and I am sure that I don't have to explain why, to
anybody on this list. I love it so much that it often clouds my
judgement. Sometimes I really should be using a relational backend but I
don't - the ZODB is just too convenient, and I don't have to complicate
the design of my app with a complicated object relational mapping.

Inevitably I end up with applications that perform poorly in some areas.
When this happens I found that using a hybrid backend works best. Most
of the data lives in the ZODB and only instances of classes that are
written frequently and grow the most in numbers are moved to a
relational backend.

I often daydream of a ZODB that will one day have such great performance
that it won't be necessary to adopt a hybrid backend. I know there is a
huge difference between objects and records in an RDBMS, but in an
attempt to understand more, I want to know what makes the ZODB so much
slower than a relational database when writing a lot? Is it possible to
speed it up in any way?
Other questions that come to mind:

What overhead does undo add to performance?
Can state be serialised more economically to reduce disk IO?
Is the ZODB really slow, or is it just Zope and Plone or grand object
frameworks built on top it that make it appear slow? (In all my
benchmarks this is shown to be mostly true)

The ZODB is actually very fast. It has one drawback, which is that concurrent writes are resolved only for class designed for that (namely BTrees), otherwise it's left up to the application to deal with it when it receives a ConflictError.

So you're probably observing slowness in the frameworks on top of it.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to