Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

NoSQL is no Oracle killer

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

By Andrew C. Oliver, InfoWorld, 10/25/12

  • Print
  • Feedback
.

Page 2 of 3

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.

Enter NoSQL
RAC's feature set, higher scalability, and high availability are part and parcel of many modern NoSQL databases. Consider Couchbase, which is adding a document database to its popular offering with the new 2.0 release. With full 24/7 support, we're looking at $4,500 per node. That adds up to $13,500, which is maybe three times what I paid for my motorcycle but less than I paid for my car. As for MongoDB, currently the most popular document database, we're looking at $4,000 per instance of mongod (you may end up running more than one instance per node since Mongo is single-threaded).

From an operational store standpoint, where quickly handling short reads and writes concurrently is the most important priority, RAC may scale to your needs, but at a price point that doesn't make much sense. Moreover, Oracle hasn't become any easier to maintain, and setting up for "five nines" availability would require a much more advanced system than I've priced out here.

For analytical systems, the cost will be higher. Fortunately, your need for RAC is much less urgent here because these systems tend not to be real time and mere replication is often sufficient. A Hadoop cluster might be more appropriate. Neither of the two largest Hadoop vendors seem to disclose their pricing publicly, but it's hard to imagine it's worse than building a RAC system of the same approximate scale.

Moreover, as we head to the clouds, what's more partitionable and affordable than autoscaling/autoprovisioning new nodes as traffic demands?

If you don't need RAC, maybe you don't need Oracle
A key advantage of the Oracle RDBMS is that if you design your schema and structure your queries just right, you can heavily parallelize analytical, ETL, and batch jobs. A possible corollary to "it's uncommon to write your software well" is that it's uncommon to design your schema well, especially if you're trying to have one master model of all of your data. But if your problem lends itself to this kind of parallelization, it probably also lends itself to MapReduce.

Even if you have a great fit for the RDBMS, you aren't doing some highly parallelizable star-schema crazy thing, and you're not using RAC, you can use a much less expensive RDBMS such as PostgreSQL or even SQL Server (which last I checked was about one-fourth of the cost). For operational systems, the best thing your RDBMS can do is manage concurrency and get out of the way while you try and hit the disk (or maybe the cache) as quickly as possible.

Nonetheless, Oracle will have a long tail, because it's entrenched -- and enterprise customers have undertaken ill-advised actions, like writing PL/SQL triggers. Migration will take time, and in some cases, spending a few hundred thousand dollars more is less painful than the cost of the refactoring.

But my original advice holds. Anyone looking at Oracle RAC for a new system should probably take a much deeper dive into NoSQL and their data problem. NoSQL is a RAC killer.


For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

  • Print
  • Feedback