Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP
Path: utzoo!watmath!hachong
From: hachong@watmath.UUCP (Herb Chong [DCS])
Newsgroups: net.database
Subject: Re: UNIX + database
Message-ID: <16271@watmath.UUCP>
Date: Sun, 25-Aug-85 13:21:18 EDT
Article-I.D.: watmath.16271
Posted: Sun Aug 25 13:21:18 1985
Date-Received: Mon, 26-Aug-85 01:12:08 EDT
References: <164@3comvax.UUCP> <2693@sun.uucp>
Reply-To: hachong@watmath.UUCP (Herb Chong [DCS])
Distribution: net
Organization: U of Waterloo, Ontario
Lines: 49
Summary: 

In article <2693@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>I don't think there's a simple answer to the question "is an extent-style
>file map faster than a UNIX-style file map?"  It depends on the pattern of
>accesses to blocks of the file.  The worst case would be purely random
>access; however, both the UNIX scheme and the extent map scheme perform much
>better if the locus of file access doesn't move too fast (the UNIX scheme is
>more likely to find the desired indirect block in the buffer cache, and the
>extent map scheme is more likely not to have to "turn the window" and pull
>in another map block).  I don't know the locality of "typical" block
>accesses in a "typical" database system.

IBM's IMS dbms is overlaid on top of their VSAM file structure.  IMS is
a hierarchical system, although it is possible to construct network and
ISAM-like databases with a little bit of work.  unless they have
changed it again in recent years, IMS uses a B-tree method of storing
indices into a database with the leaf nodes themselves being the actual
"segments" of data. VSAM itself allows three physical access methods
depending on how the VSAM file was defined: byte offset (like unix),
record offset (like IBM direct access, not ISAM), and keyed access.
IMS uses only keyed access.  a VSAM key is a character string up to 256
characters long.  using multiple levels of indirection through memory
buffered indices, fast access is allowed into the VSAM file system
itself.  the VSAM routines provided an additional layer of buffering
for data and indices for you.  all you have to do is specify the size
of each, or use the defaults assigned at file creation time.  the
relative sizes and the absolute sizes can be tuned for the particular
application, i.e. mostly sequential access requires large data but
small index buffers, while mostly random requires large index but small
data buffers).  

obviously, we are talking a lot of memory here to hold all the indexing
information, but IMS checkpoints the index information to disk
periodically in case of system crashes and of course, a complete log
file is maintained to back out changes as well as for billing.  one
large database used for online banking running on a single processor
can support sustained transaction rates of about 1000/second.
applications run under the control of IMS and request services from it
to perform database transactions.  only one copy of the database index
is actually kept by IMS, and most of it is paged out when not needed
anyway.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!hachong
CSNET: hachong%watmath@waterloo.csnet
ARPA:  hachong%watmath%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET, EARN: herbie@watdcs