*I8Berkeley DB Reference Guide: Introduction[P2

Berkeley DB Reference Guide: Introduction



7

What can you do with Berkeley DB?



LBerkeley DB was designed to provide industrial-strength database services toJapplication developers, without requiring them to become database experts.FIt is a classic C library style toolkit, providing a broad baseDof functionality to application writers. Berkeley DB was written byBprogrammers, for programmers: its modular design surfaces simple,Forthogonal interfaces to core services, and it provides mechanism (forGexample, good thread support) without imposing policy (for example, theIuse of threads is not required). Just as importantly, Berkeley DB allowsIdevelopers to balance performance against the need for crash recovery andBconcurrent use. An application can use the storage structure thatGprovides the fastest access to its data and can request only the degree%of logging and locking that it needs.

IBerkeley DB is powerful enough to use as the underlying support for largeBnetwork servers and simple enough to use in a fast-prototype for aGsingle-user application. There are many large, complex, multi-threadedKservers running on fast, multi-processor machines, depending on Berkeley DBGtransaction semantics for recovery after system or application failure.

MMost Berkeley DB applications fall into two categories: basic data managementJand data management with recovery. In basic data management, applicationsKuse the Berkeley DB access methods to manage their data without concern forMapplication or system failure. The only Berkeley DB interfaces necessary for;this purpose are the Access Method and CursorGinterfaces. In data management with recovery, applications add calls toHthe transaction subsystem, in order to ensure complete recoverability in*the face of application or system failure.

HGenerally, both of these categories involve linking Berkeley DB into theGprocess' address space. It is also possible to implement client-serverPmodels using Berkeley DB. In such cases, application writers use Berkeley DB toIimplement the server as described above, and then select an IPC mechanismOwhich the client will use to talk to the server. (The Berkeley DB distributionIdoes not include an IPC mechanism, and it is up to the application writer!to implement this functionality.)

EWhile Berkeley DB's primary purpose is to provide a complete databaseHenvironment to applications, it is important to realize that Berkeley DBFincludes general-purpose shared memory buffer-pool and general-purposeElock manager interfaces, among others. These interfaces are directlyEuseful to application writers that may have no interest in databases.

HAdditionally, because of the tool-based approach and separate interfacesFfor each subsystem, you can support a complete transaction environmentNfor other system operations, e.g., Berkeley DB allows you to wrap transactionsIaround the standard UNIX read/write operations! Further, Berkeley DB wasHdesigned to interact correctly with the UNIX toolset, a feature no otherIdatabase package offers. For example, Berkeley DB supports "hot backups"D(database backups while the database is in use), and you can use the>standard UNIX tools to do those backups, e.g., dump(1),4tar(1), cpio(1), pax(1) or even cp(1).

MFinally, because scripting languages interfaces are available for Berkeley DBH(notably Python, Tcl and Perl), application writers can build incrediblyBpowerful database engines with little effort, (e.g., you can buildItransaction-protected database applications using your favorite scriptingIlanguages, an increasingly important feature in a world using CGI scriptsto deliver HTML).

LAOÿÿ