Path: utzoo!attcan!uunet!pyrdc!gmu90x!lowen!larry
From: larry@lowen.UUCP (Larry Taborek)
Newsgroups: comp.databases
Subject: Re: Unix machines for large databases
Keywords: large databases
Message-ID: <244@lowen.UUCP>
Date: 13 May 88 16:01:50 GMT
Lines: 86

In article <428@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O'Farrell) writes:
>can work as a very high-performance data-base server.  Yes, there are a
>million Unix boxes out there, but a data-base server has to be able to
>cope with concurrent access by multiple (possibly several hundred)
>users.  Simple file locking isn't good enough -- users should never
>have to read "file locked" error messages.  Also, the disk performance
>should be very good.
>

This could be a little late, but I think that the following information
could be of use to you.  I work for NBI corporation and we manufacture
high speed minicomputers, though not of the size needed.  So I am not
going to try to sell you on our products.  Still this will seem pretty
much like a pitch.  I don't mean it to, its just that that is my
reference point that I have to talk from.  I have worked on some fairly
large databases as a systems engineer for the company, and these are
the things that I would look for if I were you.


There are several manufactures today that offer both Berkley 4.X and
the AT&T SYSV operating systems on the same machine.  At NBI, we have
BSD 4.3 and SYSV release 3 on our newest release.  We call this
duplix.  On our machines, we make use of a kernal that has both BSD
and SYSV system calls, on a 4.3 file system, using duplicate /usr/bin,
/etc, /usr/lib, /usr/include /bin directorys to support the dual
implementation.

Hardware/System Software:

The 4.3 file system performance has been improved over 4.2, and is
once again speedy.  You should look for a 4.3 file system (Im about to
be flamed, I know), because it offers a fast-file-system over the SYSV
system.  Unix tends to bottle neck its performance on disk IO.  Anyway
faster file systems will support more rapid access of files for your
users.

Try to look for the capability for the disk controller to be as
intelligent as possible.  We use the ISI ESMD disk controller, its 
interleave is zero (0!), which means that it reads an entire track
into controller memory, and does a DMA transfer to swap in and out the
buffers.  Look for very rapid disks.

Look for lots of memory and disk storage.

Look for a fast bus on the machine.  VME is generally faster then Qbus
and Qbus is generally faster then multibus.  (I don't know whats
faster then VME).

Try to look for a SYSV kernal, for streams and shared memory system
implementations.  This promotes faster access of the database through
locking and unlocking.

Database:

If the database supports raw disk, consider this a plus in your favor.
Through raw disk, the database bypasses unix file system reads and
writes and supplies its own, thus increasing performance considerably.
Under Unify databases, I have seen performance increase 2 fold when
moved to a raw disk.

Try to find a database that supports a host language interface (Unify,
Informix and Oracle all do, I don't know about the others).  This can
speed up database manipulation considerably.

Try to find a database that supports query optimization for its query
language.  This generally means that upon execution of a query, the
database will TRY to calculate the most rapid means of selecting the
records (humm, now which index will give me the faster result), and
then run the query using that means.

For indexing structures, hashing is generally faster then B-trees, so
try to find a indexing structure that supports hashing.  Almost no one
does.

Ask for a comparison of a TP1 benchmark of the software on a common
machine.  The reason for doing this is to find the 'load' imposed on
the machine by the database software.  I have been told that Oracle
will generally be slower on a machine then Informix and Unify.

Closing:

All of this is directed only towards speed, as generally speaking,
speed and the number of users go hand in hand.  I have not tried to
address open standards, ease of use, documentation, implementation or
any of the dozens of other things you can rate a database on/about.

-----------------------------------------------------------------------
| These opinions are mine, and should they be wrong, then their       |
| someone elses.                     Larry Taborek                    |
|                                    NBI Inc.                         |
| (703) 524-0440 ext 414             2500 Arlington Blvd Suite 400    |
| uunet!pyrdc!gmu90x!lowen!larry     Arlington Va.22201               |
-----------------------------------------------------------------------