Welcome to Objectivity, Inc. -- makers of the industry leading Objectivity/DB object-oriented database management platform, Grid Certified (Levels 1 through 6), and SOA compliant We are the leader in scalable database management solutions for mission-critical, real-time and distributed applications.
Click for print version of this page
Object Oriented Database Learning Center

Configuration Examples

Configuration Examples

Overview

This section describes the following kinds of Objectivity/DB deployment configuration:

  • Standalone processor
  • In Process Lock Server
  • In-Memory Database
  • Network of workstations
  • Client-Server
  • ODBC Server
  • Service Oriented Architecture
  • High Availability
  • Parallel Query Engine
  • High Performance Clusters
  • Geographically Distributed Clusters
  • Grid Enabled
  • Archiving
  • Hybrid

Standalone Processor

This is the simplest kind of Objectivity/DB deployment. Figure 14 (below) shows a multi-threaded application running against its own federated database. A Lock Server running in its own process manages concurrency.

In Process Lock Server [IPLS]

The In Process Lock Server can be used in many of the configurations described later. Figure 15 (below) shows a standalone processor with its own disk and an IPLS linked directly with the Objectivity/DB kernel library and application process. This avoids the overheads of interprocess messaging and context switching.

In-Memory Database

Some applications, particularly in the hard (true) real-time environment, require sub-millisecond access to reference data. As a disk I/O takes at least three milliseconds this data needs to be locked in memory. It can be read into threads that are used to service such queries, e.g. with a thread per area code in a telecom application. Individual objects can be locked into memory with a “pin” operation. Or, the whole thread can be marked as being in “Hot Mode”, which automatically pins pages in the cache.

Another similar class of applications deals with fast moving data that needs to be processed and reformatted before sending messages to other applications or committing a small amount of new data to disk. The transient objects can be managed outside of the cache, or treated as standard, persistent objects that are deleted when they are no longer required. The cache space is automatically reclaimed and used for subsequent operations.

Non-volatile solid-state disk can considerably speed up applications that are primarily in-memory but also need to store small subsets of the data. The journals used for protecting update transactions during the commit stage can also be stored on solid-state disk.

Figure 17 (below) shows a process that is ingesting data, correlating it with reference data, notifying other applications and storing summaries of actions taken.

Although it is not an optimal use of an ODBMS, configuring Objectivity/SQL++ with a very large cache can dramatically improve performance for relational query tools. This is similar to the technique used by In-Memory RDBMSs, such as Oracle’s TimeTen.

Network of Workstations

Objectivity/DB is frequently used in workgroup or engineering environments (see Figure 18 below). One workstation will run a Lock Server for the federation and individual workstations will have local and shared data, accessed via a data server (AMS). Workgroup environments often run without an Objectivity data server.

Figure 18 – One workstation (top left) runs a Lock Server for the federation

Client-Server

