FAQ - Understanding Objectivity/DB

Printer-friendly version
Introduction to Objectivity/DB
What is Objectivity/DB?

Objectivity/DB is a distributed object database management system (ODBMS). As an ODBMS, Objectivity/DB is ideal for applications that require complex data models. As a distributed ODBMS, Objectivity/DB supports large numbers of users and provides high-performance access to large volumes of physically distributed data.

Objectivity/DB manages data transparently to high-end applications. Its distributed database architecture provides scalability as well as performance. This architecture supports a wide range of application architectures, including client/server, mixed-tier, and service-oriented.

Objectivity/DB integrates easily with application software. It allows you to directly store and manage objects through standard language interfaces—such as, C#/.NET, C++, Java, Python, Smalltalk, SQL and XML—using traditional programming techniques and tools.

Integrates into your existing environment. Objectivity/DB also integrates into existing computing environments. It supports complete interoperability across major hardware platforms and operating systems. Through its ANSI-standard SQL interface, you can leverage your SQL-programming knowledge to use popular client/server tools compliant with Microsoft’s Open Database Connectivity (ODBC) interface.

ODBMS versus RDBMS
When should I use Objectivity/DB rather than an RDBMS?

If you can solve the problem with an RDBMS without a lot of effort and also achieve the performance, throughput and scalability that you need then there's no compelling reason to use an ODBMS. If any of the following conditions are met then you should consider using Objectivity/DB:

  • Complex Relationships If there are a lot of many-to-many relationships, tree structures or network (graph) structures.
  • Complex Data If the data has multiple varying length components, particularly multi-dimensional arrays, arrays of structs or binary streams.
  • Distributed Databases If the databases need to be geographically distributed, used in a detached mode or are accessed from a processor grid [or "farm"].
  • Multiple Languages or Platforms If the system will use multiple languages and/or platforms.
  • Repetitive use of Large Working Sets of Objects If your application performs many successive transactions on the same "working set" of objects.
  • Massive Scalability If you have very large amounts (Terabytes or Petabytes) of data, databases at large numbers of sites or a very large numbers of clients.
  • Expensive Mapping Layer There is no need to decompose objects to fit into rows and columns; or to give up on doing ad hoc queries by storing binary data as BLOB [Binary Large Objects]; or to construct artificial JOIN tables to express many-to-many, tree and network relationships.
Why is Objectivity/DB faster than an RDBMS?

Ojectivity/DB is faster than an RDBMS in many instances. It may have equivalent, or even slightly worse, performance in some cases. It is almost always faster than an RDBMS in the following cases:

  • Complex Relationships If there are a lot of many-to-many relationships, tree structures or network (graph) structures then Objectivity/DB will traverse those relationships much faster than a relational database. If an object is linked to N other objects then an RDBMS will probably perform 2*N B-Tree [index] lookups and 2*N logical reads (into the rows of the JOIN and the target tables) to retrieve information from those other "objects". Objectivity/DB will do 1 B-Tree lookup and N+1 logical reads.
  • Complex Data If the data has multiple varying length components, particularly multi-dimensional arrays, arrays of structs or binary streams then Objectivity/DB has a very powerful Storage Manager that is built to manipulate those kinds of data. Relational databases are designed to manipulate data structures that neatly fit into rows and columns, where the latter are preferably of fixed length.
  • Distributed Databases Central servers are convenient to manage and describe, but they represent a performance bottleneck and require extensive monitoring and tuning. If it makes more sense to distribute data across machines or sites then Objectivity/DB offers a powerful and simple solution. Databases can be distributed and/or replicated around a network. They may be at different sites or simply spread out across multiple data [page] servers. The clients are presented with a single logical view of all of the objects in a federation of databases. The clients do not need to know where the data resides. This makes it relatively easy to manage an Objectivity/DB distributed configuration, as the administration commands can be run from any authorized machine in the network.
  • Multiple Languages or Platforms Objectivity clients and servers can run on a mixture of platforms (Linux, Unix, LynxOS or Windows). The clients can use C++, Java, Smalltalk, SQL++ or ODBC interchangeably. Objectivity/DB adds no constraints beyond those imposed by the various languages, e.g. Java and Smalltalk do not support multiple inheritance, whereas C++ does. SQL and ODBC do not support inheritance, but the Objectivity/SQL++ and Objectivity/ODBC interfaces extend SQL to handle inheritance.
  • Repetitive use of Large Working Sets of Objects If your application performs many successive transactions on the same "working set" of objects then it may be possible to cache thoses objects locally, avoiding the need for disk I/Os and moving data across the network. Objectivity/DB uses smart caching to reuse objects that have been cached locally and that have not been outdated by other transactions.
  • Massive Scalability The largest known relational databases are around 100 Terabytes. The largest Oracle database is believed to be around 50 Terabytes. Stanford Linear Accelerator Center built a Petabyte+ Objectivity/DB database. Most relational servers slow down considerably as the number of concurrent transactions approaches tens of thousand. Objectivity/DB is used in distributed telecom applications that support peak loads of 150,000 active users per rack and millions of users across the whole network, such as SprintPCS.
  • No Mapping Layer Objectivity/DB stores objects as objects. It does not need to convert them to serialized ASCII formats or break them down to fit into rigid row and column constructs. It stores many-to-many, tree and network relationships as named bi-directional associations, eliminating the need for JOIN tables. Eliminating the mapping layer not only saves programming time, it means that the objects can be stored and retrieved faster (because there are fewer I/Os) and with fewer CPU cycles.
