[ZODB-Dev] Re: Heavy size increasing of database after adding an object

Malcolm Cleaton malcolm at jamkit.com
Fri Dec 3 09:08:37 EST 2004


On Wed, 01 Dec 2004 17:20:07 +0100, Manuel Markwort wrote:
> I adding my own ZClass Objects in the data.fs. After adding a new 
> instance of those objects the database size increases heavily in 
> opposition of the real object size. Before I add the instance to the 
> database it's size is 26.6MB, after commiting the transaction the size 
> is about 26.9MB. After packing the database the size is 26.6MB again. 
> What happened in the background? It is possible to avoid this high 
> increasing of the database without packing after adding the object?

The temporary size increase of the database is caused by all the existing
objects that you've changed. Whenever you change an object, a new copy is
created in your transaction, and the old copy hangs around in the Data.fs
until you pack.

"But wait!" I hear you cry, "I didn't change anything, I just added my new
object!" Well, you probably added it to a Folder, and as a result the
Folder object has been changed - it now has a different list of children.
Depending on the details, other objects may have been changed too.

As an example, I added a couple of empty Python Scripts to my database,
one in a folder with not many items, and one in a very busy folder. I then
added a new page, which adds a few objects and also touches various
catalog indexes etc.

Script in small folder: +6700 bytes
Script in large folder: +154,907 bytes
New page: +657,405 bytes

Total: +819,012 bytes
After packing: +57,728 bytes

In short, around 800Kb of Data.fs size increase, 93% of which was old
versions of changed objects, and only 7% of which was the new content I
added and the actual size increase of existing objects.

If you need transaction undo support, you can't avoid this, although you
can minimise the additional space needed by designing your object
relationships carefully, so that you don't often need new versions of
large objects.

If you can do without undo, then theoretically a Storage implementation
could avoid this growth, but I don't know if there's anything
production-ready which does this.

I believe the traditional approach is to ensure you have plenty of space,
and to pack regularly.

Thanks,
Malcolm.

-- 

    [] j a m k i t
      web solutions for charities

         malcolm cleaton
T:  020 7549 0520
F:  020 7490 1152
M:  07986 563852
W: www.jamkit.com




More information about the ZODB-Dev mailing list