All of that helps spread the load or provide ways to avoid a heart attack if a server or disk is lost. But what about taking some load off of the database? Oracle again has two products that it bought for the purpose:
- TimesTen. This can be used as an in-memory database cache and is entirely JDBC/SQL-based. There are alternatives such as VMware's SQLFire that actually may be more mature and provide similar functionality, but require ANSI SQL and lack support for PL/SQL. TimesTen also has some limitations and quirks related to Oracle RDBMS-specific features. The sales pitch is that TimesTen is just "thrown in front" and you press the Go button. The truth is that if you have a bunch of PL/SQL and have coded to Oracle and not ANSI, you may be headed for a substantial system integration project.
- Coherence. This is a traditional replicated cache similar to JBoss's Infinispan, VMware's GemFire, and Software AG's Teracotta. Since Oracle acquired Coherence, development appears to have dropped off somewhat; Oracle appears to be more aggressively pushing TimesTen. All of these products allow you to write a custom CacheLoader and CacheWriter -- and it may actually be easier to do so than port all your queries to a more standard dialect of SQL or even a subset of PL/SQL. All of these products have some interesting features for localizing and distributing data. In general, it's best to think of them as in-memory key value stores (a type of NoSQL database) with a write-behind queue for a SQL database or indeed other storage mediums. With both LAN and WAN replication and other features, replicated caches can also serve as at least a partial DR and HA solution, depending on the size and complexity of your database and whether you can fit most or all of it in memory.
As I've outlined here, Oracle offers various methods and technologies to achieve most of what a NoSQL database can do in terms of scalability and availability. So why NoSQL if Oracle can do it all?
Well, we haven't yet addressed cost. It isn't that you can't scale Oracle -- but you must weigh the costs of doing so. Most of the companies I work with have existing systems, and the cost of migration to a different type of database after years of coding directly to Oracle is daunting by comparison. For new systems, however, NoSQL can look a lot more attractive.
This article, "How do I freaking scale Oracle?," was originally published at InfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.