Welcome!

Eclipse Authors: David Smith, Bob Gourley

Related Topics: Java, XML, Weblogic, Eclipse, AJAX & REA, Oracle

Java: Article

Column Store, In-Memory, MPP Databases and Oracle

How Oracle implements latest developments in database world

( For latest information on Oracle 12c database update please refer to the following article: Oracle 12c Database and How It Relates to SAP Hana )

RDBMSs are stable and mature products. While there is nothing radically new on horizon that would challenge Codd's relational theory and related advances in data processing there are some developments that force established vendors like Oracle to come up with new features and products.

Column Stores and Oracle
Column store concept has been around for quite a while. Vendors like HP Vertica grabbed some market share in data warehousing segment with their column store,  MPP databases. Oracle Exadata is offering Hybrid Columnar Compression -  solution that modifies Oracle standard row based storage (NSM, or row-major) into proprietary format that is probably closer to PAX (as opposed to DSM) classification. Rows of data are reorganized, broken down into columns, compressed and stored in Compression Units which consist of multiple Oracle data blocks. CU is physically implemented as a standard Oracle single column chained row. (Description of CU layout is based on marvelous article written by Oracle expert  Jonathan Lewis).

This is truly hybrid design, i.e., column store is implemented on top of a standard row store.

It is not in the scope of this article to discuss pros and cons of this implementation from performance, locking, compression and other points of view. I will just mention that HCC requires change in standard operating procedures and methods.

MPP (shared nothing) and Oracle
Column-based stores like HP Vertica use Multiple Parallel Processing, shared nothing design to enhance performance by bringing processing closer to data, i.e., data is processed in parallel on the node where it resides. Volume of data that is moved around is reduced with the additional benefit of CPU and data proximity.

Oracle's implementation of this idea could be classified as asymmetric MPP. Oracle Exadata uses offloading to storage layer, Smart Scan, Storage Indexes and other techniques to improve performance.

Storage layer (Exadata cells) are tasked with as much work as possible to reduce load on database server and network. Each Exadata storage cell has the ability to perform some parts of data processing operations as well as decompression.

IMDB and Oracle
SAP relatively recently released Hana - a fully functional in-memory RDBMS, targeted for both OLTP and OLAP applications. Hana operates on the premise that whole database is in memory and not on disk. Majority of data processing is now pointer based arithmetic, so whole sections of RDBMS code related to moving data back and forth between disk, RAM and CPU are not needed any more. This is all possible because memory is more affordable and abundant, so much so that most of modern OLTP databases can completely fit within modern server's RAM.

Oracle puchased Times Ten in-memory database, but marketed it mostly as caching layer to standard Oracle database. Times Ten is not marketed as stand alone IMDB the way SAP Hana is.

Oracle database can have Flash Cache devices configured as an extension of SGA for better performance (via database parameter), or for database logging purposes.

Exadata can be configured with terabytes of Flash Cache memory for database caching and to serve as solid state disk. This is not memory directly accessible by CPU though ( DRAM ), i.e., Oracle database accesses Flash Cache via PCI interface and IO operating system calls. In other words, Flash is treated the same as disk, with all negative consequences of such approach regarding code complexity and performance. The latest release of Exadata performs writes directly to flash cache first to improve performance. We should expect more optimizations that will try to better utilize abundance of various types of memory. Expected scenario could be similar to Microsoft Hekaton project is also about adding IMDB features to SQL Server ( tables can be loaded in memory and processed in IMDB fashion, with reduced latching and locking; perhaps choice between different storage engines will be possible).

Conclusion
Oracle will probably continue to execute on strategy that worked well in the past - gradual inclusion of new technologies into its core RDBMS product (like it did with programmable server, OODBMS, Internet database, XML, partitioning, etc.). None of the latest developments in server technologies and database world is as seismic as introduction of RDBMS, client-server and Internet computing was. Oracle was so far successful  in modifying its database engine to adjust to the changes in hardware and data processing methods. We expect this trend to continue, as pace of technological innovation is somewhat slowing down and no truly disruptive changes are on horizon. Oracle solutions are designed to introduce and take advantage of these new (old) technologies and avoid cannibalizing existing profits. Intent is to maximally protect existing legacy RDBMS software revenues and integrate and sell products that came with new hardware and software acquisitions. Oracle Exadata, for example, could be viewed just as intelligent, Oracle database aware and Oracle produced SAN, bundled with database server. It is perhaps safe strategy in an environment where even mediocre and lackluster repackaging, modifying and integrating acquisitions is not seriously challenged by radical new ideas or strong, competitive implementations of existing concepts and technologies. SAP Hana, for example, is also unification layer built on top of in-house built or acquired products.

More Stories By Ranko Mosic

Ranko Mosic, BScEng, is specializing in Big Data/Data Architecture consulting services ( database/data architecture, machine learning ). His clients are in finance, retail, telecommunications industries. Ranko is welcoming inquiries about his availability for consulting engagements and can be reached at 408-757-0053 or ranko.mosic@gmail.com