bruce@zeb.USWest.COM (Bruce W. Hoylman) (12/13/89)
I'm evaluating RDBMS packages for potential use in a major development effort in my company. I am having trouble locating *ANY* type of benchmark/performance data for the RDBMS packages I am considering. Maybe I'm looking in all the wrong places. The packages I am currently evaluating are: o Progress Progress Software Corporation o Ingres Relational Technology, Inc. o Sybase Sybase, Inc. o Informix Informix Software, Inc. o Oracle Oracle Corporation I am particularly interested in results derived through embedded SQL commands in 3GLs, 4GL, report writers and form tools (if possible) with mainly ANSI standard SQL calls. Otherwise, *ANY* information would be greatly appreciated. Alternately any information SOURCES which might provide me with this type of information would be welcome as well. Please e-mail replies. If there is enough interest in my findings, I will certainly post a summarization. Thanks in advance. Later ... Bruce W. Hoylman (303-889-5806) -- Standard disclaimer: "These views are bruce@mirage.USWest.COM probably my own ..." -- ncar!boulder!uswat!bruce
jkrueger@dgis.dtic.dla.mil (Jon) (12/13/89)
bruce@zeb.USWest.COM (Bruce W. Hoylman) writes: >I'm evaluating RDBMS packages for potential use in a major >development effort in my company. And, like most people, you're focusing on performance, instead of functionality, reliability, vendor support, and programmer productivity. Please reconsider. Don't be like most people. >The packages I am currently evaluating are: > o Progress > o Ingres > o Sybase > o Informix > o Oracle You can expect adequate performance from any of these. Within a few years, you can expect little difference in performance between any of the survivors. Please look at things that really matter. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.
robf@squid.rtech.com (Robert Fair (ECSC Tech Support)) (12/14/89)
>From: bruce@zeb.USWest.COM (Bruce W. Hoylman) writes: > o Ingres > Relational Technology, Inc. INGRES comes from Ingres Corperation (what was RTI). The name changed earlier this year. Robert Fair Technical Support Ingres Corperation.
eric@pyramid.pyramid.com (Eric Bergan) (12/15/89)
In article <698@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >bruce@zeb.USWest.COM (Bruce W. Hoylman) writes: > >>I'm evaluating RDBMS packages for potential use in a major >>development effort in my company. > >And, like most people, you're focusing on performance, >instead of functionality, reliability, vendor support, >and programmer productivity. Please reconsider. >Don't be like most people. > [...] >You can expect adequate performance from any of these. >Within a few years, you can expect little difference >in performance between any of the survivors. Please >look at things that really matter. I'm afraid I disagree. I agree that if you average across all applications, etc, that the DBMSs tend to be about the same, but the fact is that there can be significant differences in performance on specific facets - differences so great as to rule out the DBMS. Some examples: - complex query that one DBMS properly parses out, and another doesn't - can mean a several order of magnitude difference in performance - backup strategy - some products can take 8 times longer to do backups than others, due to their buffering/backup strategies. Can be very important if backing up larger databases - differences in buffer management, particularly with respect to what to do about linear searches, can cause major differences in performance. (It is true that TP1 is not a great distinguisher of performance any more...) I'm sure if pointed out to the vendors, any shortcomings versus a competitor will go on the list of things to change, but that list can get very long, and not all items make the cut for each release. But if the effect is a difference between a 1 second response time and a 100 second response time, I submit that is a very important point in choosing a database. My suggestion is that the only way to assess the performance of a database system for your application is to do as accurate a job as you can at developing a benchmark which models your application and environment, and then run it on the DBMS systems under selection. General benchmarks, such as TP1 or DeWitt are only useful if you can understand the relationship between the TP1 or DeWitt application model and your own. -- eric ...!pyramid!eric
pan@propress.com (Philip A. Naecker) (12/18/89)
In article <4703@uswat.UUCP>, bruce@zeb.USWest.COM (Bruce W. Hoylman) writes: > I'm evaluating RDBMS packages for potential use in a major > development effort in my company. I am having trouble > locating *ANY* type of benchmark/performance data for > the RDBMS packages I am considering. Maybe I'm looking > in all the wrong places. > >... > Bruce W. Hoylman (303-889-5806) -- Standard disclaimer: "These views are > bruce@mirage.USWest.COM probably my own ..." -- > ncar!boulder!uswat!bruce -- Without intending to be insulting, a reasonable question is "Why do you think that this information might be of help to you?" As a consultant who specializes in building high-performance data management applications (almost always using a relational database underneath), I can tell you that "Your mileage may vary" is more than just a cute saying in the area of relational database performance - it is the critical factor that you must understand and take to heart. If you believe that performance is going to be a major factor in your selection of an RDMS, then I strongly suggest that you use a suite of benchmarks built from your own (most important) applications. Anything else is just not sufficiently meaningful to be considered in any rational sort of way. At the very least, to make use of a "standard" benchmark you would need a deep understanding of the relationship between you own application(s) and the standards. And since the standards as generally completely unrealistic in a great many ways, even if you have that understanding you will likely have very many unanswered questions regarding how your own application will perform. Of course, almost no one either has (1) a sufficiently complete understanding of their most critical applications to build such a benchmark suite, (2) the time, money or inclination to do so, or (3) the environment in which to perform such tests. Cie la vie. If you happen to be lucky enough to have a narrow range of applications that you want to use with the RDMS, i.e.: o a very update-intensive application o an application with mostly ad-hoc query to stable data o a read-only application with full reloads of the database o a single-writer application o or some other rather monolithic characteristic that dominates all database accesses then you might be able to use some standard benchmarks that represent such extremes in normal RDMS usage. However, most *real* applications are not easily represented by such extremes. If you haven't already done so, I suggest you stop spending time looking for benchmarks and start spending time rigorously documenting the characteristics of your application(s). Such parameters as transaction volumes, a preliminary data model, update characteristics, referential integrity requirements, hardware constraints (especially in the disk subsystem), requirements for distribution through the network, de-normalizations you might be willing to make for performance, and so on. These factors will be of much more use to you in constructing a truly useful benchmark (even if it is synthetic) than will most of the information you are likely to find about the publically available benchmarks and how they perform in your proposed hardware environment. Of course, the above steps are useful not only for understanding the performance impacts of your RDMS choice, but also for identifying differences between RDMS's in other important areas (ease of development, tools for performance monitoring, data integrity characteristics, portability, network distribution, etc.) Even in building high-performance systems, I believe that the performance of the database system itself (given any of the major players, including some you haven't listed) is probably no more than 10% of the problem. _______________________________________________________________________________ Philip A. Naecker Consulting Software Engineer Internet: pan@propress.com Suite 101 uunet!prowest!pan 1010 East Union Street Voice: +1 818 577 4820 Pasadena, CA 91106-1756 FAX: +1 818 577 0073 Also: Technology Editor DEC Professional Magazine _______________________________________________________________________________