If the bandwidth of the connection between the client and the hosts connected to the databases is low (less than 100 Mbit) then a conventional client-server model should be used (see Figure 19, below). A messaging protocol, such as Remote Method Invocation [RMI or Common Object Request Broker Architecture [CORBA] can be used between the client and the server. Objectivity/DB is embedded in the server application code, which runs as a standard client. The In Process Lock Server [IPLS] is often used in this kind of configuration, but it is not a prerequisite.

ODBC Server

Objectivity/SQL++ is an ANSI SQL-3 compliant interface to Objectivity/DB federations. It enhances standard SQL and ODBC with constructs that make it possible to deal with structured fields and mechanisms that exploit inheritance, named relationships and simple object-oriented methods. An application that uses SQL++ syntax in query iterators looks just like any other client, but it is linked with an Objectivity/DB library that contains the extra SQL++ code.

An ODBC application, such as Crystal Reports or Microsoft Office (most frequently Excel and Access) calls an Objectivity/SQL++ ODBC driver. It communicates with a SQL++ daemon process (oosqld) that is engineered as a server application with an ODBC interpretation, execution and response layer. Figure 20 (below) show a typical setup.

The relational client application does not need to know that it is actually connected to a distributed ODBMS. An environment that has many such clients could load balance across multiple SQL++ daemon processes (servers).

Service Oriented Architecture

Many systems are using a standardized three-tier model, known as Service Oriented Architecture, to integrate existing systems and develop new ones. The application server middleware may be proprietary, as in the case of IBM WebSphere and BEA WebLogic, or open source, such as JBoss and Sun Java System Application Server.

Java Platform Enterprise Edition [J2EE] is an interface for writing multitier Java applications. It encompasses several other APIs, such as Remote Method Invocation [RMI]. Java EE Connection Architecture [JCA] is a generic architecture and protocol for connecting to databases and legacy applications. Objectivity for Java includes a JCA implementation that has been validated with the most popular application servers.

The middle tier imposes its own overheads, so care should be taken in choosing between direct interaction with the database and interaction via a service. One solution is to send service requests to the middleware, receive an Object Identifier (which may reference a scaleable collection) and then access the database directly, given adequate bandwidth.

Figure 21 shows an SOA setup that uses an In Process Lock Server [IPLS]. The Application Server may itself be distributed, so the choice of an In Process Lock Server or standalone Lock Servers will depend on the physical environment.

High Availability

A High Availability configuration requires at least two physically independent processors. We discussed standard High Availability configurations early in this White Paper. Figure 22 (below) shows a highly available configuration using three processors and two replicated databases. The Lock Server on Host_1 is active and is in transactional control of the replicated database. The second Lock Server, on Host_2, is running but does not have transactional control. Each database replica has one vote to be used by the quorum resolution algorithm. The second Lock Server (on Host_2) also has one vote.

If one of the two data serving hosts (Host_1 or Host_3) fails the other processor can continue serving data, including updates, as clients have access to a Lock Server and can locate two of the three votes they need for a quorum. The exact mechanics depend on which machine fails:

  • If Host_1 fails then the Lock Server on Host_2 already has the tiebreaker vote. However, it must be catalogued as being in control of the database as the previously active Lock Server is dead. Client processes that were using the replica on Host_1 will automatically pick up the one on Host_3 and the new Lock Server in their next transaction.
  • If Host_2 fails then the tiebreaker vote can be given to the Host_1 Lock Server, which can continue service without interruption as it is already in control of the database. Client processes will not be affected.
  • If Host_3 fails then clients using Host_1 can continue uninterrupted as they can see a quorum of votes. All of the clients can still see the controlling Lock Server on Host_1. Clients that were using the database replica on Host_3 will automatically pick up the one on Host_1 in their next transaction.

If only two processors are available then the situation is altered slightly. Objectivity/HA provides a mechanism for forcing one of the two replicas to have a quorum. The mechanism for determining whether or not a host machine has gone down, or is merely disconnected, is implemented outside of Objectivity/DB.

If there are more than three processors then the whole system can be much more resilient and the failure of individual nodes will be easier to deal with. Most nodes will be unaffected, but nodes using the failed resource may have to rollback and reapply interrupted transactions.

Parallel Query Engine

Standard scan() methods (operations) run synchronously within the kernel. Imagine a federation with these contents:

  • Seven databases named after continents - Africa, Antarctica, Asia, Australasia, Europe, North America and South America.
  • Each database has a container for each country in that continent.
  • Each container has City objects linked to one or more Image objects.

If all that is known is the name of the city and there are no supplementary structures to help locate a specific city then a query that needs to find the Images associated with “London” would have to iterate over all City objects in the federated database. Although the iterator starts returning qualified city objects as soon as they are found the scan is executed synchronously within the kernel. In the worst case, the database and container that includes the city object for a sole occurrence of “London” might be the last ones scanned.

The Parallel Query Engine [PQE], shown in Figure 23 (below) supports a parallelScan() method. It uses remote Query Agents to execute subsets of a query. It has two types of replaceable component:

  • Client side “Task Splitters” – determine the databases/containers to be searched and the degree of parallelism.
  • Server side “Filters” – further qualify an object after it has been selected using standard predicates.

The query described above would use a Task Splitter to direct parallel sub-queries to seven Query Agents located near each country database, i.e. within the same high-speed network, or in the host connected to the database files. The seven Query Agents would look for containers holding information for City objects called “London”. They would find 5 in Africa, 3 in Australasia, 1 in Europe, 20 in North America and 2 in South America.

As each country/database specific Query Agent scans the containers in its target database it finds City objects and returns them to the client-side PQE subsystem, which then presents them to the application via the iterator. The client receives objects much faster than an individual process could find them. The client then navigates to the Images.

This mechanism is radically different from the one used by conventional database servers. They use knowledge of the probable physical whereabouts of candidate items and population statistics, rather than the tunable search clues that PQE uses.

The replaceable Filter component in each agent could further refine the search, perhaps applying an image recognition algorithm and searching for “people wearing red hats”. The replaceable Filter component can perform any function desired, including accessing other Objectivity/DB databases and external data sources.

High Performance Clusters

Many High Performance Computing environments deploy clusters of single or multicore processors. They may be tightly connected via special backplanes and shared memory, or loosely coupled via high-speed switches. The hosts containing single or multiple processors may: be locally connected to their own filesystems; use a distributed filesystem, such as CXFS; or be connected to a common storage infrastructure, such as a Storage Area Network or Network Attached Storage.

The Objectivity/DB clients and servers can be distributed across the processors, with Lock Servers and data servers located close (time wise) to the clients they are serving or the resources they are making available. Shared memory can be used to pass preloaded Objectivity/DB caches (contexts) between threads belonging to the same process.

Figure 24 (below) shows a High Performance Cluster that was used to ingest, fuse and service queries on a 120 Terabyte federation that ingested data at the rate of 3.2 million objects per second (one Terabyte per hour) for a benchmark. Note that the processors were relatively low speed, to meet a heat dissipation limitation. The configuration used a SGI Numalink backplane, a Brocade switch, the distributed CXFS file system and an LSI Logic SAN. The ingest/fusion processes used their own caches, rather than the CXFS or SAN caches.

Much larger clusters have been deployed in government and scientific applications. The Stanford Linear Accelerator Center’s BaBar Project used 2400 processors to work with over a Petabyte (compressed to 984 Terabytes) of data for their high-energy physics experiment.

Geographically Distributed Clusters

We briefly discussed geographic and mobility issues in the Architecture Primer section and showed an example in Figure 13. Telecom hardware is generally grouped according to the usage requirements. The Operations Support Services will be centralized or geographically dispersed. The Network Operations Center will be centralized with one or more emergency standby facilities. Local centers will house large communications switches and resources for specialized services, such as voicemail, photo sharing and on-demand music and video serving. Some equipment, such as broadband Internet provision, may be located in Central offices close to the subscriber, or even in their home or office.

Figure 25 (below) shows a geographically distributed telecom network. The Corporate Headquarters and Regional Centers would most probably use Service Oriented Architecture clusters. Each Intelligent Network node would use clusters of application servers or standalone processors.

Objectivity/DB is most frequently used in the lower layers of telecom networks, in subsystems such as Advanced Intelligent Networking and Element Management Systems, but it has been gainfully deployed in all of the above environments by companies such as:

  • Iridium - Low Earth Orbit satellite communications network operations center) using CORBA and Objectivity/DB
  • Alcatel – Intelligent Networking Service Control Points
  • SprintPCS - CDMA wireless base station controllers
  • Com21 - advanced cable services
  • Fiber optic multiplexers (Siemens)
  • Optical switches (Ciena) and broadband delivery (Navini Networks).

