|
|
This manual is meant as an introduction to the Berkeley DB library. Consequently, it describes how to build a very simple, single-threaded application. Consequently, this manual omits a great many powerful aspects of the DB database engine that are not required by simple applications. One of these is important enough that it warrants a brief overview here: environments.
While environments are frequently not used by applications running in embedded environments where every byte counts, they will be used by virutally any other DB application requiring anything other than the bare minimum functionality. An environment is essentially an encapsulation of one or more databases. Essentially, you open an environment and then you open databases in that environment. When you do so, the databases are created/located in a location relative to the environment's home directory.
Environments offer a great many features that a stand-alone DB database cannot offer:
Multi-database files.
It is possible in DB to contain multiple databases in a single physical file on disk. This is desireable for those application that open more than a few handful of databases. However, in order to have more than one database contained in a single physical file, your application must use an environment.
Multi-thread and multi-process support
When you use an environment, resources such as the in-memory cache and locks can be shared by all of the databases opened in the environment. The environment allows you to enable subsystems that are designed to allow multiple threads and/or processes to access DB databases. For example, you use an environment to enable the concurrent data store (CDS), the locking subsystem, and/or the shared memory buffer pool.
Transactional processing
DB offers a transactional subsystem that allows for full ACID-protection of your database writes. You use environments to enable the transactional subsystem, and then subsequently to obtain transaction IDs.
High availability (replication) support
DB offers a replication subsystem that enables single-master database replication with multiple read-only copies of the replicated data. You use environments to enable and then manage this subsystem.
Logging subsystem
DB offers write-ahead logging for applications that want to obtain a high-degree of recoverability in the face of an application or system crash. Once enabled, the logging subsystem allows the application to perform two kinds of recovery ("normal" and "catastrophic") through the use of the information contained in the log files.
All of these topics are described in the Berkeley DB Programmer's Reference Guide.