Why haven't the ODBMS companies overtaken the RDBMS companies?

RDBMSs perform perfectly adequately for many types of applications, particularly in the regular Information Technology domain. ODBMSs target a narrow range of applications, so the potential market size is smaller. A loose analogy is that RDBMS companies are like the manufacturers of internal combustion engines and the ODBMS companies are like the manufacturers of jet engines. The two technologies service different markets, but there is a small degree of overlap. In general, ODBMSs can service all of the applications that an RDBMS could be used for, but the reverse is not true, at least not with anything like the same performance or ease.

The RDBMS companies also have a 15 year lead, so they have a well established and fairly loyal customer base, often with site licenses that conceal the real costs of ownership. Companies have invested a lot of resources and money to learn how to run their RDBMS technology, so they are slow to change technologies. ODBMSs are generally easier to learn and cheaper to own than an RDBMS, so an ODBMS is a more natural choice for a new product or company. The growing number of Java programmers means that ODBMSs can expect to increase their market penetration, but usually at the expense of home grown structured file systems rather than applications that are adequately serviced by RDBMS technology

Performance and Scalability
How fast is Objectivity/DB?

There are many ways of measuring the speed of a database. Unfortunately, almost all of them are only suitable for relational databases. The industry benchmarks on object databases are over ten years old. Objectivity/DB can create new objects and store them on disk at almost the maximum rate that the processor-network-disk configuration can support. In one recent benchmark Objectivity/DB ingested and stored objects at the rate of 32 Terabytes per day. It randomly or sequentially reads data at similar speeds. If a client thread can reuse data that has already been cached in memory then there is no need to read the data from disk (or across a network) in subsequent transactions. Objectivity/DB can be configured with small client caches for streaming data, or with large client caches for repetitive use of large amounts of data. In the latter case, Objectivity/DB effectively becomes an in-memory database.

How much does Objectivity/DB slow down as my database grows?

The time to store and directly access objects stays almost linear as the container, database and federated database sizes grow. Operations that need to scan whole containers, databases or the federation scale linearly. B-tree indices behave in a predictable fashion. However, note that applications can often utilize small, local indices or hash tables within containers or databases, rather than global indices across a whole federation.

What happens if the number of clients increases?

It depends on what they're doing. If they all have to share the same data then the disk holding that data will eventually saturate. It may be possible to replicate the data multiple times to share the load. If they are accessing data on different disks then there is little noticeable effect. Eventually, there may be too many clients for a particular lock server. That problem can be solved by allocating multiple lock servers.

Objectivity/DB Basics
What is Objectivity/DB's storage hierarchy?