The process control and automation, medical instrumentation and defense markets have also deployed Objectivity/DB in geographically distributed and mobile environments, including:

  • Dräger Medical’s Zeus® - high precision anesthesia system
  • L-3 Communications – Network Centric Collaborative Targeting system
  • LMS – Fetal monitoring system
  • NEC – Wafer fabrication control
  • NGMS – THREADS, a Human Intelligence correlation system.
  • Siemens Advanced Building Technologies - building automation system.

Grid Enabled

Objectivity/DB has been used in distributed configurations in many computational and data grids. It has been validated as being compliant with the Level 6 requirements of the “Ready for IBM Grid Computing Systems” program. Objectivity/DB client applications were submitted to a grid batch program scheduler supplied by Platform Computing. They were started in the grid environment, located their data and Lock Servers and ran to completion, returning their results to the nodes that submitted the jobs. Figure 26 (below) shows a grid deployment. The diagram omits the data return paths for simplicity’s sake.

Objectivity/DB has also been validated with IBM WebSphere 6, which is grid-enabled. This allows clients to request services from WebSphere and use grid enabled Objectivity/DB services.
Future releases will allow Objectivity/DB clients and servers to communicate over standardized grid infrastructure. Objectivity/DB will use virtualized servers. The server processes and database files will be able to be administered using standard (Open Grid Services Architecture) grid services. This is a natural evolution as Objectivity/DB is a fully distributed DBMS and the leading RDBMSs are not.

