ZODB

All about the ZODB.

ZODB Introduction

ZODB makes it really fast and easy to build and distribute Persistent Python applications. Just subclass `Persistent`, and your objects and application become persistent. ZODB is in heavy use in the Pyramid and Plone communities. It is used in this website, and at PrivaCV.com. Multiple people report ZODB to be rock solid. No Zope required.

ZODB uses optimistic concurrency control to provide ACID properties and Snapshot isolation to python transactions. ZODB is very good for applications which feature many reads and comparatively few writes. Not so good for an airline reservation system. ZODB scales wonderfully. If a single server is not fast enough, deploy a ZEO server. ZEO provides a database server feeding application servers with cache invalidation, so it performs wonderfully in heavy read applications. If that is not good enough, store the data in a PostgreSQL database using RelStorage. Or store your blobs on the file system, or in Amazon S3 storage. For larger applications, you can shard your data across multiple databases. And since it is mostly written in Python, it is really fast and easy to make any optimizations you need.

ZODB has significant advantages over other persistence technologies. In relational databases it is hard and slow to store a tree. JSON databases do store trees but not graphs. MongoDB has problems with fine-grained transaction management across document boundaries. PostgreSQL has excellent transaction management, but does not support arrays of heterogeneous objects. And of course once you are in a pure dynamic Python environment, there are all kinds of things that you can do that you could not even imagine doing with a traditional database.

ZODB is useful for building JSON servers. There are a large number of Python libraries which support JSON. Javascript does not have a `__getattr__` method, and would block on object fetching, so don't wait for something like ZODB to appear in the Javascript world anytime soon.

To summarize, ZODB makes it really easy to build and distribute persistent Python applications. This introductory page answers the major questins, and links to the key resources that you will need if you are considering using the ZODB.

You can use persistent python objects directly,
or with one of the multiple web frameworks built
on top of them. This section introduces the different web
frameworks built
on top of Persistent Python Objects. It takes a historical
perspective, starting with the oldest frameworks. Perhaps
the most interesting ones are the newest ones at the end
of the list.

ZODB supports both sharding, where the database is split across multiple file storages, as well as multi-database, where where the database is split among multiple databases. Indivudial databases can be FileStorage, RelStorage, NEO, or any other format supported by the ZODB.
A multiple-database is pretty much what it sounds like: it ties together multiple DBs into one grand unified DB: each persistent object is stored in only one DB but can be transparently referenced as normal from any DB in the collection.

There are several parts to multiple-database. Transaction management uses two phase commit to ensure that the transaction is successfully completed across all databases. Garbage collection cleans up the garbage across all databases. You also need a scheme to figure which database a particular object id is located in.

ZODB is very interesting software, very different from mainstream databases, and so it is only natural to ask about performance. Yes, it offers great speed of software development, but how does it perform at runtime. In particular a ZODB application is just a python application, with potentially lots of disk access to small python objects. And also with lots of traversals of the graph of objects, particularlly if used in Zope. So how does ZODB perform?

I invite you to Register and then link to your own blog postings and
software packages..