Oracle's Ellison talks up 'ungodly speeds' of in-memory database. SAP: *Cough* Hana
Plus new, RAM-heavy hardware promises 100x performance improvement
OpenWorld Oracle headman Larry Ellison kicked off this year's OpenWorld conference on Sunday by touting the lightning-fast performance of the Oracle 12c database's new in-memory database caching option, and he brought along some brand-new hardware to prove his point.
In-memory databases are nothing new, of course. SAP has long flaunted its HANA in-memory technology as a key competitive advantage over Oracle, and even Oracle offers in-memory caching in the previous iteration of its database.
With Oracle 12c's new in-memory option, however, the database giant claims performance that's an order of magnitude faster than what was achievable before. The trick is that Oracle 12c doesn't just replicate the on-disk database in RAM, but it structures the data in an entirely new way.
In the past, databases had to choose between two methods of storing their data. Traditional databases stored data in row format, which made it very fast to do things like adding a new row or record. More recently, some databases have begun storing data in columnar format, which makes query processing much faster when doing things like generating reports.
Oracle's alternative with its new in-memory database technology is to do both at the same time. It stores the data in memory in traditional row format, and it stores it a second time in column format. The two stores are always kept in parity through transactional integrity – when you write to one, you always write to both.
According to Ellison, having the data in memory in both formats is what gives Oracle 12c its remarkable speed advantage. "Once we have the column store we can process data at ungodly speeds," the always-outspoken CEO told the crowd at San Francisco's Moscone Center.
Just how blasphemous are Oracle's new performance numbers? "A hundred times actually understates how much faster it is," Ellison said. "It's at least a hundred times faster."
To underscore his point, Ellison invited Oracle VP of systems technology Juan Loaiza onstage to demo the new technology. Using a sample database with a table containing roughly three billion rows with no indexes, Loaiza showed how the current Oracle technology would take several minutes to return the result of a simple query. With the new in-memory option, it took less than a second. In fact, by Oracle's measurement the query was completed some 1,354 times faster than with the older Oracle technology.
"Obviously this is a fairly simple query," Ellison said, "but you can imagine that as queries get more and more complex and take a longer and longer time, things that used to run in an hour now run in a few seconds. It's a dramatic improvement in query and analytic processing."
This performance improvement is strictly the result of the changes in how the database operates, Ellison said. Applications do not need to be rewritten to support Oracle 12c's in-memory option, and the new in-memory technology even works with the database's new multi-tenancy option for cloud applications.
"Everything runs," Ellison said. "There are no changes to SQL. There are no changes to your apps. There are no functions that are restricted. Everything that works today works with the in-memory option turned on. There is no unloading and reloading of data; just throw the switch. There's no data migration. Every one of your applications – every application that you wrote, every application that you bought – everything runs without a single change to the application."
Lest you think this all sounds a bit fishy – how can this method of storing and accessing the database really be faster, when you're essentially maintaining two complete copies of the database instead of just one? – Ellison had an answer for that, too.
For one thing, Oracle 12c doesn't duplicate the work it does for transactional logging. It logs transactions for the row store, but it doesn't do it a second time for the column store; there's no point. So the overhead required to store the data twice isn't actually double what it is to store it once.
Incidentally, the new approach doesn't require buckets of RAM, either. The whole database doesn't need to be in memory at once. Oracle already has a sophisticated system that can migrate data between RAM, flash, and disk based on heuristic access patterns, so that only the most frequently accessed data need live in memory.
More importantly, by making the data available in two different formats, Oracle 12c's in-memory option obviates the need to create lots of indexes to support analytic processing. In the past, a simple add-row operation might have not have really been that simple; it might have needed to update dozens of indexes at the same time to support the eventual analytics that would have been conducted on that row.
But by storing data simultaneously in a format that is efficient for live data processing and in a format that's efficient for data analytics, the new technology dodges a lot of other work it would have done to make the database run smoothly when the data was only stored in a single format.
Sponsored: Hyper-scale data management