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

[Jim Lawrence]

Hi Arthur: 

Thanks for applying back. 

So you are saying that memory on a group of computers can be connected together similar to the way ZFS connects a group of computer's hard drives? That is very interesting technology. When a group of computers are so configured are they usable for any other purpose or are they dedicated? 

What happens when a database exceeds the memory available?...does it then just parce to the hard drive and keep running? What happens to performanace? 

THere are a hundred other questions that I could ask but I am sure they are answered in VoltDB documnetation. 

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