Re: db2 vs oracle
Date: Sat, 28 Aug 2004 21:11:55 GMT
Message-ID: <4130F51E.7020102_at_comcast.net>
Data Goob wrote:
In
>>> Larry's
>>> own words they indicate the direction of the company has less to do with
>>> being a database company and more to do with applications.
>>
>>
>>
>> Complete and utter bullshit. You have absolutely NO basis for your
>> characterization, yet you make it. Why ?
>>
>
> It was based on experience?
Who's ?
>>
>> You obviously have no idea how the grid applies to business. Note that
>> one of the foremost proponents of the grid architecture is indeed Ford.
>>
> > Enlighten me on the grid. I'm getting my SETI screen-saver fired up, and > turning on the Lava Lamp. LOL. >
Presuming that this was not a rhetorical question, the argument goes something like this.
Silo's of computing are bad. Seperately configured systems for individual workloads are bad - high cost, each over worked individually but under utilized in terms of resources across the company. Labour intensive. Difficult to integrate, make secure, make highly available.
So as an alternative, consider a grid. As follows
Consider data management software that stores not only characters numbers and dates, but all your email, all your documents, all your multimedia, all your spatial, all your XML. Everything digital that you may care about. Not only that, but can truely do cross domain queries - for example, a single query that anwsers the question - "Find me all customers who previously placed but cancelled an order over the web (in XML), for a product whose shipping instructions mentioned special handling requirements due to fagility, where those customers are now with 5 miles of the new store we are just opening"
Place this data on a storage grid based on SAN or NAS storage shared amongst multiple systems, complete with intelligent software that automatically manages the data placement to give maximum performance and availablity for all those systems. The same data management software that then automatically backs up this data, automatically allows any change made in error to the data to be undo, automatically mirrors the data across two or more physical storage grids for redundancy and disaster recovery. Then add the ability to horizontally manage the physical storage across the organization simply by adding new disks to the storage grid and have the storage grid then automatically (and online) maintain the most optimal data/disk layout. Do this on with any disk solution, anywhere, and even with emerging low cost ATA technology.
Consider then the database grid - the machines that access the data on behalf of the applications. Consider a cluster of these machines, all very low cost commodity hardware, each with 2-4 cpus, intellgently sharing the workload and access to this data. Have workloads be able to expand across the physical boundary of a single machine. Have each workload definable as a level one object in the taxonomy, and be able to dynamically add or remove machines to and from a workload. Have service levels definable that determine how one defined workload should be failed over to other machines in event of an outage. Have service levels definable that determine the required performance characteristics for each workload, with the ability to react to an outage in the service by adding (or removing) more machines. Do this on any hardware, with any operating system.
Do the same thing at the application server grid level, but now also include all the web services, BPEL and SOA good geekness that is in that environment (of which I know little). Have the same service level definition of a workload that is defined at the storage and database level apply here as well, for end-to-end monitoring up and down the stack, and eventual dynamic sharing of the machine resources between the database and application server layer. Have the same definition of a user up and down through the entire stack as well. Manage ALL the users access, security, roles etc in one central location, with ALL other software using this information consistently - the same Mark Townsend - from the application login, to the browser cookie, to the app server connection, to the JDBC connection, to the proxied user identity in the database telling the system what I can and cannot access.
Then provide built in application level monitoring software that can start from the end user and trace a representative transaction up and down the stack - all the way from the browser across the network to the app server to the Java container to the executed SQL to the the storage IO. Have defined service levels for these transactions as part of the workload definition. Automatically alert an administrator if the service level starts to fail and provide the ability to profile where the problem is from one end to another, with the ability to step into any layer in the stack and diagnose the problem using wizards and advisors. Do this end to end tracing from any endpoint in the network. Then have the software just do this automatically for you, and simply tell you what needs to be fixed, by when, and how.
Then provide configuration management software that allows you to define the standard configuration for any one of these component layers, as well as your best practice security, HA, performance and deployment procedures. Centrally manage these configurations, and as new machines/disks arrives, just blow these configurations out to them and remotely build the machines. Automatically check every day with the vendor to see if any urgent patches/fixes are required to YOUR specific configuration. If so, have them downloaded to the central repository, and have these blown out to the targets as well. Have the same software then automatically checks every 24 hours to see that your best practice configurations have not been bypassed.
Then build a suite of business application on top of this.