There are many ways of measuring the speed of a database. Unfortunately, almost all of them are only suitable for relational databases. The industry benchmarks on object databases are over ten years old. Objectivity/DB can create new objects and store them on disk at almost the maximum rate that the processor-network-disk configuration can support. In one recent benchmark Objectivity/DB ingested and stored objects at the rate of 32 Terabytes per day. It randomly or sequentially reads data at similar speeds. If a client thread can reuse data that has already been cached in memory then there is no need to read the data from disk (or across a network) in subsequent transactions. Objectivity/DB can be configured with small client caches for streaming data, or with large client caches for repetitive use of large amounts of data. In the latter case, Objectivity/DB effectively becomes an in-memory database.

What is a Federated Database?

The federated database is the highest level in the Objectivity/DB logical storage hierarchy. Logically, a federated database contains application-created data in one or more databases. Physically, each federated database exists as a file containing a single system database, which stores:

  • The schema for the federated database.
  • A global catalog of the federation’s application-created databases.
  • Any federation-wide structures (indexes and scope names) created by applications.

The federated database provides unified management of database files and a collection of other Objectivity/DB resources (files and processes):

  • A boot file gives applications the information they need to connect to the federated database.
  • A system database maintains internal Objectivity/DB information such as the global catalog of databases.
  • A lock server is a process that manages concurrent access to a federated database's data.
  • Data servers enable applications to obtain data from distributed databases on local or remote hosts.
  • A journal directory contains files that maintain information for recovering transactions.
What are databases and containers?

A database is the second highest level in the Objectivity/DB logical storage hierarchy. Each database stores an application’s persistent data in structures called containers, which constitute the third level in the Objectivity/DB logical storage hierarchy. Within a container, persistent data is stored in fundamental units called basic objects.

A database is physically represented by a database file, which contains:

  • The database’s default container.
  • Zero or more containers created by applications.
  • A catalog of the containers belonging to the database.

Database files are typically used to distribute related containers and their basic objects to different physical locations in your network.

Most containers are physically embedded in the files of the databases to which they belong. For various reasons, such as keeping the size of database files within manageable limits, an application can choose to store selected containers in their own separate container files. Such containers, called external containers, differ from embedded containers only in terms of their physical representation; a database can logically contain any combination of embedded and external containers. Because all persistent data physically resides in a database file, a system-database file, or a container file, these files are collectively called the data files of a federated database.

Each container manages a group of physical storage pages allocated in the database; the container's persistent objects are stored in binary form on these pages. Some or even all of these physical storage pages also serve as logical pages, which means that they store one or more small persistent objects, or the beginning of a large (multi-page) persistent object.

What is a persistent object?

Persistent objects are the fundamental logical units of data storage in an Objectivity/DB federated database.

Persistent objects are created by applications. Each persistent object has an object identifier (OID) and is an instance of a class. The class may be defined in an object-oriented programming language, or it may be a class defined by Objectivity/DB (for example, ooObj). In either case, the class is described in the federated database's schema.

A persistent object continues to exist and retain its data beyond the duration of the process that creates it. In contrast, a transient object exists only within the memory of the process that creates it; when that process terminates, the transient object ceases to exist.

Technical Overview and Datasheets
Where can I find a quick overview of Objectivity/DB?

You can find a overview of Objectivity/DB in our Technical Overview document. The Technical Overview provides a comprehensive overview, but you should also read the latest datasheets and press releases for the most timely information. The product datasheets summarize the capabilities of each Objectivity product.

Where can I find information about the kinds of application that Objectivity/DB is deployed in?

Take a look at the general and industry focused White Papers, and Case Studies available in our extensive content library. There are news articles about specific customer deployments or industry initiatives in the Press Center.

I've looked at the information on this site and I need more technical details. Can I obtain copies of the technical documentation?

Yes. It's available for free in the Product Download, or you can Contact Us to buy paper copies. If you have specific questions please send them to us at Objectivity Email or call your nearest Sales Office.

Date: 
Tuesday, October 23, 2012
Product: 
Objectivity/DB
Version: 
10.2.1
10.2