> I know ZODB is slow on writes and is better
> suited to many reads/few writes. This fits
> the profile of my application (and probably
> many web apps) however even with reads, using
> ZEO server and one ClientStorage instance per
> CherryPy thread I find that ZODB is around 5
> times slower using IOBtrees() as the persistance
> class and reading in the key order.
On somes tests I did yesterday the initial
read took a long time, but subsequent reads
where very quick. For example, a 2000 record
table (about 400K of data) required about 10
seconds to read the first pass. Subsequent
iterations were on the order of 0.25 seconds.
This suggests one approach: If you know which
objects are likely to be accessed, you could
pre-fetch them, possibly in the background
while waiting for user input.
> I would really like to use ZODB but with
> the performance I have experienced so far
> it is just not practical.
After some brief tests, I'm reluctantly passing
on ZODB, but I think we should be careful about
spreading the OODBMS-is-slow meme. I'd like to
see some use cases that handle > 10**6 objects.
Someday I'd like to revisit ZODB for a project
in different circumstances -- where I'm certain
that the dataset has lower bounds.
Jeff Bauer
|