ODB

I recently had the privilege of trying out ODB, a Python-based frontend for object databases. This software allows users to interact with three separate data storage engines, the most prominent of which being the popular BDB (Berkeley DB). However, the other two engines are memory-resident and built entirely in Python.

ODB's interface is clean and streamlined and aims to hide the gritty details of database interactions from the user. One of the most notable features of ODB is its "Full" and "Mem" engines. Previously, ODB was created as a simple wrapper for BDB; however, I discovered that this caused major issues with locking. Deadlocks and leaks were common, causing database recovery to be performed frequently, which is not optimal for a 24/7 environment.

Due to the locking issues associated with BDB, ODB released its own Python-based, in-memory database engine called "memdb." This engine stored the database as a sequence of log files and rebuilt the database one change at a time. Unfortunately, this resulted in a large overhead issue for databases with considerable size. ODB quickly added the ability to checkpoint and store the environment as a giant state file. Despite the improvements, reading the entire database at startup was still required.

This late prompted the creation of the "full" implementation that checkpoints the database to a heap file for lazy loading and minimal startup time. At this time, all of the interfaces are mostly intercompatible. With the abstract ODB interface (odb.odbi), it's possible to switch back-ends without coding differences. However, if you'd like to use the special features of the "full" back-end, use that interface directly. Overall, I found ODB to be an excellent software tool with a clean interface and easy-to-use capabilities.