|
Relational Database Management Systems (RDBMSs) have been very successful, but their success is limited to certain types of applications. As business users expand to newer types of applications, and grow older ones, their attempts to use RDBMS encounter the "Relational Wall," where RDBMS technology no longer provides the performance and functionality needed. This wall is encountered when extending information models to support relationships, new data types, extensible data types, and direct support of objects. Similarly, the wall appears when deploying in distributed environments with complex operations. Attempts to scale the wall with relational technology lead to an explosion of tables, many joins, poor performance, poor scalability, and loss of integrity. ODBMSs offer a path beyond the wall. This paper measures the wall, explains what model and architectural differences cause it, how to foresee it, and how to avoid it.
The Wall: Where an RDBMS breaks down
The generation of Relational Database Management Systems (RDBMSs) has brought many benefits to users, including ad hoc query, independence of data from logical application, and a large variety of front-end graphical user interface (GUI) tools. It has served a large number of business applications, and the industry has grown to over $4B annually, including tools. Why, then, should we look beyond RDBMSs? We should do so only when necessary to s upport new kinds of applications, new media data types, relationships, distribution, and scalability. In fact, most applications have never used RDBMSs, and many that have are now looking for a better solution, such as ODBMSs.
Most Applications are not served by RDBMS
Now three decades old, relational technology is showing signs of age. Although it works quite well when supporting simple, tabular data models, with short, simple operations, and centralized data storage and access, as in online transaction processing, or OLTP, anything beyond that encounters the "Relational Wall." This phenomenon is the result of applying the wrong tool (in this case, RDBMS). One might, for example, try to use a screwdriver to pound nails into a wall, and some nails might actually go in, but in the process many nails would likely break, along with screwdrivers and walls. Instead, using the right tool, a hammer makes the job much easier.
The relational wall is exactly the same; i.e., it is the result of using a table-based DBMS for non-tabular data, or a central server DBMS for distributed applications, or a centralized (and hence non-scalable) DBMS for large, enterprise scalable applications. The term "wall," though common in the literature, is a bit misleading, in that there is not a specific point where good turns to bad. Rather, as the complexity of the application increases, the mismatch between the RDBMS and the application grows. The same happens as data model complexity increases, as more relationships are managed, and as more distributed, scalable access is needed. The result is an explosion of tables, with slow joins between them, complexity difficult to manage, integrity loss, performance loss by orders of magnitude, all increasing. The user is left trying to squeeze his applications into tables, much like squeezing round pegs into square holes.
This wall is specifically a rapid rise exec ution time (slower performance), measured as complexity of the application increases. However, as we'll see below, it is also a rapid rise in the difficulty to change (loss of flexibility) the application and database. Also, a similar effect occurs in terms of extensibility; i.e., as complexity rises, the ability to extend applications, data models, and existing databases rapidly decreases. All these are aspects of "the relational wall."
Detailed measurement of the wall, and visual illustration is in the benchmark section, below. First, however, we'll review the concepts at a higher level, starting with a simple, but quite illustrative, example. Suppose you wish to store your car in the garage at the end of the day. In an Object DBMS (ODBMS), this is modeled with an object for the car, another for the garage, one operation "store," and you're finished. In a relational system, on the other hand, all data needs to be normalized; i.e., it must be flattened to primitives and sorted by type.
|
