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

Basic Approaches to Utilizing Containers: One of the key elements of designing a system using Objectivity/DB is the mapping of the Application Object Model onto the Objectivity logical storage hierarchy and thus taking advantage of the underlying physical implementation. We will cover two of these, the Container Pool Pattern and the Data Acquisition Pattern in some detail.

Container Pool Pattern: The concept of container pools is a very simple and useful one. It is basically the generic version of the approach taken by the RentalFleet example, explained below.

In designing and implementing a database in Objectivity/DB, you create a pool of containers at database creation time that will be large enough to contain all objects that the database may be required to hold for the foreseeable future. The trick is to use basic probability to calculate how large this pool of containers will need to be for your application.

If your application has a worst case scenario of 12 clients needing to perform updates at any given moment and you wish to calculate the probability that there will not exist any update locking contentions if you use 1000 containers, you can do so as follows:

Probability=(1000!/(1000-12)!)/(1000^12 )

which works out to approximately 93.58%. Increasing the number of containers to 10,000 will increase the probability of no contention to approximately 99.34%. Even if there is contention, ODBMS updates are usually very fast. Recall that readers do not block writers in Objectivity/DB.

The use of container pools can be quite straightforward. Picking a container from the pool at random or by round robin assignment are such methods. You may find the random method in the d_session class (available from Objectivity infocenter) useful. Or you can use more sophisticated schemes including hashing or named containers or containers with specific purposes. We will propose a pattern utilizing some of these ideas in the next section.

Using the object model below, we will step through the example of an automobile rental fleet.

Consider the RentalFleet example. Let us assume that we are dealing with a worldwide system of RentalFleets. A RentalFleet is an organization that rents vehicles of different classes. The idea is that each RentalFleet organization keeps data for vehicles at each location at that location itself, i.e. in a database that resides at that location. Therefore the Rent-a-Jalopy company would have databases in each location it served, say San Francisco, San Jose and London’s Heathrow airport. It is also possible to return a vehicle to a different location then the one from which it was rented. Furthermore, Rent-a-Jalopy is a tight organization which obtains its vehicles from Ace Rent-a-Car.

Assuming that both Rent-a-Jalopy and Ace Rent-a-Car are in the same federated database, we would have a situation like the one below.

Now we can think about the containerization strategy. On a per location basis, if we put all vehicles in one container then this would only work if there is only one updating process at any time. This is probably not the norm. Next is the strategy to spread the vehicles across a number of containers to increase concurrency and therefore throughput. You may think of splitting all the vehicles into containers which represent the class of car.

There would be economy, compacts, mid-size, full-size, luxury, SUVs, minivans and trucks as the different classes. This will certainly spread the vehicles across a number of containers. However if San Francisco is hosting the Fortune 100 top CEOs, they may all arrive together wanting the luxury cars! There will be conflicts accessing the luxury cars container. We therefore need a different clustering strategy.

We can use simple probability to determine the number of containers that would be needed. Let us say that the maximum number of operators at any counter of any location is 10. The minimum number of containers that would be needed in such a scenario would be 10. However, allowing for collisions in our imperfect world, we could set the number of containers in this application to some factor larger than unity (such as two) times the number of operators. Now we can be reasonably certain that we are going to get a good degree of concurrency without going to the extremes of one object per container.