Oracle Promises 100x Faster DB Queries With New In-Memory Option

Hugh Pickens DOT Com writes "ZDNet reports that Oracle's Larry Elison kicked off Oracle OpenWorld 2013 promising a 100x speed-up querying OTLP database or data warehouse batches by means of a 'dual format' for both row and column in-memory formats for the same data and table. 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. 'This is pure in-memory columnar technology,' said Ellison, explaining that means no logging and very little overhead on data changes while the CPU core scans local in-memory columns. Ellison followed up with the introduction of Oracle's new M6-32 'Big Memory Machine,' touted to be the fastest in-memory machine in the world, hosting 32 terabytes of DRAM memory and up to 384 processor cores with 8-threads per core."

Like Microsoft SQL Server

[Anonymous Coward]

Wow, just catching up to Microosft. like SQL Server In-Memory OLTP http://technet.microsoft.com/en-us/library/dn133186(v=sql.120).aspx
And Column Store Indexes released 2 years ago. http://blog.sqlauthority.com/2011/10/29/sql-server-fundamentals-of-columnstore-index/

This merely allows poor code to suck less.

[pla]

First, let me say that I would love to have a table option to keep a particularly heavily-hit table always in memory.

This ain't it.

From TFA, "Maintaining those indexes is expensive and slows down transaction processing. Let's get rid of them," Ellison remarked. "Let's throw all of those analytic indexes away and replace the indexes with in-memory column sort."

This merely minimizes the penalties of poor indexing and RBAR by making complete table scans on arbitrary columns faster. Apparently Mr. Ellison has forgotten his algoithmics and combinatorics - Oh, wait, no he didn't, he dropped out as a sophmore. Pity, because had he stayed, he would have learned that even with a 1000x slower storage medium, an O(log N) algorithm (index seek) will eventually beat an O(N log N) algorithm (column sort).

Thanks, Larry, but you want to make Oracle faster? Remove cursors from the core language, and although that alone won't "fix" it, you'll see all the hacks who can't think in set-based logic drop out overnight.

Re:Oracle gains speed

[pinkstuff]

An estimated $100m USD [time.com]. The winner sets the rules for the next one, so if New Zealand wins they will lower the cost, allowing more teams to able to compete.

Re:Like Microsoft SQL Server

[SDrag0n]

Until next year http://blogs.technet.com/b/dataplatforminsider/archive/2013/07/17/what-s-new-for-columnstore-indexes-in-sql-server-2014.aspx [technet.com]

Re:This merely allows poor code to suck less.

[pla]

Okay, you'll have to 'splain it too me as well then, because I don't see the joke (and only refrained from posting substantially the same response because an AC beat me to it).

Memory runs roughly 1000x faster than disk (it can get down to around 50x on an array of SSDs, but up to 100,000x for random seeks across physical platters). Holding all else equal, 1000*O(log N) will take longer than 1*O(N log N) until N=1000, despite the lower time complexity. Additionally, the AC made a good point about the relative constant factor of the algorithms themselves, in that a binary search of a sorted list has virtually no overhead, while a good general purpose sorting algorithm does.


And all that said, yes, I see now that I made an error because this change applies to columnar rather than row-oriented data; O(log N) will still eventually beat O(N), however.