Wednesday, July 20, 2011

What does a Great White flopping in a boat have to do with databases?

Greetings! I am the proud expecting father of several kidney stones in August. Yes, in August they are going to clean me out of a number of stones all over the Freeman internal acreage. I can hardly wait.

I saw this picture:

and believe it or not, it made me think of databases. This boat was trolling around with scientists doing shark study when Jaws here leaped out of the water, and settled right where you see it. You can see the story here.

So, does this make you think of databases? No....? Your thinking this is making me think about how fast I could get to the front of the boat. I don't blame you.... I'm sure someone said, "We are going to need a bigger boat"

But what if I suggested this was an Oracle database example. How about the idea of elastic scalability? Freeman, are you hopped up on your pain meds? No! I think this is a perfect idea of what elastic scaling is all about.

So, your database server (the boat) is humming along doing what it was *designed* to do... chumming water, chasing sharks, tagging them, catching an occasional red snapper, whatever. Your ship is built for this mission, it's designed for the load.

Then, in one moment there is this BIG FRIGGING FISH laying on your boat. This is the sudden rush of users. Maybe your a state agency and it's election day, maybe you are some gossip rag that just got sued or you are some database vendor reporting incredible earnings... whatever the story, all of a sudden this big fish just plopped into your neatly tuned system and you realize, it's not going to scale.

In this case, the big shark caused all sorts of damage, causing the boat to need to be towed into port. Do you want your system to have to be towed into port just because it could not scale, and rapidly. This is where true architecture, configuration, *thinking* and planning come into play. Sure, maybe today you are dealing with small, 2 foot long sharks which, even if they did flop up on your boat, won't cause much of a problem (but the teeth do still hurt). But what about the future? What about the unknown? How prepared are you for that? How likely is it?

The is the beauty of RAC I think. Even if your using RAC One Node, or just clustering a single machine for the moment, the ability to easily scale out is powerful. Yes, it might be a little expensive and not everyone is going to need that power, but it is something to consider for mission critical applications/databases.

Anyway.... that's my fish tale and I'm sticking to it.

P.S. Amazingly - the shark LIVED......

1 comment:

Noons said...

Yeah, good point. Easily scaling out by having RAC ready to go in a one-node system is not a bad idea. I might be able to use it as a motivator, here! Thanks for that.

On the shark tale: many years ago a mako jumped into a game-fishing boat, offshore from Sydney. The 4 folks in the boat decided it was safer to be in the water - mako sharks are known to turn rabid and this one was steadily dismantling all the upholstery - so when the rescue boats approached, there were 4 very wet and scared folks in the water and a berserk mako in the boat.
I'm not sure how I could equate that to a db situation, but we still laugh about it! ;-)

Good luck for the stone throwing!

Subscribe in a reader