views:

377

answers:

5
+2  Q: 

ZODB In Real Life

Hi guys,

Writing an app in Python, and been playing with various ORM setups and straight SQL. All of which are ugly as sin.

I have been looking at ZODB as an object store, and it looks a promising alternative.

My question then:

Would you recommend ZODB?

What are your experiences, problems, criticism with ZODB?

particularly with regards developer's perspectives, scalability, integrity, long-term maintenance and alternatives. Anyone start a project with it and ditch it? Why?

Whilst the ideas behind ZODB, Pypersyst and others are interesting, there seems to be a lack of enthusiasm around for them :(

Thanks in advance

+2  A: 

ZODB has been used for plenty of large databases

Most ZODB usage is/was probably Zope users who migrated away if they migrate away from Zope

Performance is not so good as relatonal database+ORM especially if you have lots of writes.

Long term maintenance is not so bad, you want to pack the database from time to time, but that can be done live.

You have to use ZEO if you are going to use more than one process with your ZODB which is quite a lot slower than using ZODB directly

I have no idea how ZODB performs on flash disks.

gnibbler
Thanks for the answer! I am wondering if ZODB will fit in place of MySQL using ZEO in a webfarm setup. Serious caching will hopefully negate the slow performance of the store.
Aiden Bell
ZODB usually smokes relational databases for repeated queries when the data doesn't change, even with ZEO in the mix, because there's already a client-side cache.
Chris McDonough
A: 

With pickling you should be able to use any key value database in a similar fashion.

mikerobi
Unless you pickle both 'a' and 'b' which each reference 'c' surely?
Aiden Bell
@Aiden, how does zodb handle that case?
mikerobi
ZODB handles it transparently. See http://faassen.n--tree.net/blog/view/weblog/2008/06/20/0
Chris McDonough
@Chris, thanks :)
Aiden Bell
+2  A: 

Compared to "any key-value store", the key features for ZODB would be automatic integration of attribute changes with real ACID transactions, and clean, "arbitrary" references to other persistent objects.

The ZODB is bigger than just the FileStorage used by default in Zope:

  • The RelStorage backend lets you put your data in an RDBMS which can be backed up, replicated, etc. using standard tools.
  • ZEO allows easy scaling of appservers and off-line jobs.
  • The two-phase commit support allows coordinating transactions among multiple databases, including RDBMSes (assuming that they provide a TPC-aware layer).
  • Easy hierarchy based on object attributes or containment: you don't need to write recursive self-joins to emulate it.
  • Filesystem-based BLOB support makes serving large files trivial to implement.

Overall, I'm very happy using ZODB for nearly any problem where the shape of the data is not obviously "square".

Tres Seaver
+1 - interesting read
Aiden Bell
+2  A: 

I've used ZODB for more than ten years now, in Zope and outside. It's great if your data is hierarchical. The largest data store a customer operates has maybe.. I dunno... 100GB in it? Something on that order of magnitude anyway.

For a performance comparison against Postgres, see http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/zodb-benchmarks-revisited .

If you're writing a WSGI web app, these packages may be useful:

http://pypi.python.org/pypi/repoze.tm2 (http://docs.repoze.org/tm2/)

http://pypi.python.org/pypi/repoze.zodbconn (http://docs.repoze.org/zodbconn/)

Chris McDonough
Accepted. Not just because of the answer, but I keep coming across your posts/articles/presentations when googling ZODB stuff I need. I know who to direct further questions at! ;)
Aiden Bell
A: 

I would recommend ZODB.

I really don't have any criticisms, if it's an object store your looking for, this is the one to use.

I've stored 2.5 million objects in it before and didn't feel a pinch.

Kevin Kalupson