Xref: utzoo comp.arch:4817 comp.databases:1001
Path: utzoo!attcan!uunet!husc6!bbn!mit-eddie!ll-xn!ames!nrl-cmf!cmcl2!phri!manhat!mancol!murphy!peterg
From: peterg@murphy (Peter Gutmann)
Newsgroups: comp.arch,comp.databases
Subject: Re: Unix machines for large databases
Message-ID: <254@murphy>
Date: 10 May 88 23:36:03 GMT
References: <428@cmx.npac.syr.edu>
Lines: 65

In article <428@cmx.npac.syr.edu>, billo@cmx.npac.syr.edu (Bill O) writes:
> deleted stuff about "need this yesterday" and record locking.....
> 
> What is the nature of the data base?  Would you believe we're not
> sure?  The amount of data will probably be very large, and it may or
> may not be based on the relational model.  Why am I asking such a
> vague question?  Because we are trying to develop corporate funding
> for a project that is still in the jello stage of conception (you can
> see it, and it glistens, but you still can't get a good grip on it).
> What we want to do is to be able to talk about existing Unix-based
> solutions to very large data sharing problems.

	Without knowing the "nature" of the database there are some 
	questions that must be answered about the logical location
	of the data (two phase commit), how much transaction logging 
	is required, distribution of the users, etc. 
> 
> Names we know about:
>  Gould -- fast disks, but is there data-sharing software?
>  Most other Big Unix Boxes in the world -- ditto above comment.
>  Tandem -- is this Unix based?

	Tandem has a UNIX box. It is based upon the Altos 3068 System V
	using the MC68020 as the processor. The rest of there products
	do not use UNIX.

>  Stratus -- is this Unix based,  is this a good database machine?

	Not a UNIX box, there is a UNIX kernal that runs under there
	VOS operating system. Performance is a question using this
	method
>  
> Deleted fears about being swamped with product stuff....
> 
> Bill O'Farrell, Northeast Parallel Architectures Center at Syracuse University
> (billo@cmx.npac.syr.edu)

Based upon the outline provided, there appear to be two approaches.

Hardware - Use a database machine (like britton lee, etc). These
	usually can be accessed thru a network of some sort. The
	machines containing the users would reach the machine thru
	a network.

Software - The software approach, this gets interesting. At this
	point the outline of how your users are connected to the
	data becomes important. If the database can sit on a
	database machine and the users exist on different
	machines. You should look into requester/server designs.
	We are currently doing some development in the SYBASE 
	environment and have found the server to be very well
	hardened. 
	
	The dataserver from SYBASE manages the locks, and the 
	transaction logging for you.

	I know of several organizations that are developing
	applications that need high transaction rates and garenteed
	recovery (all of the major financial exchanges). All of 
	these people are using SYBASE as an database engine. 

These thoughts, ideas, and misstakes are mine and mine alone.

Peter Gutmann		UUCP:	cmcl2!manhat!mancol!murphy!peterg
(212) 227-7706			philabs!pencom!murphy!peterg