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

Wed May 20 14:17:47 CDT 2015

Jim,

First things first. VoltDB is designed to handle massive input loads, which
may or may not come from humans. Examples might include a Bloombereg stream
of stock-market transactions, or maybe election results coming in from
thousands of polling stations, or thousands of transactions on a web site
such as Chapters Indigo or Amazon. In those cases, the sort of hardware I
described earlier would definitely be required. Oh, I forgot to mention
that lots of cores would help, the more the better.

As to the db outgrowing the RAM available, It is the developer/DBA's
responsibility to ensure that the DB never grows larger than the RAM
available. As it starts to get close, add more servers and/or RAM. You can
do both operations without having to bring the database down. Those kinds
of organizations can afford the costs.

But VoltDB is not only for such massive database input streams. In fact,
there's a community version that can run in as little as 4GB of RAM. The
largest db I ever managed as DBA was just shy of 50 GB, so a pair of
servers each with 64 GB leaves lots of room for rapid growth.

But I'm beginning to see a place for VoltDB in lots of situations. A chain
of drugstores, say. How big can the Shoppers Drug Mart database be? Or
think of the "average" app most of us have written, with 30 or 40 PCs
running an Access app against a SQL back end. The community edition is
cheap enough to make that thinkable, and the speed would blow the doors of
the SQL equivalent. That would be FUN.

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

> 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
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>

-- 
Arthur