Next: , Previous: Garbage Collection, Up: User Guide


4.17 Berkeley DB Data Store

This section briefly describes special facilities of the Berkeley DB data store and explains how persistent objects map onto it. Elephant was originally written targeting only Berkeley DB. As such, the design of Elephant was heavily influenced by the Berkeley DB architecture.

Berkeley DB is a C library that very efficiently implements a database by allowing the application to directly manipulate the memory pools and disk storage without requiring communication through a server as in many relational database applications. The library supports multi-threaded and multi-process transactions through a shared memory region that provides for shared buffer pools, shared locks, etc. Each process in a multi-process application is independently linked to the library, but shares the memory pool and disk storage.

The following subsections discuss places where Berkeley DB provides additional facilities to the Elephant interfaces described above.

4.17.1 Architecture Overview

The Berkeley DB data store (indicated by a :BDB in the data store specification) supports the Elephant protocols using Berkeley DB as a backend. The primary features of the BDB library that are used are BTree databases, the transactional subsystem, a shared buffer pool and unique ID sequences.

All data written to the data store ends up in a BTree slot using a transaction. There are two databases, one for persistent slot values and one for btrees. The mapping of Elephant objects is quite simple.

Persistent slots are written to a btree using a unique key and the serialized value being written. The key is the oid of the persistent object concatenated to the serialized name of the slot being written. This ordering groups slots together on the disk

4.17.2 Opening a Store

When opening a store there are several special options you can invoke:

4.17.3 Starting a Transaction

Berkeley DB transactions have a number of additional keyword parameters that can help you tune performance or change the semantics in Berkeley DB applications. They are summaried briefly here, see the BDB docs for detailed information:

4.17.4 Special Commands

The berkeley DB data store exports some special facilities that are not currently supported by other data stores.

4.17.5 Performance Tuning

Performance tuning for Berkeley DB is a complex topic and we will not cover it here. You need to understand the Berkeley DB data store architecture, the transaction architecture, the serializer and other such parameters. The primary performance related parameters are described in config.sexp. They are: