hao@wren.cs.rmit.OZ.AU (Hao Hong Nguyen) (04/16/91)
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. As my knowledge, on an Unix system, the kernel and the front-end can communicate through socket, pipe or shared memory. 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. ------------------------------------------------------------------------------- Hao Nguyen, ACSNET: hao@goanna.cs.rmit.OZ Key Center for Knowl. Based Sys., INTERNET: hao@goanna.cs.rmit.OZ.AU Victoria University of Technology, JANET: hao%au.oz.goanna@uk.ac.ukc RMIT Campus, BITNET: hao%goanna.cs.rmit.OZ.AU@relay.cs.net Dept. of Comp. Sci., UUCP: ..!uunet!goanna.cs.rmit.OZ.AU!hao GPO BOX 2476 V, Phone: +61 3 660 2992 Melbourne, 3001, AUSTRALIA Fax: +61 3 662 1617
dmg@Unify.Com (Dave Glende) (04/18/91)
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
dhepner@hpcuhc.cup.hp.com (Dan Hepner) (04/18/91)
From: hao@wren.cs.rmit.OZ.AU (Hao Hong Nguyen) >As my knowledge, on an Unix system, the kernel and the >front-end can communicate through socket, pipe or shared memory. >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. The bulk of the cost of a shared memory front-end to back-end IPC is in the context switch, which in unoptimized implementations includes going through a general purpose scheduler algorithm, which is expensive in this context. HP-UX, and maybe others, offers a system call to two-process DBMS implementations which passes a single pointer into shared memory, and in as cheap a way as we could do, switches immediately to the partner process. Using this, we find that communication overhead is not all that significant. Dan Hepner