Archiving

Many environments require immediate access to a subset of the available information and can access archives for additional or older material. The Objectivity/DB Advanced Multithreaded Server [AMS] can access the High Performance Storage System or other mass storage archival solutions via the Objectivity Open File System layer. The only impact on applications is that they should be prepared to receive an exception informing a client that offline data is being located and brought online.
The client to AMS messaging protocol allows the client to send additional clues to the storage infrastructure, such as a policy selection. Examples might be: offline this now; retain online until accessed at least once; retain for 31 days; cache for random access; or make two additional copies as soon as possible.

Some storage devices do not allow the user to deploy application code inside them. However, any device or system that runs a Network File System [NFS} daemon process (nfsd) can act as a data server for Objectivity/DB. It is impossible to use the NFS protocol directly as it does not guarantee the timeliness of simultaneous read and update operations, but the nfsd lightweight server has enough functionality to support basic remote access requirements. AMS is preferred for write intensive applications and is essential for the support of Objectivity/DB database replication and High Availability functionality. Figure 27 (below) shows a mixed environment, with local, AMS, HPSS, distributed file system (CXFS etc.) and nfsd file handling.

Hybrid

We have reviewed a wide variety of deployment configurations, ranging from standalone to grid enabled and real-time in-memory to offline archive handling. All of these configurations use the same version of Objectivity/DB and interoperate across platforms and with other configurations. Even the standalone configuration can serve data to other clients when it is connected to a network, using an nfsd daemon as a data server.

The same application can run in many different deployment configurations with zero or a few modifications. There are minor considerations that are unique to disconnected machines, offline storage or the message handling that is always present in server side applications. However, these aspects can be handled at a high level in an application process, allowing the majority of developers to concentrate on the task at hand and to use the full power of Objectivity/DB to help solve problems.

Figure 28 (below) is an Objectivity/DB customer’s depiction of an advanced data fusion system that deploys Objectivity/DB at multiple locations in its architecture.

Summary

We have shown that it is easy to configure Objectivity/DB to suit a whole range of performance, throughput, geographic and other parameters. The architectural features that make this possible are: Single Logical View; Simple Distributed Servers; and Replaceable Components.

The ability to deploy the same DBMS at multiple locations and provide all users with a single logical view is a powerful tool when selecting architectural components. It opens up new possibilities for making data available in a timely, efficient and safe manner. The single logical view allows database administration tools to be run anywhere that they have permission to access resources that need to be installed, updated or moved. The same Objectivity/DB libraries can be installed at all of the locations that need them, without having to worry about mobile, enterprise or other capability and licensing issues.

The architecture uses simple servers that improve scalability and reliability and are easy to install and maintain. Replaceable components can increase the power and functionality of a system without moving the full burden of support to the application developer.


Object Oriented Database Learning Center