Sydney Oracle Developer Day Review

Last week, I attended the Developer Day in Sydney.

One of the presentations was about Apex, and I was hoping for more information on Apex 4.0.  I was disappointed as there wasn't a lot of detail, and nothing new to me. While I've had a Workspace in the EAs, I haven't really had a chance to use it. I'll have to wait for an installable version, so I can play with it on the train home.

However one of the other talks was about the TimesTen / In-Memory Database Cache. While I'd heard of it, it hasn't had the same level of spruiking as Exadata (or Iron Man, come to that ). Since it had previously escaped my attention, it was the presentation from which I gained the most.

Firstly, it is an Enterprise Edition feature. That's sort of okay, since it is aimed at very high throughput environments. I know not all of those are awash with money, but I don't expect Oracle to give everything away for free and it is reasonable to equate demanding requirements with a preparedness to pay for them.

Secondly, it gives Oracle scale-out capability. For most Oracle techies, scaling means either a bigger database box (scaling up) or RAC. All those mid-tier happy developers just want the ability to throw boxes at a problem, and RAC isn't that simple. TimesTen would fit their mindset better.  Think of it as half proxy/half cache. Most importantly, the developers treat a TimesTen node as the database, and Oracle will keep all the tricky stuff hidden from them.

In some ways it should be simpler than RAC, as the "hardcopy" database (the one with real disks) would treat the cache as a client rather than as an integrated component. That means that it would be easier to throw up TimesTen caches as and when required (very cloud-like).

Multiple TimesTen caches can duplicate data or shard it (eg one for images, one for audio).  A duplicate would be good for reducing latency issues by having a cache co-located on an app-server. That is "on" not just "near". Apparently the removal of the network is part of the performance boost. 

Sharding could be effective in 'boosting' memory. If you've got a machine maxxed out on 32 GB, then having 20 Gb of 'Northern' data in one shard and 20 Gb of 'Southern' data in another means the hardcopy database can offload the frequently queried read-only stuff to the caches.

It isn't just read-only though. There's  capability for the data to be written, either directly to the hardcopy database, or with 'batching' done by the cache for improved performance.

Of course, I was just sitting through the sales pitch. I've had a flick through the manuals too. SQL and PL/SQL both work in the cache layer, though with some bits missing. Still all the general stuff that you use for applications is there. I'm going to have to dig around and see what real-life experiences have had to say about it. And see if I can throw up an instance (though I suspect VirtualBox on a net book might be somewhat challenging).

In some ways there is an overlap with RAC. There would be a set of problems where either additional RAC nodes or TimesTen caches would be a valid solution. There's also definitely issues where the cache would benefit where RAC would not (eg co-location with an app server).

[PS. The whole TimesTen / In Memory Database Cache terminology is a bit clunky. Oracle on speed or CrackOracle might have a bit more life in it. ]

There was a further talk on the GoldenGate product also acquired by Oracle a while back. More on that later….