Home

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?

Objectivity/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.