Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!aplcen!osiris!eric From: eric@osiris.UUCP (Eric Bergan) Newsgroups: comp.unix.wizards Subject: Re: NFS in a heterogeneous environment Message-ID: <930@osiris.UUCP> Date: Fri, 12-Dec-86 08:42:57 EST Article-I.D.: osiris.930 Posted: Fri Dec 12 08:42:57 1986 Date-Received: Mon, 15-Dec-86 07:17:09 EST References: <2530@phri.UUCP> Organization: Johns Hopkins Hospital Lines: 42 In article <2530@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > > How do you deal with big data bases? We have some rather large > shared data bases (Genbank and related stuff is about 50 Mbytes, for > example) that I'd rather not replicate if I don't have to. Since most of > the data base is ASCII, there isn't much problem there, but what about > binary index files? One solution would be to share the ASCII parts and > have the binary parts be symlinks to the real files in /local/lib/binary, > and mount the appropriate /local/lib/binary depending on which machine you > are on. Does this seem reasonable? I'm hesitant to get into a situation > where data bases are scattered all over the universe with billions of > symlinks tying it all together -- sounds like an administrative nightmare. > Can anybody think of a better way? I can't really address the other issues that this article brings up, but we do have some experience with distributed database access. We currently have a very diverse group of machines (Pyramids, Suns, IBM/MVS, MUMPS, PCs) accessing a common database. We don't use NFS for this, but the underlying Remote Procedure Call (RPC) protocol. We define the interface to the database in terms of function calls (look up this given that, change this, etc). Then an RPC server is implemented to support these function calls. Now all a potential client program needs to do is to make RPC's to the server to have access to the data. This solves the replication problem, also allows one to continue having tight locking control, if necessary. Further, by decoupling the client frontend from the database backend, it is possible to change the database management scheme without effecting the frontends. Simply change the server to support the new DBMS, while continuing to support the same RPC function calls. With commercial database systems (particularly those that require a separate "backend" for each client process), one can also reap some memory savings by having several RPC clients "share" the same RPC server. As I said, we have been using this design with great success for connecting production applications together throughout a hospital environment. It definitely cuts down on replication, and provides a well defined interface for radically different systems to access the same database. -- eric ...!seismo!mimsy!aplcen!osiris!eric