Objectivity/DB Technical Details & Support

Objectivity/DB logo


Objectivity/DB is a scalable, high performance, distributed Object Database (ODBMS). It is extremely good at handling complex data, where there are many types of connections between objects and many variants.


Distributed Architecture

  • Objectivity/DB manages a fully distributed database, presenting a Single Logical View of objects that may be distributed anywhere within a network of machines.
  • It is also a fully distributed processing system, where clients transparently access the appropriate lock, data and query servers.
  • Lock servers can be built into an application server in order to increase performance and reduce network traffic.
  • These features increase the scalability, throughput and reliability of systems built using Objectivity/DB. A system can scale-out as well as scale-up.



  • Objectivity/DB uses plugins to allow developers to tailor their applications to their needs. There are plugins for:
    • Security hooks
    • Parallel query tasking and result filtering
    • Adapting the backend of data servers to suit novel file systems or storage devices.
  • Replaceable components offer much of the flexibility of an open source solution and also allow Objectivity to guarantee the core performance and reliability of your applications.
  • We will also support systems with user extensions as long as our standard tests can be run when they are present.


Standard Interactive Development Environments

  • Objectivity/DB uses standard compilers and tools.
  • Objectivity/Assist is a set of Eclipse plugins that make it easier to develop, test and debug application code.


Platforms and APIs

  • Objectivity/DB runs on 32 or 64-bit processors running Linux, Mac OS X, UNIX (Oracle Solaris) or Windows.
  • There are C++, C#, Java and Python APIs.
  • All platform and language combinations are interoperable. For example, objects stored by a program using C++ on Linux can be read by a C# program on Windows and a Java program on Mac OS X.
  • Objectivity/DB generally runs on POSIX filesystems, but there are plugins that can be modified for other storage infrastructure.
  • Objectivity/DB client programs can be configured to run on a standalone laptop, networked workgroups, large clusters or in grids or clouds with no changes to the application code.

Object Handling


Object characteristics and placement

  • Objects are assigned a unique 64 or 32-bit Object Identifier (OID) upon creation.
  • Objects have a fixed length (including zero length) “body” and zero or more varying length components (VArrays). The elements of a VArray may be scalars or structs.
  • Inherited object classes have a single, contiguous body with all of the attributes of that class and the parent classes.
  • Objects can be grouped into containers, which can be grouped into databases, which are grouped into a federated database (federation). The federation provides a Single Logical View of the objects, no matter where they are physically stored.
  • Containers full of objects (such as all of the objects in a document) may be stored in dedicated files or a file shared by all of the containers in a database.
  • The physical placement of objects is specified using Placement Management Directives (XML).
  • Objects and associations typically incur a physical space overhead of around 20%, rather than the 200% needed by most RDBMSs when they are handling inheritance and complex structures.


Object Capabilities

  • Objects can be created, opened for read or update access, or deleted.
  • Objects may be linked to other objects using 1:1, 1:many, many:1 or many:many typed uni-directional or bi-directional links.
  • Objects may be copied within a container, or be moved to another container/database.
  • C++ objects can be versioned (linear or branching), with a single object representing the whole pedigree.
  • Java objects support the same functionality, using slightly different semantics.
  • Links between versioned objects can be copied, moved or dropped when an object instance is versioned.
  • Objects can be accessed via B-Tree indices, by name, or via scalable hash, tree, list and other collections.


No Mapping Overheads

  • Mapping the objects used by languages such as C++ and Java into a relational database requires extra work on the part of the database designer and application programmers.
  • RDBMSs don’t support inheritance, which requires multiple tables and join tables that slow down queries and complicate the creation, updating and deletion of objects.
  • RDBMSs are also not very good at handling complex relationships. They require join tables and indices and handling graph structures is cumbersome at best.
  • Using Objectivity/DB rather than an RDBMS will typically shave 25-35% off of the database related development effort.


Schema Manipulation

  • System requirements evolve. Objectivity/DB schemas can be predefined or dynamically created and evolved. There is a wide variety of methods for handling the physical migration of affected object instances in a federation.
  • Existing object instances may be migrated in a single transaction, or when discovered, or be left intact, with the object being presented in its new shape. This is generally only necessary when the object is on read-only media.

Standard and Relaxed Transactions


ACID and Relaxed Transaction Semantics

  • Objectivity/DB transactions are ACID (Atomic, Consistent, Isolated and Durable) by default.
  • Objects are locked in groups, rather than individually. This significantly reduces network traffic, queueing and deadlocks, increasing system throughput.
  • Java applications can take advantage of distributed transaction management services in order to synchronize updates to multiple datastores, such as Objectivity/DB and MySQL.
  • Objectivity/DB also supports a Multi-Reader, One-writer (MROW) transaction mode that allows readers to view the committed, consistent view of a group of objects whilst another user is updating the same group of objects. The readers are seeing a consistent, but potentially stale, version of the group.
  • If an MROW reader attempts to update an object that is locked for update by another user the client application will throw an exception that can be handled by waiting and then refreshing the cache. Readers will never see inconsistent data or be able to interfere with other transactions, other than potentially delaying the ability to apply updates. Other NoSQL DBMSs with variable consistency, acidity and persistence may present erroneous results.


