Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Download a PDF version of this Article

Learning Center Home

Table of contents:

Dynamic Containers™: The Key To Superior Performance

• Introduction
• Objectivity/DB Database Architecture
• Typical Data Access and Usage
• Basic Approaches to Utilizing Containers
• Data Model Abstraction
• Data Acquisition Pattern
• Leveraging Containers
  

Deployment Examples

• The COM21 Solution
• The Coherent Networks Solution
• Space Telescope Institute
• Conclusion

Objectivity/DB Database Architecture

Overview: Objectivity/DB utilizes a 64 bit object identifier (OID) for every object within the federated database (or Federation). The 64 bit OID is split into 4 components as follows:

• First 16 bits - Logical Database ID
• Second 16 bits - Logical Container ID (1 bit internal use, 15 bits container number)
• Third 16 bits - Logical Page within container
• Last 16 bits - Logical Slot within page
  
  

The Objectivity/DB storage model thus comprises a Federation (the system database) which logically contains a collection of databases, where each database is represented as a physical file1 . Each database is a collection of containers, where each container is a number of physical database pages. A container contains objects which may be related to many other objects. The container is used to cluster a group of logically related objects together for efficient access and processing.

Based on the OID breakdown above, a federated database can have 65,535 databases (implemented as system files) which can in turn have 32,767 containers, which in turn can have 65,535 pages. Assuming that we use 4Kb pages, this would give us the ability to address a minimum of 5.76 * 10^17 bytes - a very large addressing space that is closing in on the petabyte level. By changing the page size, the address space is affected proportionately. Objects may be larger than a physical page and VArrays may be extremely large, so the physical address space can be many Petabytes with current releases and will stretch to Exabytes with future releases.

This is part of the reason that Objectivity/DB is the premier choice for those requiring the ability to store extremely large amounts of data in a database and to manage it.

Objectivity/DB uses the container as the level of locking granularity. Lock management is done by lock server processes which communicates with all the database client processes that request locks. Since individual containers can be tailored to different sizes, a single lock can lock very few objects in a small container or large numbers of objects in a large container.

There are three lock modes supported by Objectivity. The first two are familiar to most database programmers, the read lock and the update lock. As expected, a read lock prevents others from updating, but allows others to read, and an update lock is exclusive. However, since the locking granularity is at the container level, supporting only these two modes would be quite inconvenient to most programmers. It could also degrade system throughput and response times. Therefore, a third locking mode, MROW read, is also supported. MROW (Multiple Readers One Writer) permits an update to exist concurrently with any number of MROW readers. In short, an MROW reader never blocks, and can always read data from a container. Objectivity/DB takes a transactionally consistent snapshot of the container and maintains the ACID properties of an MROW read transaction for each MROW reader.