NFS in a heterogeneous environment

[Eric Bergan]

In article <2530 at phri.UUCP>, roy at 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