[Zope] ZODB robustness

[Chris McDonough]

Corey,

ZODB is very stable.  It's fast, and it's very transparent.  It serves web
apps very well.  With ZEO, it becomes compelling for distribution of logic
and data.  But it's not particularly well-equipped to handle high-write
situations in any configuration.  If your app will have many concurrent
users all wishing to write to the same objects at the same time, it may be
wise to look into a relational datastore, many of which offer record-level
locking instead of the optimistic write-collision detection strategy used by
the ZODB.  Although I've not used it, I believe Phillip Eby's ZPatterns
product aims to facilitate object-relational mapping in these sorts of
cases, and it apparently allows you to prototype using the ZODB and move to
other data stores later without application logic changes.

If you're on the edge of thinking this may not be a requirement, you'd be
wise to get comfortable with the nitty-gritty of how the ZODB works so you
can design your objects to be well-behaved in modest concurrent-write
situations.  Looking at the ZODB UML model in the Developer section of
Zope.org is a good start.  If you search for ZODB on Google, probably the
first thing that will come up is Jim's paper on the ZODB for the 2000 Python
conference, which is another good place to start.

----- Original Message -----
From: <corey@axcelerant.com>
To: <zope@zope.org>
Sent: Saturday, December 23, 2000 3:13 PM
Subject: [Zope] ZODB robustness


>
> Yo!
>
>
>   Hey, I got a few questions and could use the advice from some
>   of you experts out there.
>
>   First off, a quick background.  I'm in the current design and
>   analysis stage of a major new project.  What I'm doing is a
>   complete re-write of a venerable Operational Support System -
>   essentially, an n-tier framework that will be the ultimate,
>   back-bone engine ultimately running the whole company. Mission
>   Critical comes to mind...
>
>   My vision is to implement this thing entirely, from start to
>   finish, thoroughly in an object-oriented model. This is easy
>   as far as the web-application ( our front-end user interface )
>   is concerned, of course, by using Zope. However, in order to
>   see a pervasive object-orientd design through and through -
>   I'd also like to store all *data* as objects, within an Object
>   Database as well -- rather than the more traditional means of
>   using an RDBMS as the data-store and composing and decomposing
>   complex objects into tables...  Yuck.
>
>   Now, as a ( rather pleasant ) side-affect of choosing Zope as
>   our Web Application Server - it looks like Python will be the
>   choosen language that we'll be using to construct this OSS
>   in. Which leaves every OODB *I'm* aware of out ( they all only
>   support C++, Java and/or Smalltalk ) -- except, that is, for
>   ZODB.
>
>   So there it is. Can a whole company confidently rely on ZODB
>   as a robust ( I know it's scalable, with ZEO ) OODB solution
>   for a large, highly-active, mission-critical, highly-available,
>   enterprise Operational Support System infrastructure? Storing
>   and serving thousands of objects? For added reliability, I've
>   looked into utilizing one of the custom ZODB storage types -
>   namely, OracleStorage looks like the ticket - rather than the
>   standard FileStorage Data.fs.
>
>   So please, tell me - am I totally wacked? Crazy? Stark-raving
>   Mad? Should I just use Zope and stick with Oracle rdbms for
>   the data store, or is ZODB truly a viable and robust OODB?
>   I really appreciate any and all comments, advice or rotten
>   vegetables, thanks!
>
>
> Beers,
>
> Corey
>
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>
>