Le mardi 18 mai 2010 20:08:51, Jim Fulton a écrit :
> I've decided I really want to provide a database compression option. I
> could have built something directly into ZODB or used a wrapper
> storage. I chose the later because it was more flexible. I think I
> would have run into the same issues without a wrapper storage.
In NEO (which I introduced a few weeks ago) we support compression "inside"
the Storage implementation, which solves the points you mentioned: it can
expand objects before looking for references, for example.
Also, some out-of-hat stats: In our test application, with optional
compression enabled (ie, objects are stored zlib-deflated only when it shows a
gain) it turns out that 10% of objects are not compressed.
They are for example BTree.Length instances (very small, < 30 bytes IIRC) but
modified very often. Delta compression would help here, not sure if it's worth
Why not defining some kind of callbacks in Storage API, which would allow to
plug such mechanisms in a storage rather than wrapping around it ?
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org