Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!cmcl2!esquire!roger From: roger@esquire.UUCP (Ro Reid) Newsgroups: comp.databases Subject: Re: Data Base Machines Message-ID: <650@esquire.UUCP> Date: 22 Sep 88 14:49:25 GMT References: <21755@tut.cis.ohio-state.edu> <664@stech.UUCP> Reply-To: roger@esquire.UUCP (Ro Reid) Organization: Mondo Connie Francis Lines: 66 in article <21755@tut.cis.ohio-state.edu>, mcclure@tut.cis.ohio-state.edu (James Edward McClure) says: > > Could someone please tell me exactly what a data base machine is and > how if differs from a DBMS (besides being hardware based)? > > Thanks for your help!! Speed (fast as hell, especially on complex queries) Cost (more than a software-based DBMS by quite a factor) Number of things that can go wrong (2-3 times more than a software DBMS resident on the host) Elaboration: At one time the ONLY way to get serious speed without completely swamping your host was to have a separate box to offload the database work to. This box has it's own hardware and software specifically designed to be fast at RDB type things, instead of being general purpose. The drawbacks were always there: more hardware to fail, a network (or some sort of interface) is involved and can fail, and lack of portability: in a Unix shop, you can move your software to the newest, latest fastest box, regardless of vendor. A hardware database machine is about a proprietary a beast as there is. Things have changed since we bought our first database machine 7 years ago. The 11/70 is no longer the workhorse of the Unix world, there are some fast, relatively cheap boxes out there and they keep getting faster and faster. So now many applications can afford to use the more generalized hardware to take advantage of the speed gains as they are developed, even if you maintain the separation between the front end and the back end, and basically make yourself a database machine by loading a software-based DBMS on one box and using another box as host. My experience is that right now, there are some very good software-based DBMS's out there that can negate the need for a specialized database machine. This holds until you start doing things above a certain level of complexity. For example, we found a software DBMS that was faster than our database machine, until we hit it with 5,6,7 way joins. And then the software system went to hell in a bitbucket, while the hardware system continued to be fast. We also found that software systems didn't do so well when the conditions for the retrieve got real complex and nasty. These are by no means final benchmark figures on all software systems, which is one reason I'm not naming names. But if you are not going to torture a database system the way we do, you probably should stick to software. It's when you find that there is no software out there that can do the job for you that you have to start considering database machines. We still have hopes that we can move to a software based system, if we can find one that can get the work done in the available CPU cycles for us. If you want architectural type details, you might contact BrittonLee; they might be glad to fill you in. I've had it explained to me before and it's amazing the things they do to make that sucker hum! -- Ro Reid {rutgers|phri|cucard}!cmcl2!esquire!roger uunet!esquire!roger roger@woof.columbia.edu "...to understand is always an ascending movement; this is why comprehension ought always to be concrete. (one is never got out of the cave, one comes out of it.)" -Simone Weil, First and Last Notebooks