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