Pluggable Databases Vs. Database Virtualization

I love this industry.

On one hand, you can clearly see the megatrends that are driving change.  On the other hand, not every vendor reacts to these trends in the same way.  That's what makes things so interesting.

Take virtualization -- as applied to servers. A powerful idea, but interpreted in different ways.

One camp saw the need for a new technology abstraction -- the hypervisor -- that encapsulated and extended the legacy approach.  A second camp decided to add server virtualization features to their existing operating systems.

In this case, VMware is the best example of the first camp.  Sun, IBM and Microsoft are probably good examples of the second camp.  You're free to debate which one is theoretically "better", but there should be no argument whatsoever around market adoption of the former over the latter.

A similar divergence of approaches appears to be shaping up over networking technology.

The database world is not immune to this megatrend, either.

As part of Oracle Open World 2012, Oracle gave their first peek into how they're going to address what I would call "database virtualization concepts" (expressed in their terms as the need for multi-tenancy) in their core database products. 

And, once again, we'll see a familiar argument play out: create a new abstraction, or simply extend existing database technology.

I know which one I'm betting on ...

The Background

You can get to the core discussion through any path of your choosing, but you'll end up in largely the same place.  In today's world, the notion of one physical database / one physical server / one application is seriously outmoded for any number of reasons; efficiency, agility, you name it.

VMware has been quietly applying a small amount of pressure on Oracle database consumption and implementation habits -- not only with their core products, but more specifically via a recent release of vFabric Data Director. 

If you're not well acquainted with what it does, in a nutshell it makes database instances far easier to instantiate, consume and manage for everyone involved --  simply by extended many of the capabilities found in vSphere. 

If you're interested in my slightly longer treatise, here it is.

But no good deed goes unpunished in today's technology world, does it?  Oracle's response appears to be in the form of pre-announcing new capabilities for Oracle 12c, namely "pluggable databases".  The idea is conceptually simple: a "root" instance of Oracle can be used to instantiate "up to 250" user-specific sub-instances that are theoretically unrelated to (and isolated from) the root Oracle instance.

Specific details are scant (as you might expect at this stage), but you can see where they'd like to go: applying virtualization concepts to the database world by extending the features of the database itself.

So, what are we to think of all of this?

Stating The Obvious

Let's tackle the easy bits up front. 

First, Oracle 12c isn't here yet, and won't be anytime soon.  Any major architectural feature this substantial will take a non-trivial amount of calendar time to bring to market, more time to mature, and even more time for their users to migrate in sizable numbers.  I'll leave it to Oracle to make specific statements in this regard, but past history (for any vendor) is hardly encouraging in terms of speedy access to the new capabilities.

Second, remember this is Oracle we're talking about.  New functionality inevitably means new licensing terms, which isn't expected to be cheap -- unless there is a viable competitor in the market gnawing away at market share. 

Case in point: Oracle's pricing on Linux and their versions of hypervisor technology.

Third, we're clearly talking about new skills and processes that the DBA will have to acquaint themselves with.  These are some major new database concepts at hand; proficiency won't happen overnight -- and won't begin in earnest until the product is generally available.

If we compare these three attributes against VMware's vFabric Data Director, there are some clear differences.

First, vFabric Data Director has now been around for a while, and is now in its second major release.  Its design goal is to be relatively DBMS-agnostic; limited by engineering bandwidth to support various popular flavors of database versions in use.   You don't have to upgrade to a new version of the database just to get the capabilities you're looking for.

In general, vFabric Data Director does not appear to be tightly coupled to other parts of the VMware portfolio, either.

"Migration" in this case is really more "implementation": a semi-automated procedure to incorporate existing databases into vFabric Data Director vs. migrating to a new version of a database, sort of like how P2Vs work in the server world.  The vFabric Data Director also supports an open source database variation that can be an attractive alternative to a licensed database product, e.g. Postgres.

You'll have to decide for yourself which vendor has the more attractive licensing terms -- VMware or Oracle.  I'm not going to touch that one ...

More importantly, the DBA doesn't have to acquaint themselves with entirely new database concepts and practices.  The goal of vFabric Data Director is to simply automate what's largely being done manually today, so the skill requirements are comparatively minimal.

Arguing The More Subtle Points

Harder to discern are the relative merits around performance, efficiency, security and isolation.

On paper, I could give Oracle a theoretical nod for performance, simply because there's no hypervisor acting as an intermediary.  But, that being said, I don't think that will end up being a big deal. 

Today's hypervisors are plenty fast for 99.99% of the workloads that are out there, and more performance is always available in the form of faster processors, use of intelligent flash, and so on.  Besides, it's personally hard for me to see how a pluggable database could have the exact same performance profile as a non-plugged one.  But I'm certainly no expert :)

