Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!csus.edu!ucdavis!csusac!unify!dmg
From: dmg@Unify.Com (Dave Glende)
Newsgroups: comp.databases
Subject: Re: Need information on DBMS architecture
Message-ID: <40gudo7@Unify.Com>
Date: 17 Apr 91 20:03:03 GMT
References: <5274@goanna.cs.rmit.oz.au>
Organization: Unify Corporation, Sacramento, CA, USA
Lines: 67

In article <5274@goanna.cs.rmit.oz.au> hao@wren.cs.rmit.OZ.AU (Hao Hong Nguyen) writes:
>
>The common architecture of a relational DBMS is to have two layers: the
>front-end process and back-end process. The front-end process may be a form
>interface, a textual command language (eg SQL) or a user application. The
>back-end process (also called the kernel) is a common program which contains
>the query evaluator, indexing code and accessing to raw data stored on disk.
>

This is the most common architecture, although there are others.  
Client/Server can also have a few styles: 1 server per client, 1 server for
all clients, or M servers for N clients (where N != M).

Another architecture is to have the DBMS kernel bound into the same
executable as the application tools.

UNIFY 2000 uses this architecture when accessing local databases.  It uses
client/server for remote databases.

Some benefits of this architecture are:
	
	1) The communication overhead is eliminated.

	2) The number of processes on the system is reduced.

	3) The 'execution path' of a database operation is generally shorter.
	   Theoretically, the comm overhead should be the only additional
	   cost, but this is not always true in practice.  Or to say it
	   another way, the communication cost generally includes more than
	   just the cost of the system calls.

Some drawbacks include:

	1) The possibility that bugs in user application code could
	   corrupt DBMS data structures.
	
	2) The upper security levels of the Orange Book would not allow
	   this architecture.

>As my knowledge, on an Unix system, the kernel and the
>front-end can communicate through socket, pipe or shared memory.

Obviously, for processes communicating on the same machine, shared memory
is the only way to go for large amounts of data.  The overhead of pipes,
sockets, and SYSTEM V messages is too high for high volume use.

You should also try to stay away from OS synchronization mechanisms for
high use latching (critical section locking of shared memory data structures).

Messages and semaphores are fine for lower volume use.

>Is there any other DBMS architecture ? and how how different compenents of a
>DBMS communicate to each other ?
>
>The reason I ask for this is that my group is implementing a research
>DBMS and find out that the communication overhead is quite
>siginificant.
>
>I am looking for any papers or books to talk about these thing formally. I will
>be appreciate for any help.
>
>
-- 

David Glende   Work:(916) 928-6254  | Unify Corporation
dmg@unify.com  FAX :(916) 928-6401  | 3901 Lennane Drive
                                    | Sacto, CA 95834