[ZODB-Dev] Re: What makes the ZODB slow?

[Florent Guillaume]

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

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com