This article addresses the benefits provided from database
virtualization. Before we proceed however, it is important to
explain that database virtualization does NOT mean simply running
a DBMS inside a virtual machine.
Database Virtualization, More Than Running a DBMS in a Virtual
Machine While running a DBMS in a VM can provide advantages
(and disadvantages) it is NOT database virtualization. Typical
databases fuse together the data (or I/O) with the processing
(CPU utilization) to operate as a single unit. Simply running
that single unit in a VM does not provide the benefits detailed
below. That is not database virtualization that is merely server
virtualization.
An Example of the Database
Virtualization Problem Say you have a database handling
banking and I have $10MM in the bank (I wish). Now let’s assume
that the bank is busy, so it bursts that database across 3 VM
nodes in typical cloud-style. …
This article addresses the benefits provided from database virtualization. Before we proceed however, it is important to explain that database virtualization does NOT mean simply running a DBMS inside a virtual machine.
Database Virtualization, More Than Running a DBMS in a Virtual
Machine While running a DBMS in a VM can provide advantages
(and disadvantages) it is NOT database virtualization. Typical
databases fuse together the data (or I/O) with the processing
(CPU utilization) to operate as a single unit. Simply running
that single unit in a VM does not provide the benefits detailed
below. That is not database virtualization that is merely server
virtualization.
An Example of the Database
Virtualization Problem Say you have a database handling
banking and I have $10MM in the bank (I wish). Now let’s assume
that the bank is busy, so it bursts that database across 3 VM
nodes in typical cloud-style. Now …
This is a response to a blog postby analyst and marketing consultant
Curt Monash.
Originally virtualization meant running one operating system in a
window inside of another operating system, e.g. running a Linux
on a Windows machine using Microsoft Virtual PC or VMWare. Then
virtualization evolved to mean slicing a single server into many
for more granular resource allocation (Curt’s ex uno
plures, translated: out of one, many). It has since
expanded to include e pluribus unum (from many, one)
and e pluribus ad pluribus (from many to many). This is
evidenced in the use of the term “virtualization” to create the
compound words: server virtualization, storage virtualization,
network virtualization and now database virtualization.
Server Virtualization: Abstracts the physical …
This is a response to a blog postby analyst and marketing consultant Curt Monash.
Originally virtualization meant running one operating system in a window inside of another operating system, e.g. running a Linux on a Windows machine using Microsoft Virtual PC or VMWare. Then virtualization evolved to mean slicing a single server into many for more granular resource allocation (Curt’s ex uno plures, translated: out of one, many). It has since expanded to include e pluribus unum (from many, one) and e pluribus ad pluribus (from many to many). This is evidenced in the use of the term “virtualization” to create the compound words: server virtualization, storage virtualization, network virtualization and now database virtualization.
Server Virtualization: Abstracts the physical (servers), presenting it as a …
[Read more]
More and more public cloud companies are moving to managed cloud
services to improve their value-add (price premium) and the
stickiness of their solution. However, the shift to a database as
a service (DaaS) severely reduces the DBAs visibility into the
business, thus limiting the ability to hand tune the database to
the requirements of the application and the database. The
solution is a cloud database that eliminates the hand-tuning of
the database, thereby enabling the DBA to be equally effective
even with limited visibility into the business and application
needs. It is these unique needs, particularly for SQL databases,
that is fueling the NewSQL movement.
DBAs traditionally have insight into the company, enabling them
to hand tune the database in a collaborative basis with the
development team, such as:
1. Performance Trade-offs/Tuning: The database is partitioned and
tuned to address business requirements, maximizing performance of …
The CAP Theorem has become a convenient excuse for throwing data
consistency under the bus. It is automatically assumed that every
distributed system falls prey to CAP and therefore must sacrifice
one of the three objectives, with consistency being the
consistent fall guy. This automatic assumption is simply false. I
am not debating the validity of the CAP Theorem, but instead
positing that the onset of CAP limitations—what I call the CAP
event horizon—does not start as soon as you move to a second
master database node. Certain approaches can, in fact, extend the
CAP event horizon.
Physics tells us that different properties apply at different
scales. For example, quantum physics displays properties that do
not apply at larger scale. We see similar nuances in scaling
databases. For example, if you are running a master slave
database, using synchronous replication with a single slave is no
problem. Add nine more slaves and it slows the …
ScaleDB and Oracle RAC are both clustered databases that use a
shared-disk architecture. As I have mentioned previously, they
both actually share data via a shared cache, so it might be more
appropriate to call them shared-cache databases.
Whether it is called shared-disk or shared-cache, these databases
must orchestrate the sharing of a single set of data amongst
multiple nodes. This introduces two challenges: the physical
sharing of the data and the logical sharing of the data.
Physical Sharing:
Raw storage is meant to work on a 1:1 basis with a single server.
In order to share that data amongst multiple servers, you need
either a Network File System (NFS), which shares whole files, or
a Cluster File System (CFS), which shares data blocks.
Logical Sharing:
This is specific to …