jas@ernie.Berkeley.EDU (Jim Shankland) (05/08/89)
In article <509@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >Look, would you care to research different methods of ensuring >atomicity and serializability, support for them in commercially >available operating systems, and their tradeoffs in performance, >development, installation, scalability, portability, multiprocessor >support? If some technically qualified person (which I am not, by the >way) were to post a summary on this topic, we'd all be most grateful. That would be quite a summary :-). Lots of open research issues here. Just a quick thought or two: a DBMS designed around shared memory is unlikely to make good use of a set of loosely coupled processors such as a set of workstations connected by an Ethernet. Sure, you can punt and run front-ends on diskless Suns, and have them talk to a DBMS server on your big fileserver Sun (or Pyramid, or Sequent, or ...). But you're missing the opportunity to spread your disks around the network, and gain both performance (through I/O parallelism) and reliability (through redundancy), as well as making good use of the, say, 75-1000 aggregate MIPS and 100-1000 Meg of RAM on the network. One answer to that problem: run a DBMS server on each diskful workstation, and implement a distributed DBMS on top of them. That's RTI's INGRES/STAR approach, I think. There are persuasive arguments both for and against this approach. We live in interesting times. As long as a server is running on a single machine, building it around shared memory is a big win. Note that non-availability of shared memory on UNIX is rapidly becoming a non-issue: the commercial ports of Berklix all seem to have it; System V, of course, has it; and 4.4bsd will have it. In this context, cs_bob's assertion that relying on shared memory was a major architectural design error on RTI's part seems questionable, at best. Jim Shankland jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
robf@squid.rtech.com (Robert Fair) (05/08/89)
>Article 2633 of comp.databases: >Path: rtech!mtxinu!ucbvax!ernie.Berkeley.EDU!jas >From: jas@ernie.Berkeley.EDU (Jim Shankland) >Lines: 37 > > ... A DBMS designed around shared >memory is unlikely to make good use of a set of loosely coupled >processors such as a set of workstations connected by an Ethernet. INGRES R6 is not designed around shared memory as such, we just happen to need certain functionality for interprocess communication (IPC) and the only practical way to do it on UNIX is shared memory. >Sure, you can punt and run front-ends on diskless Suns, and have >them talk to a DBMS server on your big fileserver Sun (or Pyramid, >or Sequent, or ...). Which is exactly what INGRES net does, and is often a good solution for real-life problems. >But you're missing the opportunity to spread >your disks around the network, and gain both performance (through >I/O parallelism) and reliability (through redundancy), as well as making >good use of the, say, 75-1000 aggregate MIPS and 100-1000 Meg of RAM >on the network. This is inherent to any single server running on a loosly coupled network, and has little to do with shared memory - a single process (a server) can only run on one process-or at a time. Thats why INGRES's multi-server architecture was implemented - multiple servers can be spread across linked processors (i.e VAX-Clusters for VMS users, or the multiple processors on Sequent machines) giving better performance. > >One answer to that problem: run a DBMS server on each diskful workstation, >and implement a distributed DBMS on top of them. That's RTI's >INGRES/STAR approach, I think. There are persuasive arguments both >for and against this approach. We live in interesting times. Thats pretty much what STAR does, although its optimizer is rather more sophisticated that a standard DBMS optimizer - it has to include things like network overhead, where to put temporary results etc in its calculations. > >As long as a server is running on a single machine, building it >around shared memory is a big win. Note that non-availability of >shared memory on UNIX is rapidly becoming a non-issue: the commercial >ports of Berklix all seem to have it; System V, of course, has it; >and 4.4bsd will have it. Exactly! >Jim Shankland >jas@ernie.berkeley.edu > Robert Fair RTI Tech Support Disclaimer: This posting is done as an individual, not a representative of RTI !