Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!zen!ingres.Berkeley.EDU!larry From: larry@ingres.Berkeley.EDU (Larry Rowe) Newsgroups: comp.databases Subject: Re: Database Machines Message-ID: <2918@zen.berkeley.edu> Date: Tue, 23-Jun-87 11:10:42 EDT Article-I.D.: zen.2918 Posted: Tue Jun 23 11:10:42 1987 Date-Received: Thu, 25-Jun-87 01:53:38 EDT References: <2861@blia.BLI.COM> Sender: news@zen.berkeley.edu Reply-To: larry@ingres.Berkeley.EDU.UUCP (Larry Rowe) Organization: University of California, Berkeley Lines: 89 Keywords: servers vs. distrib is more interesting... In article <2861@blia.BLI.COM> billc@blia.BLI.COM (Bill Coffin) writes: >>From larry@ingres.Berkeley.EDU (Larry Rowe) Wed Jun 17 09:19:02 1987 >>Several comments on the recent discussion of ``database machines.'' >> >>2. The above analysis says that Sybase has a creditable strategy [ ... ] >> [ ... ] they will quickly fall >>into the morass of customizing the code for N environments [ ... ] > >This is a problem on all distributed and all server architectures. >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. btw, from what i can tell, most software vendors are implementing (software) servers (e.g., rti, sybase, oracle, ...). > >> [ ... ] >>5. Another thing. When doing performance comparisons, it is important to >>compare apples and apples. Numbers ought to be $'s/xact (guess what, a >>program on an ibm 3094 is faster than a vax!) and/or use identical hardware >>(2 processors are better than 1). i'm tired of seeing claims that a dbmachine >>is faster than a loaded central machine. of course it is, the central machine >>has other things to do. compare the performance/cost to buying a larger >>central machine or buying a second general purpose processor. > >This is odd. When you compare a loaded front end vs. a dbmachine, you >are comparing real-life usages. If you care about db speed, then you must >consider the typical work loads. Secondly, buying a bigger central >machine may solve a "raw" speed problem, but server architectures still >solve the problem of sensitivity to the host work-load. Most people >really do care if some host process causes db accesses to slow to a >crawl, or if db access causes other important (non-db) processes to >wimp out. A faster machine may get things going faster, but the >sensitivity is still there. > 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. btw, another major advantage of all back-end dbservers is the ability to interconnect different host computers. for example, i think 50% of teradata's sales come from the fact that they are the only dbms available today that allows applications on VM and MVS to share access to a database. britton-lee has a similar advantage with pdp-11's and vaxes. over time, all software dbms's will offer similar features. > >>2. Distributed DBMS's are a big, big win. [ ... ] > >Why? I'm convinced that many of the people who THINK they want >distributed DBMS's REALLY need server architectures. See Jim Gray's >article in the May UNIX REVIEW. I won't elaborate here -- but >I would like to see a distribution vs. server discussion on the net. >For the record, I'm not "opposed" to distributed DBMS architectures, >but I DO think they're being oversold. There are job mixes that >make servers look bad, and there are job mixes that will make >distributed dbms's look bad. Mr. Natural says, "get the right tool >for the right job." > i haven't read jim's article, but knowing him and having read some tandem tech reports on the topic, i think i have some additional insights. first, application design for distributed applications is very, very hard. average people don't have the experience and the vendors products do not offer enough help yet to make it easy to define them. consequently, only pioneers and very brave people will attempt to build them. btw, tandem has only recently come out with an SQL interface to its distributed dbms offering. i'll be curious to see how much usage goes up now that end-users and mere humans can access the distributed databases. 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. 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.