Efficiency (CPU and memory) is also going to likely be a wash for most situations.  Oracle may (rightly) claim that their approach can reuse memory pages, balance across available CPUs, etc.  Well, the same is largely true for the VMware-based approach -- it just happens in the hypervisor vs. the database.  And I'll have to give VMware substantial credit for continually improving their capabilities here over the last decade vs. what looks like a comparatively fresh start for the Oracle team.

When it comes to security, I'll give VMware big points: they've been enhancing the security of their virtual machine containers aggressively for many, many years -- not only with their own products, but partnering with folks like RSA.  While Oracle is arguably very good at security as well, I do have to note that they'll be introducing an entirely new "container" to secure.

Ditto with multi-tenancy, especially the all-important performance isolation -- not an easy thing to address, and something the VMware team has been furiously focused on for many years.

Once again, these are only theoretical comparisons.  We have a VMware-based product to evaluate, and we won't get a detailed look at Oracle's answer for quite some time yet.

How This Might All Play Out

I have no doubt that Oracle will be successful in bringing Oracle 12c to market when it's ready.  I also believe that -- over time -- they'll find ways to get their installed base to migrate to the new version.  But when it comes to adopting the proposed pluggable-database concept vs. other alternatives to achieve similar results, it's far less certain.

Frequently, these debates play out to the market power that's held by the respective vendors.  As an example, an all-IBM shop is usually very comfortable with AIX virtualization as being a really good answer.

But we've got an interesting situation here -- overlapping power bases.  Oracle is a key vendor for so many enterprise IT shops, but -- then again -- so is VMware.  I'm sure this will lead to some heated internal discussions before long as this particular issue comes to a head. 

One interesting preview exists, though -- there's decent interest from the VMware community in how to, for example, get much of the functionality found in Oracle RAC by instead using VMware's capabilities.

Maybe we'll see the same thing play out here.

Comments

[David]

Interesting preview of database approaches in the pipeline.

From personal experience, we saw a slow movement of our clients from managing physical server boxes to vmWare virtualization, and I'd say about 50% of our client-base is still on physical boxes.

I think you hit the nail on the head when talking about DBA proficiency. You'd be dumbfounded by the general skill-level of DBA's NOT in high tech verticals or Silicon Valley. I've worked with government agencies, counties, healthcare providers, etc, and simplicity is a requirement if you want to get anything done.

While pluggable databases might be attractive from a Database developer's perspective, the licensors of these technologies are typically CTOs and CIOs. These are people that stake their reputation on new IT initiative working quickly and smoothly. I don't see a big shift to a new database architecture just as virtualization is taking root in general industry. My two cents though....

--David Waugh--
http://www.assetgurus.com

[Chuck Hollis]

David

Good points and observations, thanks for sharing!

-- Chuck

[Alex Fatkulin]

Memory efficiency still remains a difference. When each database needs it's own private memory which it doesn't share with anybody else you need a lot of memory to run a lot of separate databases on the same machine. With Pluggable databases the memory is shared because it's a single Oracle instance running it all. Thus I don't see Pluggable databases as much a competitor for virtualization but as complementary feature mainly targeted at reducing resource (mainly memory) footprint.

[Mike]

You can run a DBMS on a virtual machine, you can support multi-tenancy inside the DBMS, or you can support a fully virtualized database, where you abstract between compute and storage (like Serengeti does for Hadoop and ScaleDB does for MySQL). Here is a write-up of the challenges, solutions and benefits of true database virtualization: http://www.scaledb.com/database-virtualization.php

[Kyle Hailey]

To see a comparison of database virtualization technologies check out

http://dboptimizer.com/2012/12/19/database-virtualization/

Putting a database in a virtual machine is still just virtualizing the compute tier i.e. the operating system. Database virtualization, as opposed to operating system virtualization, is sharing a read only copy of a source database between clone databases. The clone databases are called virtual databases (also called thin provision clones as distinct from full physical copy clones). Virtual databases are much more than simple read only databases. The virtual databases can also write to the data files. How can the virtual databases write to the data file when the data files are read only? Writing to the data files is accomplished either through one of two basic mechanisms. Those mechanisms are pointer based copy on write file systems or journal file systems. When a virtual database writes to the data files the changes are not written to the data file but are kept in a private area only visible to that virtual database. Each virtualized database sees what appears to be a private read/write copy of the database. Database changes made by a virtual database are only seen by that virtual database as if the virtual database had its own full private copy of the source database.

Database Virtualization gives:

1. Enormous storage savings.
2.Instant provisioning of virtual databases.

A virtual database can be made in seconds and takes up almost no space. The datafiles are full shared initially so initially take up almost no space.

Now combining compute virtual machines, pluggable databases and virtual databases will provide enormous hardware savings and more importantly unprecedented agility.

- Kyle Hailey