Ellison promises in-memory option for Oracle database

Oracle has attempted to destroy the value proposition for customers thinking of switching to SAP's HANA in-memory database, announcing an in-memory option for its pluggable 12C database.

Larry Ellison at this year's OpenWorld.

In his opening address to Oracle OpenWorld in San Francisco, Oracle CEO Larry Ellison claimed that existing users of Oracle's 12C database will now be able to access in-memory functions by "flicking a switch", via a few short command lines.

The feature is likely to incur an additional licensing fee, and is not yet generally available. But by providing an option that can be invoked from within the 12C database, which is technically 'pluggable' with older Oracle database instances, Ellison gave those customers considering a switch to SAP pause for thought.

Architectural approach

Ellison said analytic queries can be processed faster if stored in memory in columnar format. But while columnar data performs well for analytical queries and reporting, it doesn't for online transaction processing (OLTP) that operates on rows.

"We have to be careful not to compromise transaction performance such as inserts and changes," he said.

Using Oracle's 'dual-format in-memory database' option, every transaction is recorded in row format simultaneously with writing the same data into a columnar database.

"What if we store the data in both formats simultaneously - in addition to the row format, the same data is re-arranged or rotated 90 degrees in column format?" Ellison said.

"And what if we put both columns and rows into memory?"

Ellison said while this would lead to significant performance improvements for query processing (up to 100x faster, by his estimates), he acknowledged it could also risk creating an OLTP performance overhead, as the system has to effectively write two inserts for each transaction.

Oracle's answer is to ask database administrators to re-think the way they index data.

DBAs, he said, usually have to decide what columns to create an index for when building a database. Most of these indexes aren't required for the transaction but for analytics processing.

Adding a sales order as a new row, for example, might have traditionally updated the indexes for numerous columns - not just essential information like transaction ID and dollar value, but also a range of other fields such as identifiers for the state and city in which the transaction took place.

"So you insert a new sales order and you update three indexes [required immediately] and 10-20 indexes [you need for analytics/reports]. Those 10-20 indexes should be considered additional operations to simply inserting a row in a table," Ellison said.

"Today we insert a row, then update index after index after index. This is expensive and it slows down transaction processing. 

"So let's get rid of them. Let's throw out the analytics indexes and replace them with an in-memory column store, because we have the new technology to run analytics faster. But when we insert a row into the sales table, let's only update one or two or three [OLTP] indexes."

Using this approach, Ellison claimed that users of the dual-format in-memory database would enjoy 100x speed improvements for analytics processing and up to two times faster transactions, depending on how many indexes are chosen by the DBA to be written in column format rather than row.

Ellison claimed the in-memory option could be turned on with a few command lines in which the DB engineer enters how much memory they intend to use, what partitions of what tables they want resident in memory, and what analytics indexes to 'drop'.

Customers won't need to migrate data into a new database or format, change allocations or make changes to applications in the database to use the feature. Database availability features should still work, he said.

"Everything that works today works when this is turned on. You could double the speed of updates for every [Oracle] database you have now, simply by throwing a switch," Ellison said. 

The new feature is aimed squarely at Oracle's new competitor in database, SAP. SAP claimed that after introducing the SAP HANA in-memory database two years ago, it has signed up 1500 new customers and has an application ecosystem of around 70 solutions.

HANA proved a threat to Oracle in that many customers run SAP applications on top of an Oracle database. HANA gave SAP the opportunity to convince users to swap out Oracle from their stack.

In a blog post released in June, SAP's main call to action for customers was that they "can’t afford to wait for the future", reminding Oracle customers that delays in the release of Fusion Applications proved "the wait is longer than the promise!"

What do you think of Ellison's architectural approach? Will it work for your databases and applications? Comment below.

Brett Winterford travelled to OpenWorld as a guest of Oracle.