sas@beta.lanl.gov (Steven Smith) (12/17/88)
I am looking to the commercial database world to help me leverage a large problem with a few people. We are moving our "system" from 3 VAX 11/785's to N Sun4/260 class machines. Our requirements for reliability, flexibility and maintainability suggest that talking to a commercial database through SQL would help us enormously. The big hitch is that we will have approximately 12 machines and the rest of the design of the system involves a layering and redundancy of critical resources such that the effective degradation of the system is on the order of N where N is the number of machines not working. This mostly means having every resource redundant. For data and databse it also means having accurate up to date information on each node such that isolation of the node does not cripple it nor does the loss of any other node affect it's performance. What I need to know is just where distributed database technology is and how much can we expect from it? My model is that on each node, there exists some "work" to do and some "resources" to do it with. If the resources aren't available for any reason it is neccesary that other nodes be able to get at that work and if there is no work to be done it is desireable that "work" from another node be available to the local "resource". Simultaneously, the status of the "work" and the "resources" needs to be known virtually anywhere and nodes that are temporarily isolated should be able to continue on their "own" "work" and the other systems should be aware of the "work" there and it's indeterminate status. Yet another constraint is that we use standard interfaces and have equivalent products available from alternate sources with only performance differences. We will be running Sun 4's but can't afford to lock to a single vendor. We need to maintain at least the possibility of vendor independence! Thanks in advance for all your input Steve
jon@altos86.UUCP (Jonathan Ma) (12/21/88)
In article <22995@beta.lanl.gov> sas@beta.lanl.gov (Steven Smith) writes: > We are moving our "system" from 3 VAX 11/785's to N Sun4/260 class >machines. Our requirements for reliability, flexibility and maintainability >suggest that talking to a commercial database through SQL would help us >enormously. The big hitch is that we will have approximately 12 machines >and the rest of the design of the system involves a layering and redundancy >of critical resources such that the effective degradation of the system >is on the order of N where N is the number of machines not working. This >mostly means having every resource redundant. For data and databse it >also means having accurate up to date information on each node such that >isolation of the node does not cripple it nor does the loss of any other >node affect it's performance. > What I need to know is just where distributed database technology >is and how much can we expect from it? My model is that on each node, >... As far as I know, there isn't any commercial SQL DDBMS that will both be distributed databases and distributed load. Large databases can be distributed across many machines, eg. Sun 4's, however, reliability and performance should be a factor of network performance (bandwidth, load average, etc). I'm pretty sure that all the major database vendors have something to offer, but, what you are looking for is probably beyond their products. BTW, loss of a node may be critical to your large databases if some tables are located on that node only (data not available). > Yet another constraint is that we use standard interfaces and have >equivalent products available from alternate sources with only performance >differences. We will be running Sun 4's but can't afford to lock to a single >vendor. We need to maintain at least the possibility of vendor independence! I've heard from my friends working at various database vendors that they are working on an _universal_ front-end (user interface). I'll believe it when I see it. >Steve -Jon- Jonathan Ma, Software Engineer / Database Altos Computer Systems UUCP: {sun,pyramid}!altos86!jon Disclaimer: These openions are mine, not my employer's. Any further discussions or corrections should be directed to the NET or me.