What is database virtualization? You can be forgiven for thinking that it’s yet another buzz-word mining exercise invented for nefarious marketing purposes. It is in fact a real and useful idea and it’s only partly new. Oracle introduced its RAC (Real Application Cluster) architecture in 2001 with Oracle 9i, and this qualifies as database virtualization. I remember being impressed. It was innovative, relevant and an effective competitive move.

You may not remember, but at the time IBM was giving Oracle a good run for its money with DB2 and Oracle RAC gave Oracle the edge it needed to stay ahead. IBM never did build its own RAC capability, but it’s now partnering xkoto to offer a capability that I regard as better and it can genuinely be referred to as database virtualization.

So what is database virtualization?

I’ll try to explain this simply. In deploying databases we have tended to stay with the traditional tried and trusted method of configuring a large cluster with lots of memory and adequate amounts of disk, and inserting the database. We can still do that, of course, but hardware has been getting faster in every possible way and in every possible place. From a technical perspective, clusters are no longer really necessary. It is possible to use the speed of the network to build informal clusters on the fly, if you really want to. (see The Server Vendors v Cisco: Is This A New Technology War? for more information). And that reality is part of what makes xkoto’s GRIDSCALE a technology to be reckoned with.

From a software perspective, it is possible to split a large database into a number of different instances and parse the SQL calls in flight, turning them into multiple calls to the multiple instances. You then manage the responses. It’s not a trivial trick to pull off, but it can be done and if you do that, what you have is a virtual database made up of multiple physical instances. And you can happily dual up some or all of the instances, so that if one fails, the whole virtual database can continue without pausing for breath. GRIDSCALE can do that.

The above illustration shows an example of a GRIDSCALE configuration, with the remote Atlanta site firing query traffic at a replicated instance of a database. It’s an example of how GIRDSCALE users actually use the product.

If you summarize the characteristics of Gridscale, they read as follows:

• Shared Nothing Architecture: Each node in the database cluster operates completely independent of the others, maintaining its own complete and consistent copy of the database instance. This delivers fault tolerance if you configure it sensibly. Also you can implement it all on NAS (which is cheaper per gig than a SAN – in case you didn’t know).
• Continuous Availability: There really is no need to take the “virtual database” out of service for any reason, ever. No back-up window needed – in fact no back-up needed if you configure it that way.
• Geographically Distributed Implementation: Made possible by modern networking technology. But it’s neat because you can replicate to your heart’s content and really balance the workloads. This also gives you very flexible disaster recovery options.
• 100% Data Consistency: This is a product claim. xkoto claims that its technology ensures consistency across all copies. (It’s not hard to do, but it’s not trivial to do without impacting performance.)
• High Performance and Scalable: GRIDSCALE gets the high performance by scaling out. Ultimately you can get the same or better transaction throughput with horizontal scale-out in a shared nothing environment.
• No Application Code Changes: If you’ve got JDBC/ODBC/CLI-compliant applications then there should be no code changes.

Right now GRIDSCALE supports DB2 and its about to release a version that provides the same capabilities for Microsoft SQL Server. The company is exhibiting strong growth and has some A-List clients.

Incidentally, this isn’t so different from the way that Vertica works. My thoughts are that this is how databases will be implemented as time passes. The days of the tight cluster and single database instance are coming to an end.