Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!think!ames!amdahl!pyramid!voder!blia!billc From: billc@blia.BLI.COM (Bill Coffin) Newsgroups: comp.databases Subject: Re: Database Machines Message-ID: <2877@blia.BLI.COM> Date: Thu, 25-Jun-87 16:14:57 EDT Article-I.D.: blia.2877 Posted: Thu Jun 25 16:14:57 1987 Date-Received: Sat, 27-Jun-87 04:58:34 EDT References: <2861@blia.BLI.COM> <2918@zen.berkeley.edu> Organization: Britton Lee, Los Gatos, CA Lines: 96 Keywords: servers vs. distrib is more interesting... >From larry@ingres.Berkeley.EDU (Larry Rowe) >>Even on a one-machine server architecture you need host software. > >Remeber to distinguish between a hardware server and a software server. >again, you can build a software server dbms and run it on conventional >hardware. Yes, I noted that. In fact, I think a s/w server will beat a hardware server in price/performance except at the high end (the people who will pay anything for the extra speed). However, an effective server needs to control its hardware. I'm saying that a server should have a whole machine to itself and should have a custom operating system (or an off-the-shelf OS that has been pacified). > btw, from what i can tell, most software vendors are implementing >(software) servers (e.g., rti, sybase, oracle, ...). I think there is a difference between a server (hardware or software) and a distributed dbms. Oracle and, I think, RTI are implementing distributed dbms's. Sybase is implementing a server. My point was that there is a proliferation problem no matter which architecture. Perhaps life is a bit simpler at BLI, since we don't have to port the dbms internals, but we still have to port the host software. There's no free lunch in this area. >the point here is that without including cost/performance in your comparison >everyone would buy the biggest machine(s) that ran their desired software. >personally, i'd love to have a cray performance machine for my personal >workstation. but, as we all know, it isn't practical. i agree that a >``back-end'' dbmachine may be the most cost effective and may offer substantial >performance benefits. what i don't agree is that it is the only solution >and that people should accept without questioning what their problem really >is. for example, an equally plausible solution to a heavily loaded central >machine is to off-load user-interface/application programs to a personal >workstation. from what i can tell, people don't really do these comparisons. I guess that I'm in agreement here. People need to analyze real-life situations when they choose a dbms configuration. Certainly a back-end isn't the only solution, and frequently it's a poor solution. btw, I think your alternative solution enhances the server argument -- why not offload the user-interfaces to bitmapped workstations (application servers) AND offload the dbms to a dbms server? And setup the old mainframe as a number-crunching server, and so on. It's nice to be able to hook up servers based on specialized abilities rather than put apples and pancakes in the same bag (ie: mutually antagonistic processes in the same machine). Anyway, comparing a back-end with an unloaded front-end is certainly not examining a real-life situation. >btw, another major advantage of all back-end dbservers is the ability to >interconnect different host computers. > [ ... ] britton-lee >has a similar advantage with pdp-11's and vaxes. Minor plug (here we go!): We also support data sharing between VM/CMS, Vax VMS, most major flavors of UNIX (SysV, BSD, Ultrix), MS-DOS, and a lot of other machines. > [ ... ] >second, tandem's distributed dbms is a single-vendor hardware solution. >when i visit companies and universities, senior managers say their number >1 problem is managing the diversity of hardware/software that proliferates >through the organization. a distributed heterogenous dbms can cover up >this diversity and give people control again of their corporate data. the >complete solution to this will take years to achieve, but from my discussions, >people really want it. also, some new application growth areas (e.g., >factory autmation) insist on distributed dbms's. so, i stand by my statement. OK, but it seems to me that heterogeneity and distribution are two different issues. I haven't yet seen any good solutions to the heterogeneity problem, just some talk. (Gray's article has some interesting observations on this.) Server architectures are well-understood and currently available. Mature heterogeneous/distributed dbms's are still in the future. Even whey they do mature, there will still be many situations in which a server is a clear win. >btw bill, what happens to a britton-lee customer who's bought 5 machines >and now wants to query data that is spread across the machines? do they have >to copy it by hand to one machine and run the query? all a distributed >dbms does, is make that operation easier. No, it's easier than that (now). However, it is not location transparent. OK, a distributed dbms is different from a server. They solve some similar problems, but they are not the same. I think it's going to be awhile before distributed dbms's can match the performance, reliability, and security of servers. The very nature of a server is that you don't worry about distributing data over many of them. If you do worry about that, then the server is probably not the solution you're looking for. (And, if you lick the heterogeneity problem then you can have N servers transparently within your distributed database.) -- W.H.Coffin. billc@blia.BLI.COM (ucbvax!{mtxinu|ucsfcgl}!blia!billc) >> the usual disclaimer about my employer and my wretched opinions. << >> the usual witticisms that swell netnews to ridiculous proportions. <<