Object Oriented Database Learning Center

Performance - Object Oriented Databases vs Relational Databases

Object Oriented Database vs Relational Database

Performance

At runtime, disassembling and reassembling the automobile from its primitive components takes time. The more complex the structure, the more time. Any nested structures or varying-sized structures require multiple RDBMS tables, and joins between them. Similarly, any relationships require joins. The join, although it's quite flexible, is the weak point of relational technology because it's slow. It requires a search-and-compare operation, which takes time, and gets slower as the database tables get larger. (For more on this, see the next section.) Instead, all such complex structures, even dynamically varying-sized ones, are directly modeled as objects in the ODBMS, whose storage manager understands and is optimized to efficiently manage such structures. In addition, wherever the object model includes relationships, these are direct. There is no need to do the slow search-and-compare of the joins. Direct relationship traversal can literally be orders of magnitude faster (see examples below and benchmark). The more relationships you have, the more you'll benefit from an ODBMS.

A high-level comparison of DBMS architectures is useful to clarify the differences between relational, object, and objectrelational technology. Simplify DBMS architecture into a front end and a back end. Either of these may be based on either relational or object technology, yielding four possible combinations, as illustrated. If both front and back ends are relational, this gives a typical RDBMS. Similarly, if both are object, this gives a typical ODBMS.

An object front end layered over a relational back end is what's often called object-relational (ORDBMS). There are some new products in this area (UniSQL, Informix Illustra), and it's also the future direction of the major relational products (Oracle, Sybase, etc.). It's easy to understand why: it's very difficult to change the core engine technology of a DBMS, but very easy to add layers over it. These object layers can add functionality; e.g., they can offer additional data types and can ease integration with other object systems. However, the back end is still based on tables, so the front-end objects must still be flattened, disassembled into those tables, as in the car example above. If the application's data is simple and tabular, this is not a problem, but if it's more complex, the same performance problems remain.

For completeness, a relational front end may be layered over an object backend, as in the Objectivity/SQL++ product (see right-most column of figure). This is not intended to displace the all-relational (left-most column) approach. Rather, for those users who need the object backend, because of complex information, relationships, or distribution and scalability, this adds a familiar interface to support ad-hoc query and front-end GUI tools (based on ODBC). Besides extra functionality, this allows users who are familiar with SQL or such ODBC tools (PowerBuilder, Visual Basic, etc.) to immediately use ODBMS systems with no extra training and to share the same objects with C++, Java, and Smalltalk programmers.

This display of different architectural approaches leads some to wonder what is lost. RDBMSs offer many capabilities, including data-independence (allowing the automobile in the above example to be rebuilt into a different vehicle), views, SQL query, and a strong mathematical foundation that allows proving theorems on query optimization. The answer is that nothing is lost. These capabilities, and other RDBMS capabilities all continue to be available to the ODBMS user. The automobile parts may be searched by range of attribute values (e.g., all pistons with tolerances between x and y, made in Korea, etc.) exactly as in RDBMSs, using the same indexing techniques (b+ trees, hash tables, keys, etc.). Queries may be performed using the same standard SQL query language. All aspects of SQL may be used, including views, DDL (create table creates an object c lass, usable in C++ and Java), DML (insert, update, delete), triggers and stored procedures (actually for more general, via object methods), and security (grant, revoke) not only at the level of every attribute but also every method, allowing certain users and groups to be restricted to accessing only certain objects and accessing them only through certain methods, enforcing encapsulation and rules, guaranteeing integrity. The automobile's parts may be reassembled in arbitrary fashion, just as in the RDBMS case. The difference is that, once assembled, the ODBMS can capture the knowledge of that assembly, so later use of it will not require reassembling (searching, joining, etc.).

The mathematical foundation of relational theory has been quite useful academically for proving theorems, but in practice it is only useful for applications with simple, tabular data structures and simple operations. For these applications, the SQL query mechanism applies directly, and the optimizers directly apply to the user's problem. However, in most cases the application's data structures are not simple tables and its operations are not limited to simple, disconnected SELECT, PROJECT, and JOIN. In these cases, the application programmer must first translate (flatten) his problem into these primitives. The complexity of the problem is, in fact, managed completely by the application programmer, while the RDBMS, confident in its theorems, works only on the resulting primitive decomposition. The mathematical world of the simple RDBMS models do not apply to the original application problems. The application programmer is left to whatever devices he can manage on his own. In short, the complexity, whatever it is, is inherent to the application. With an RDBMS, all that complexity is left to the application programmer. With an ODBMS, the DBMS itself helps manage the complexity. In the following two sections, we'll examine the underlying differences between RDBMSs and ODBMSs in order to understand the source of their different behaviors. First, we'll examine the information model differences, including:

• Relationships
• Varying-sized data structures
• User-extensible structures
• Flexibility and efficiency of structures
• Encapsulation of operations for integrity, quality and cost reduction
• Complex queries

Here we'll see how the relational wall can appear not only in performance, but also as a barrier to modeling complexity, extensibility, and flexibility. Then, we'll examine architectural differences typical of RDBMSs and ODBMSs, including:

• Caching
• Clustering
• Distribution
• Scaling, Bottlenecks
• Dynamically tunable locking granularity
• Legacy integration
• Safety and integrity

These show how the relational wall limits the user's ability to adjust the architecture of his application to fit his computing environment, to take advantage of the new, powerful microcomputers, to tune his system to fit his needs, and to maintain necessary integrity.

We'll follow with a description of a benchmark comparing a leading RDBMS with a leading ODBMS (Objectivity/DB), showing the relational wall quite explicitly. Then, we'll review a few successful production users of ODBMSs, showing in each case why they benefit from the ODBMS. This includes applications in telecommunications, financial services, internet/intranet/web information systems, multimedia systems, document management, enterprise-wide integration, manufacturing, and process control.

Object Oriented Database Learning Center