Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!ames!amdahl!pyramid!voder!blia!billc
From: billc@blia.BLI.COM (Bill Coffin)
Newsgroups: comp.databases
Subject: Database Machines
Message-ID: <2861@blia.BLI.COM>
Date: Mon, 22-Jun-87 15:29:31 EDT
Article-I.D.: blia.2861
Posted: Mon Jun 22 15:29:31 1987
Date-Received: Wed, 24-Jun-87 06:47:23 EDT
Organization: Britton Lee, Los Gatos, CA
Lines: 62
Keywords: servers vs. distrib is more interesting...

>From larry@ingres.Berkeley.EDU (Larry Rowe) Wed Jun 17 09:19:02 1987
>Several comments on the recent discussion of ``database machines.''
>
>1. I too am skeptical that custom hardware can be made price/performance
>competitive with software database systems.  [ ... ]

I may be biting the hand that feeds, but I agree with this.  Partly, Britton
Lee's approach has historical reasons.  When the first BLI box came out,
there was no off-the-shelf hardware that could easily be used. That's
no longer the case.

>2. The above analysis says that Sybase has a creditable strategy [ ... ]
> [ ... ] they will quickly fall
>into the morass of customizing the code for N environments [ ... ]

This is a problem on all distributed and all server architectures.
Even on a one-machine server architecture you need host software.

> [ ... ]
>5. Another thing.  When doing performance comparisons, it is important to
>compare apples and apples.  Numbers ought to be $'s/xact (guess what, a
>program on an ibm 3094 is faster than a vax!) and/or use identical hardware
>(2 processors are better than 1).  i'm tired of seeing claims that a dbmachine
>is faster than a loaded central machine.  of course it is, the central machine
>has other things to do.  compare the performance/cost to buying a larger
>central machine or buying a second general purpose processor.  

This is odd.  When you compare a loaded front end vs. a dbmachine, you
are comparing real-life usages.  If you care about db speed, then you must
consider the typical work loads.  Secondly, buying a bigger central 
machine may solve a "raw" speed problem, but server architectures still
solve the problem of sensitivity to the host work-load.  Most people 
really do care if some host process causes db accesses to slow to a
crawl, or if db access causes other important (non-db) processes to
wimp out.  A faster machine may get things going faster, but the
sensitivity is still there. 

(Server architectures have other benefits as well.
I won't go into all the server-architecture arguments
here, but you can't ignore these factors.)

>2. Distributed DBMS's are a big, big win.  [ ... ]

Why?  I'm convinced that many of the people who THINK they want 
distributed DBMS's REALLY need server architectures.  See Jim Gray's
article in the May UNIX REVIEW.  I won't elaborate here -- but
I would like to see a distribution vs. server discussion on the net.
For the record, I'm not "opposed" to distributed DBMS architectures,
but I DO think they're being oversold.  There are job mixes that
make servers look bad, and there are job mixes that will make
distributed dbms's look bad.  Mr. Natural says, "get the right tool
for the right job."

>3. Benchmark wars will continue to be fought and they might tell you something,
>   and then again, they might lie.

Or to paraphrase an old quote, "There are lies, there are damned lies,
and then there are benchmarks."
-- 
W.H.Coffin.  billc@blia.BLI.COM (ucbvax!{mtxinu|ucsfcgl}!blia!billc)
 >> the usual disclaimer about my employer and my wretched opinions. <<
 >> the usual witticisms that swell netnews to ridiculous proportions. <<