Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!cmcl2!esquire!roger
From: roger@esquire.UUCP (Ro Reid)
Newsgroups: comp.databases
Subject: Re: Data Base Machines
Message-ID: <650@esquire.UUCP>
Date: 22 Sep 88 14:49:25 GMT
References: <21755@tut.cis.ohio-state.edu> <664@stech.UUCP>
Reply-To: roger@esquire.UUCP (Ro Reid)
Organization: Mondo Connie Francis
Lines: 66

in article <21755@tut.cis.ohio-state.edu>, mcclure@tut.cis.ohio-state.edu (James Edward McClure) says:
>
>      Could someone please tell me exactly what a data base machine is and
> how if differs from a DBMS (besides being hardware based)?
>
> Thanks for your help!!

Speed (fast as hell, especially on complex queries)
Cost  (more than a software-based DBMS by quite a factor)
Number of things that can go wrong (2-3 times more than a software
				    DBMS resident on the host)

Elaboration:  At one time the ONLY way to get serious speed without
completely swamping your host was to have a separate box to offload
the database work to.  This box has it's own hardware and software
specifically designed to be fast at RDB type things, instead
of being general purpose.
     The drawbacks were always there: more hardware to fail,
a network (or some sort of interface) is involved and can fail,
and lack of portability: in a Unix shop, you can move your
software to the newest, latest fastest box, regardless of
vendor.  A hardware database machine is about a proprietary
a beast as there is.
     Things have changed since we bought our first database machine
7 years ago.  The 11/70 is no longer the workhorse of the Unix
world, there are some fast, relatively cheap boxes out there and
they keep getting faster and faster.  So now many applications
can afford to use the more generalized hardware to take advantage of the
speed gains as they are developed, even if you maintain the separation
between the front end and the back end, and basically make yourself a
database machine by loading a software-based DBMS on one box and
using another box as host.
     My experience is that right now, there are some very good
software-based DBMS's out there that can negate the need for
a specialized database machine.  This holds until you start doing
things above a certain level of complexity. For example, we
found a software DBMS that was faster than our database machine,
until we hit it with 5,6,7 way joins.  And then the software
system went to hell in a bitbucket, while the hardware system
continued to be fast.  We also found that software systems
didn't do so well when the conditions for the retrieve got
real complex and nasty.
     These are by no means final benchmark figures on all software
systems, which is one reason I'm not naming names.  But if you
are not going to torture a database system the way we do, you
probably should stick to software.  It's when you find that there
is no software out there that can do the job for you that you
have to start considering database machines.
     We still have hopes that we can move to a software based
system, if we can find one that can get the work done in the
available CPU cycles for us.
     If you want architectural type details, you might contact
BrittonLee; they might be glad to fill you in.  I've had it explained
to me before and it's amazing the things they do to make that sucker
hum!
-- 
				   Ro Reid

			      {rutgers|phri|cucard}!cmcl2!esquire!roger
			      uunet!esquire!roger
			      roger@woof.columbia.edu

"...to understand is always an ascending movement; this is why
comprehension ought always to be concrete. (one is never got out
of the cave, one comes out of it.)"
	  -Simone Weil, First and Last Notebooks