Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!voder!cullsj!gupta From: gupta@cullsj.UUCP (Yogesh Gupta) Newsgroups: comp.databases Subject: Re: DB engine embedded in the OS? (long) Message-ID: <671@cullsj.UUCP> Date: 24 Aug 89 17:00:50 GMT References: <8951@blia.BLI.COM> Distribution: comp Organization: Cullinet Software, San Jose, CA Lines: 101 In article <8951@blia.BLI.COM>, miket@blia.BLI.COM (Mike Tossy) writes: $ In article , hargrove@harlie.sgi.com (Mark Hargrove) writes: $ > [...] $ > One group of vendors (most notably DEC and Tandem) are making very strong $ > arguments that most, if not all, of a DB engine should be embedded in the $ > operating system. [...] $ > Both argue that high performance DB's *require* this approach. $ > $ > The other group of vendors argue that this is just not so -- except for $ > extreme cases, even heavy OLTP applications can be run with the DB engine $ > as a "normal" process, running on top of an OS. Their arguments are generally $ > based on the notion that MIPS (and to a lesser extent, disk I/O's) are $ > cheap -- and getting cheaper fast. Performance can always be increased by $ > throwing cheap MIPS and faster disks at the problem. [well, the argument $ > is more sophisticated than this, but you get the drift]. $ No, we do not argue that you can throw cheap MIPS and faster disks at the problem. The buyer is really interested in the price that needs to be paid for the whole solution, and that includes the hardware, the software, the implementation cost, and the maintenance cost (BTW, the later 2 quite often dominate the first two!). Independant software vendors would not be in business if they could not provide competetive solutions. $ (1) Even in the era of "cheap MIPS" it tends to be more cost effective $ to efficently use a resource than to waste it. Remember both the $ efficent and the wasteful use the same hardware. I agree with the above. But I do not agree with the fact that you have to integrate the DBMS into the OS to achieve high performance. $ (2) [more stuff on why we should not waste resources deleted] $ (3) ShareBase Corporation maintains atleast a 4 to 1 price/performance $ advantage over Oracle on VAXs largely due to the dbms/operating $ system integration in our database servers. (There are other tricks $ not relevant to the discussion at hand.) This has been true since $ 1981. The explosion in cheap MIPs hasn't changed the ratio; because $ the hardware improvements help us too. Now that we are touting products, I know of instances where customers who ran their business with Sharebase went to an independent vendor *because* of cost effectiveness of the DBMS engine. To get the required performance on the Sharebase system would have cost more than to use stock hardware and OS with a third party RDBMS. $ (4) DBMS & O/S integration probably only really pays off if you've got $ a significant database problem. If database work is taking 100% $ of your resources (as it does in a database server) it is logical $ to optimize how you do database. If database isn't a major factor $ then find out what is and optimize that! Optimizing the database work does *not* mean picking an RDBMS/OS integrated solution. $ (6) jkrueger@dgis.daitc.mil writes: $ > I remember, not so very long ago, hearing that operating systems had to $ > be written at machine level, or performance would be unacceptable. And $ > that shells had to be part of the operating system. And that records $ > had to be hardwired into file manipulations and record structure $ > imposed on all i/o. Oh yes, and that database programming had to refer $ > to specific tracks and cylinders when defining and accessing data. $ > $ > Have we learned nothing? $ $ How about network protocols running as user processes, or $ windowing systems without operating system support? Sometimes $ integration makes sense. The issue is not whether you need some operating system support for the efficient implementation of a certain functionality. It is whether current OSs provide enough support and capabilities that the independent software vendors can provide efficient solutions. That is true for many OSs today and is becoming more and more true for the others. The original questioner (hargrove@harlie.sgi.com (Mark Hargrove)) asked whether the claim by HW vendors that the DBMS has to be embedded in the OS for it to be efficient was correct. As you can see on the Dec platform today, it is not true. $ Assume that you are doing a significant amount of DBMS work. $ Who should decide when is the correct time to do read-ahead? $ The O/S could guess or the RDBMS (which *knows* when it is using $ a scan and when it is using an index) can tell the O/S. $ Who should decide what buffers to page out? The O/S could guess $ or the RDBMS (which *knows* the contents of the buffer) can $ tell the O/S. An OS that allows the "user" (in this case the DBMS) to specify certain buffer management and I/O policies would do very well, thank you. $ [...] $ -- $ Mike Tossy ShareBase Coropration ------- -- Yogesh Gupta. | The opinions expressed in this article Cullinet Software, Inc. | are those of the author and do not | represent those of Cullinet Software | or the plant on my desk.