[dba-SQLServer] Michael Stonebraker on the obsolescence of Oracle, DB2 and SQL Server

[Jim Lawrence]

Hi Arthur:

I have installed Docker on one of my servers and have tested a number of small containers. I then decided to download and install the VoltDB demo container and see how the product would run. It did not as there were some issues within the container, apparently not all dependencies were resolved before the compiling was done. I complained but there was a few ahead of me. Now we will wait until there is a new compile out.

Jim   

----- Original Message -----
From: "Arthur Fuller" <fuller.artful at gmail.com>
To: "Discussion concerning MS SQL Server" <dba-sqlserver at databaseadvisors.com>
Sent: Wednesday, May 20, 2015 10:52:17 AM
Subject: Re: [dba-SQLServer] Michael Stonebraker on the obsolescence of Oracle, DB2 and SQL Server

Jim,

Perhaps you missed a couple of key things, which were not described in that
brief interview but I've read all the docs.

First and foremost, you scale the number of servers and their RAM to suit
the db of interest. Second, the total RAM on all the servers is your
workspace. IOW. 8 servers each armed with 64GB of RAM = 8 * 64 = 512 GB
workspace. Not enough? Double up on the RAM on each server.

Second, partitioning. You partitiion on a particular column. No need to
describe the partitions in more detail, VoltDB takes care of that.
Partitioning also applies to indexes, of course, but here's an interesting
new (to me) idea: you can partition stored procedures as well. The
advantage of partitioned stored procedures is that everything that needs to
be there will be there within the partition. Not all tables need to be
partitioned, of course, for example lookup tables; with those you use
replication instead, placing a copy on each partition.

So think of a 1/2 TB database sitting in RAM: no disk accesses at all
except at startup and shutdown. And when you want to move the data from
VoldTB to a disk-based system for OLAP etc., you don't even have to shut it
down, just specify how often (in either transactions or temporal units) you
want to save to disk.

Even on my modest hardware, some of the sample programs are achieving 50k
TPS, which is a far cry from anything SQL or Oracle are capable of.

Arthur

On Wed, May 20, 2015 at 12:11 PM, Jim Lawrence <jlawrenc1 at shaw.ca> wrote:

> Hi Arthur:
>
> A great article. It seems that Stonebaker has accurately described the
> problems...
>
> ...but, from my observations, he has not given a solution. He does mention
> databases that run in RAM and laid out like arrays. I don't see the
> differences between arrays and tables as they both use rows and columns but
> maybe he defines arrays as rows and columns in memory. The problem I see is
> there is not yet any RAM that matches the storage of hard drives...not even
> close...even attempting such a system would cost an incredible price. Then
> he mentioned the performance of GPU processors. They are very fast for sure
> but the energy requirements are prohibitive. (A good friend has a BitCoin
> mining operation and he says his block of GPUs uses more power than the
> rest of his house...and he uses electric heat.)
>
> So. IMHO, I would guess we will have to wait for technology to catch up
> before Michael Stonebraker's predictions can be fully implemented.
>
> In the meantime, how has your RAM array based VoltDB been running?
>
> Jim
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com