Feature Sets

The Berkeley DB family of products is offered in four different feature sets, each providing incrementally more functionality.

CDS includes all DS functionality, TDS includes all CDS functionality, and HA includes all TDS functionality. Note that DS, CDS, TDS, and HA are not separate products. When you download Oracle Berkeley DB, you have access to all four feature sets. Your application will use a subset of the API based on the feature set you choose.

The three Berkeley DB products are available with feature sets shown in the matrix below:

Data Store

Data Store, or DS, encompasses the basics of data storage. The API is simple and direct key or cursor based access. This minimizes overhead when adding, removing, and updating key/data byte arrays of data. Frequently accessed data is cached in memory. DS is very fast; it avoids storing data to disk until it is necessary. It performs no locking or other concurrency control, and it does not provide the ACID features of transactional systems. DS is simple and efficient data storage for non-concurrent applications that favor raw throughput over guaranteed data integrity.

Choose DS when:

• There is one reader or writer, or multiple read only users.
• Transactional data protection (ACID) is not required.
• Data can be lost or corrupted due to system failure and data recovery is not a required.

Concurrent Data Store

Concurrent Data Store, or CDS, adds locking and concurrency management services to DS. With the CDS features enabled, CDS uses locks to manage multiple readers, and a single writer orchestrating their concurrent access to data within the databases. CDS is simple and efficient data storage for concurrent systems. ACID transactions are not supported.

Choose CDS when:

• There are many readers and writers concurrently accessing the same database.
• Reads are much more common than writes.
• Transactional data protection (ACID) is not required.
• Data can be lost or corrupted due to system failure and data recovery is not a requirement.

Transactional Data Store

Transactional Data Store, or TDS, adds support for fully ACID transactionsto CDS. Changes to databases or their contents are atomic, consistent, isolated, and durable when using TDS. Transactions can be short lived or long running, lasting days if necessary. Transactions can improve system throughput in concurrent applications by grouping actions into a single commit to disk. Applications that use secondary indices to manage relationships require transactions to keep those relationships consistent. Berkeley DB's transactional system offers a great deal of flexibility to accommodate your desired performance and durability requirements. For example, TDS supports the ability to trade off durability for speed, or to allow readers to see uncommitted data to reduce locking overhead. TDS utilizes log files to contain information about transactional data that can be used to recover from application or systems failure.

Choose TDS when:

• There is a balance of concurrent readers and writers.
• Data integrity is critical.
• Recovery of committed data is a requirement.
• Database corruption is unacceptable.

High Availability

High Availability, or HA, adds support for replicated systems to TDS. There are the two basic reasons to build a replicated highly available system: scale and reliability. Scale your transactional application beyond the processing constraints of a single system. Deliver a highly reliable system where failure of one node does not cause system wide failure. Replicated databases come in a number of different configurations. Berkeley DB HA can be configured for any of the replicated designs that involve a single writer as a master and multiple replicas allowing for read only access to data. Berkeley DB HA supports the entire range of configurations from a simple hot standby with failover setup to a geographically diverse set of tiered replica clusters. Berkeley DB HA makes no assumptions about how the nodes communicate with one another; it supports hardware specific communications as easily as TCP/IP based networks. Third-party communications products are also an option. Berkeley DB HA will support any topology regardless of the number of replicated nodes within it. Upon notification of a failure of the master node a PAXOS-compliant, or any user-definable, election algorithm will identify a new master so that processing can continue uninterrupted. Berkeley DB HA can even be used as a completely disk-less in memory reliable distributed storage system.

Choose HA when:

• Single system throughput is not enough to meet your requirements.
• System uptime of five-nines (99.999%) or better is a requirement.
• The system must be able to survive any single node's failure.
• There is a need for a consistent online backup of a system's data.
• Your architecture calls for a hot fail over strategy.
• Your hardware device has multiple redundant systems and must be able to fail from one to the other gracefully.