Flexible Caching

  • Objects are read from persistent storage in fixed size blocks (“pages”). This allows the clustering of related objects and reduces the overall number of I/Os required to complete a task.
  • The client side cache, which is allocated per thread or process, can be configured to a set size or be allowed to grow in appropriate increments.
  • Objects in the cache are retained across transactions (“Smart Caching”), so they only need to be refreshed if another user has updated them. This is particularly important when handling relatively static data, such as maps and equipment configurations or designs.

Powerful Conventional and Graph Queries


Synchronous and Parallel Query Support

  • Objects can be accessed via iterators (inherited classes and methods used in a loop) that specify the type of object to be found, the range of the scan and any predicates to be satisfied.
  • Queries can be executed synchronously within the process/thread or in parallel using remote, asynchronous query agents. There are plugins for specifying how to task the query agents (unless standard placement policies are to be used) and for refining the results before they are returned to the client.
  • Unlike an SQL query, which manifests a complete tabular view before returning any results to the client, Objectivity/DB iterators start returning qualified objects as soon as they are found. This reduces latency and eliminates the need for query timeouts.


Relationship Analytics

  • The OID and relationship mapping make Objectivity/DB extremely efficient at handling navigational and pathfinding queries. As a simple example, if an object is connected to N other objects, a query that is to return information from each of the connected objects will require only 1 B-Tree or hash-table lookup and 1+N logical reads. The equivalent RDBMS query would require as many as 2*N B-Tree lookups and 2*N logical reads.
  • Objectivity/DB pathfinding queries find the shortest or all paths between two designated objects, which is something that RDBMSs and most other NoSQL DBMSs handle very inefficiently.
  • Navigational or pathfinding queries can be qualified with predicates involving object attributes and connection types.
  • Note that complex graph-structured queries may be more easily handled using Objectivity’s InfiniteGraph, a Graph Database based on Objectivity/DB.

Low Total Cost and Risk of Ownership


Near-Zero Database Administration

  • Objectivity/DB has comprehensive tools for inspecting data, copying or moving databases, exporting and importing data and handling backups and restores. However, Objectivity/DB was architected to require as little administrative effort as possible.
  • This makes it possible to embed Objectivity/DB in locations which must run unattended or without the ability to add extra storage for journals etc.
  • We also believe that database administrators make the best database designers - prevention is better than cure!


Production Proven

  • Although Objectivity/DB has State-of-the-Art capabilities, such as: sharding; distribution; NoSQL APIs; Big Data and Fast Data handling; graph manipulation; parallel graph queries; relaxed transactions; large memory; and cloud configurability; the first commercial applications with Objectivity/DB embedded in them went to market in 1990!
  • Objectivity/DB was the first DBMS to run on 64-bit processors and Windows NT.
  • Objectivity/SQL++ (available upon request) was the first ODBMS to embrace the industry standard query language.
  • Objectivity/DB was the first DBMS to publicly manage a system with over a Petabyte of data (at SLAC in 2000, for the BaBar Project). Average RDBMS sizes were around 10 Terabytes at that time.
  • Objectivity/DB servers (handling locks, data and query fragments) are hardened against common security attack techniques, such as Denial of Service attempts.
  • Objectivity/DB is deployed in 99.999% reliable telecom and process control equipment, satellite control systems, design and simulation applications, logistics systems, government (Intelligence Community and DoD) systems, Big Science projects, financial systems, manufacturing and building monitoring and response systems, medical equipment, advanced analytics systems and social network web-based applications.
  • Every feature of our product has been introduced in response to customer needs or new technologies and standards. We are primarily a software engineering company.
  • Objectivity was a founding member of the Object Management Group (OMG) and Object Database Management Group (ODMG) and has collaborated in many similar industry initiatives.


Partners and Support

  • We have technology partners in the computing and storage infrastructure, very large memory and communications equipment domains, data blending (ETL or ELT) and visualization fields.
  • We have long-term partnerships with major defense contractors and offer GSA contractual arrangements.
  • Objectivity has a Platinum Standard reputation for Customer Support. We will get you to deployment quickly and are responsive and agile when our customers or partners need features to be enhanced, added or fixed.
  • We offer standard and custom support, along with Professional Services Packages that can streamline your training, design, development and deployment processes.