NoSQL is no Oracle killer

Over time, NoSQL and big data will slow Oracle RDBMS's long-term growth, but it won't deliver a death blow anytime soon -- except, perhaps, to Oracle RAC

Like many people, I cheer any sign of Oracle's downfall and chuckle at the thought of Larry Ellison having some misadventure on the high seas. Who doesn't? But the sad fact is that, despite all the buildup, NoSQL and big data do not threaten Oracle or the RDBMS paradigm in the near term.

On the other hand, there's a decent chance NoSQL will take a big bite out of Oracle RAC (Real Application Clusters). Here's why.

[ Andrew C. Oliver answers the question on everyone's mind: Which freaking database should I use? | Also on InfoWorld: The time for NoSQL standards is now | Get a digest of the key stories each day in the InfoWorld Daily newsletter. ]

Oracle RAC enables you to scale your application by implementing load balancing and high availability across multiple nodes. It scales well for your everyday read-mostly-mostly (the second "mostly" is deliberate) clusters but not as well when you have a few more writes. To support more nodes, it must coordinate a write-lock across the network.

To take advantage of RAC, you need to write your application very well and very carefully. For the majority of applications, the cost of that development (or the horsepower to run less carefully written apps) will be high.

RAC your world, for a price

About 1 percent of systems experience backbreaking traffic, and in cases that demand high transaction throughput, RAC may well make sense. But RAC doesn't add up for the remaining 99 percent.

There's another cost your average Oracle expert won't tell you about: Oracle RAC, like Oracle RDBMS itself, requires lots of extra care and feeding.

Oracle RDBMS, frankly, has the kinds of bugs that are hard to imagine in a mature product. Try launching a site with 8 million concurrent and very active users where some patches that can't be avoided have yet to be put into place. What if, on your rolling update, every time you restart an app server node, Oracle leaks memory? When you add RAC, you get new bugs and problems to boot. It's hard to find independent studies on maintenance costs, and vendors have long learned to manipulate total cost of ownership (TCO) measures, but ask anyone who has deployed this beast: It needs a lot of love.

We haven't even gotten to the costs for RAC yet according to Oracle's price list:



Oracle Enterprise Edition per CPU






RAC support


For a three-node cluster with four cores per node, you're looking at several times the cost of my house. Oracle pricing is like cellular carrier pricing: Hand over your wallet and they'll take what they want. There are about 100 line items of indecipherable fees. You owe what they say you owe. For this theoretical cluster, at retail, we're looking at no less than $160,000, all before installation. (This price doesn't include all the small line items I don't understand.)

If RAC is software for the upper 1 percent, why is it a best seller? Recall my statement that it's uncommon for people to write their software well. In other words, most software makes inefficient use of the database and taxes it beyond what you would expect. Therefore, you have to scale with more CPUs and more disks, which is what RAC is intended to help you do. In the event your reads/writes and locks aren't efficient, throwing hardware at the problem may not increase performance as much as you expect.

The other big reason for RAC is high availability. If a node goes down, you want to stay up. You don't need heavy load for a complete database outage to cost you a lot of money.

1 2 Page 1
Page 1 of 2