You are not logged in Log in Join
You are here: Home » Members » runyaga » ZopeFAQs » WhatWhyHowZODB
Log in
Name

Password

 
Link icon Forgot your password?
 
Print

WhatWhyHowZODB

The backing store for the ZOPE platform is the Zope Object Database. Its extremely powerful and flexible supporting a API that allows pluggable Storage Mechanisms behing the ZODB interface. Two phase commit. Has no size limit [mindlace said python has a large file support turned off so it is a python limitation OUT OF THE BOX its an option you must turn on when you compile python interperter]?. Features:

note I think this is probably the most important thing to make sound nice :) since its the scariest thing for people to get over:

  • ODBs? are unpopular becuase there is no standard interface into them, or ways to get your data out
  • most ODBs? - seem to have performance issues related to them vs. their relational breathren
  • Transactions - ZODB supports the concept of transactions between try/except blocks.
  • Versions - could be thought of as a long running transaction that can span hours, days, weeks.
  • Undo - any transaction that is committed inside the ZODB can ultimately be rolled back. if you change 4 objects in a transaction, you can undo the transaction and the objects would be restored to their previous state.
  • Undoable Undo - available to some types of Storage interfaces. they call this "Transactional Undo"
  • Permissions - the ZODB, standalone, has no known Permissions. Permissions are layered ontop of ZODB via ZOPE.
  • Pluggable Storage -
    • Berkley DB - ZODB Storage
    • RDBMS Storage - There is an OracleStorage, and InterbaseStorage?.
    • Remote Storage (ZEO) - a ZEO client is essentially a ZOPE install but its Storage is a remote server.
    • File Stroage - [default]?
    • NFS - dont use NFS, because of NFS's locking scheme (?)
    • NTFS - works just fine
    • FAT/FAT32 - works just fine
    • Intermezzo - anyone have experience?
    • ext2/ext3 - works just fine (anyone running ext3?)
    • reiserfs - i assume it works (egenius I believe sells ZOPE/Reiser configurations)

----------------------------------------------------------------------

----------------------------------------------------------------------

some quick comments:

  • as stated above, usually one major issue people come about with OODBMS is performance. the topic is complex, dependent on many factors and design decisions ..

just one fact: currently (8/2002) the world's largest database with over 500 TB is run on an OODBMS (objectivity.com) by the Stanford Linear Accelerator Center (SLAC) - http://www.slac.stanford.edu/slac/media-info/20020412/database.html

This is 50x the probably biggest Oracle installation in Europe (at a german telco).

Also: how much complex, highly-structured master data (like contract information, product definitions, .. not log-data) do you have?

100MB, 1GB? And, what does 1GB of RAM cost today? Just go out and by RAM and operate your ZODB out of main memory.

  • The impedance-mismatch.

.. at the design level: Have you ever gone through the full spectrum of pain of having both a relational DB designed as an entity-relationship model plus an object-oriented model designed with e.g. UML?

.. at the implementation level: Not to speak of the the object-relational mapping layer you also have to come along. It too often develops into a nightmare. Even with stuff like supporting code generators or libraries of mapping layers.

Enter ZODB. Transparent. Orthogonal. Single design paradigm (OO) and single design method possible (e.g. UML). Pluggable storage backends.

  • ZODB, OODBMS and language neutrality

ZODB is a closed system - it is directly only accessible from Python. Of course, this makes possible a very tight language integration and thus transparency. It is quite clear, that no language neutral access method would ever allow such transparency over all (existing) languages.

  • complex, highly-structured master data in ZODB * simple record oriented mass data in RDBMS

More important: Why do you need language neutrality? Allowing access to the data store from all system components?

Using the data store, regardless if relational or OO, as the integration platform of a system is at least a qustionable architecture. It introduces deep semantic dependencies and only on the surface level solves the integration problems.

One alternative is a service-based architecture where a stateless service API mediates accesss to the data store and implements business logic.

  • Hot schema evolution.

What if your definition of "contract" changes? With RDBMS, you usually write new DDL for the revised tables plus migration scripts to move the data. Then you must take a downtime to upgrade the schema and migrate the data.

With ZODB, you implement the revised classes plus implement hooks that get called when instances of old classes get loaded to migrate data on-the-fly. You don't need to take any downtime!

  • You're not forced to use ZODB. You can perfectly build on a backend RDBMS if you like for all your data, or you can use a mixture:
Copyright (c) 2011 Zope Foundation. All rights reserved. Legal | Contact
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)