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:

Building High-perfomance Object Oriented Databases

• The Problem
• High ingest rates
• High delete/archival rates
• Complex relationships
• Flexibility
• Performance Optimization
• Very Large Cardinalities
• A Solution
• Persistence
• The Hierarchical Solution
• The Relational Solution
• An Object-oriented approach to persistence
• Query/Retrieval
• Query by Attribute
• Query by Traversal
• Cache
• Concurrency
• Schema Control and Data Migration
• Transactions (Commit / Rollback)
• Single, Consistent View of Data
• A Practical Example
• Logical Schema
• Message Class
• Attachments and Relationships
• Sender, Recipients, CC Lists and Addresses
• Physical Data Placement
• Using Databases and Containers for Fast Archival and Deletes
• Using Databases and Containers for Fast Queries
• Using Databases, Containers and Range Lists for Parallel Queries
• Hardware Architecture Design and Sizing
• Objectivity/DB Terminology

Using Databases and Containers for Fast Queries: Furthermore, finding data by time will be much easier, since it’s logically and physically organized this way. This is a huge benefit for this application, because time is a major search criterion for almost all queries.

We’ll accelerate queries that have a time filter by creating and maintaining time metadata for all the databases. We’ll simply create a special database and populate it with a list of databases we’ve created for the data. Each time we create a new message database, we’ll add the entry to our metadata and include the time range for it.

When we query the database for a given time period, we’ll first look at the list of databases and find those that match the time period we’re looking for. We can then avoid searching databases that we know will have no relevant data.

We can carry this further by maintaining metadata for all the containers in a database. Each time we create a new database, we’ll create a special metadata container that will contain a simple list of all the message containers in the database and the time period each one represents.

Each time we create a new container of messages, we’ll add that container and its time period to the list. In this example, we’ll assume that each database and container has a discrete and predictable time period. For example, each database could represent a particular hour and contain 3600 containers, each representing a second’s worth of messages.

These ranges lists are very similar to the skeletons of a b-tree index, but they have several advantages. Let’s look at the costs of these range lists.

Each entry in a list requires 24 bytes – 8 bytes for the start time, 8 bytes for the stop time and 8 bytes for the OID to the database.

If we assume each database represents an hour of data, the requirements for the two-week online storage can be calculated as follows:

DB List Metadata Storage Requirement
= Number of Days * databases/day * number of streams * 24 bytes
= 14 days * 24 databases/day * 60 streams * 24 bytes
= less than half a megabyte

Container List Metadata Storage Requirement
= Number of Seconds/Day * 24 bytes * number of databases
= 3600 * 24 * 24 databases/day * 14 days * 60 streams
= approximately 1.74 GB