From: Ian King (iking_at_killthewabbit.org)
Date: Mon Feb 02 2004 - 17:07:21 PST
The authors describe their experience with an implementation of the Grapevine
distributed
database system within an enterprise, the Xerox Corporation. The system was
implemented
primarily in support of email and access control. It was built on top of a
Xerox
proprietary software platform in a proprietary language.
This paper is twenty years old, and the changes are striking; the "server"
machines held as
much total system physical memory as is commonly seen in memory caches today,
hard disks
were a whopping 5MB, and a procedure call was measured in tens of microseconds,
instead of
nanoseconds. A large-scale deployment was considered to be in the thousands of
users.
Nonetheless, the principles explored are still in use today, and clearly are not
dependent
on enormous processor power or extensive resources to be effective.
In describing Grapevine as a 'distributed' system, it is important to clarify
that what is
distributed is data and, to some degree, state; system code is duplicated in
full on each
node. By contrast, there have been other systems that distribute procedures,
either
statically or dynamically, with one or more protocols to emulate the run-time
environment
seen on a single machine. Grapevine's primary strengths were in its ability to
route
requests to the owner of a particular piece of information, and to sensibly
partition that
information for redundancy and reliability.
Grapevine's data schema was fairly flat and simple, and it is significant that
the only
complicating factor, that of object groups (i.e. mailing lists), caused a great
deal of
consternation. The system's performance was found to be quite sensitive to the
organization
of data, i.e. the partitioning opportunities inherent in the schema. Some
changes were made
in recognition of the heavy overhead of some of the necessary replication
patterns, but some
limitations were persistent and were simply accepted.
I was surprised that server-name caching was not employed, as one of the
performance issues
was when a transaction was begun with one server, but continued on another.
Also, the idea
of path-cost metrics would have helped optimize performance when multiple paths
(some involving dial-up lines)
were available; one becomes so accustomed to the BIND utilities' use of this
idea that it seems
odd when it is not present. (It is not a big surprise that Xerox network
protocols did not
achieve the same widespread use as TCP/IP.)
It was interesting that the authors describe the maintenance structure
established to allow
remote "experts" to diagnose errors, and administrators to manage the system;
these roles
were quite distinct. However, both roles were involved in statically balancing
use
patterns, through such means as assigning certain servers to certain roles (e.g.
secondary
mailboxes). One of the key features in most modern distributed systems is
dynamic
load-balancing; arguably, the empirical data provided by such studies as this
one
demonstrated the importance of this feature set.
This archive was generated by hypermail 2.1.6 : Mon Feb 02 2004 - 17:27:10 PST