Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!voder!blia!miket From: miket@blia.BLI.COM (Mike Tossy) Newsgroups: comp.databases Subject: Re: DB engine embedded in the OS? (long) Message-ID: <8951@blia.BLI.COM> Date: 23 Aug 89 20:29:05 GMT References: Distribution: comp Organization: Britton Lee, Los Gatos, CA Lines: 92 In article , hargrove@harlie.sgi.com (Mark Hargrove) writes: > > (Stuff deleted) > > 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. Tandem is basically in the state already; DEC insists > they will be. 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]. >>> WARNING! I work for a vendor! (Who agrees with DEC and Tandem.) <<< (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. (2) Since the development cost of integrating the dbms and operating system together is paid once by the dbms vendor vs the alternative strategy where all users pay for extra MIPS and disk speed. For the society as a whole is is cheaper to integrate the dbms and o/s, assuming that the system will be replicated a significant number of times. (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. (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! (5) tim@sybase.com writes "The challenge in designing an OS-hosted DBMS is to use only the most basic OS functions (such as user-buffered disk I/O and basic front-end/backend IPC services). ... ... That is, added resources should not be used up by overhead such as OS scheduling and heavyweight process state, they should be used directly by the DBMS to run applications faster or keep more of the database memory resident." By that, I think, he means that they have built an integrated dbms & o/s that runs on top of a regular o/s that they don't really use. I place Sybase in the DEC / Tandem / ShareBase camp on this one. (No big suprise to anyone who knows the ShareBase / Sybase history.) (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. 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. (7) I predict this will become a less important "religious issue" as evolving operating systems like UNIX continue to improve their RDBMS support. -- Mike Tossy ShareBase Coropration miket@blia.bli.com 14600 Wichester Blvd (408) 378-7575 ext2200 Los Gatos, CA 95030 (Formerly: Britton Lee, Inc.) The preceeding might be (probably is - in fact) close to the opinion of ShareBase Corp; but if you think I bothered to clear it with anybody other than myself you're crazy.