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 
the overhead.

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 ?

-- 
Vincent Pelletier
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to