Conference ulysse::rdb_vms_competition

1019.0. "Ingres FUD against Rdb" by EXHORT::GETTYS_B (Bill Gettys @CEO) Sat Oct 26 1991 02:57

I received the following from a customer today.  He has chosen Rdb for his 
plant site and is fighting a corporate edict for Ingres.  Apparently the Ingres
sales rep gave this document to an Ingres bigot in another location to help 
with bashing Rdb.  The document originated with the NY Dept. of Corrections.  
I have responded to (refuted, I hope) almost every paragraph.  You might watch
out for these objections in accounts where you compete.  The original is 
interesting.  It is unsigned and only by reading the text can you tell where 
it originated.  Nothing in the document identifies it as coming from Ingres, 
so I suspect that it is not exactly official.  Interesting reading though...  
They don't seem to like us very much!

Bill


                           MANAGEMENT SUMMARY

After closely examining the functionality, performance, and cost of Rdb and 
the Ingres RDBMS, the RDBMS Selection Committee has determined that the 
Ingres RDBMS offers more functionality and greater performance than Rdb, at 
a lower overall cost, and therefore, recommends the purchase of the Ingres 
RDBMS and application development tools.

During this evaluation, the RDBMS Selection Committee found that Ingres 
provides functionality that is unmatched by Rdb or any other RDBMS 
currently available for VAX/VMS, including:

    A Client/Multi-Server architecture that makes efficient use 
    of system resources and, in particular, takes full advantage 
    of all VAX configurations, including VAXClusters and 
    Symmetric Multiprocessors;
    
    An AI-based query optimizer that uses a detailed set of 
    statistics on data distributions to efficiently process every 
    database request;
    
    Resource controls that prevent users from monopolizing system 
    resources with "runaway" ad-hoc queries;
    
    Business rules embedded "once" within the database, providing 
    a high degree of data integrity and reduced application 
    development and maintenance costs;
    
    Advanced access controls that provide a high degree of data 
    security while reducing database administration costs;
    
    User-defined data types that enable the RDBMS to precisely 
    model business data and practices while reducing development 
    and maintenance costs;
    
These and other features, including I/O reduction techniques not available 
with Rdb, give Ingres a PERFORMANCE advantage over a wide range of 
transactions, compared with Rdb.  Also, of crucial concern to DOC is 
Ingres' advantage in the APPLICATION DEVELOPMENT TOOLS area:

     Ingres has a wealth of sophisticated development and 
     decision-support tools that is not matched by Digital and 
     that will allow Department of Corrections to develop robust, 
     efficient applications more quickly.
     
Although the initial cost of the Ingres RDBMS is higher than the initial 
cost of Rdb, it is the evaluation committee's estimation that total cost 
over the system lifecycle is less with Ingres than with Rdb and that the 
choice of Ingres offers Department of Corrections far greater flexibility 
in hardware and software growth planning.

                         BASIS FOR COST COMPARISON

HARDWARE COSTS

Additional hardware expenses must be added to the costs for Rdb due to 
Rdb's relative inefficiency compared with Ingres.

The Ingres RDBMS incorporates a number of features which account for its 
greater efficiency compared with Rdb.  These include:

    A Client/Multi-Server architecture that requires an 
    incremental memory cost of only 50 KB per user.  The 
    multi-threaded database server process requires 2-4 MB for 
    effective operation.  Rdb uses a shared executable 
    architecture that requires 500 KB of memory per user.  
    Therefore, the Ingres RDBMS is more efficient than Rdb for 
    more than 8 users.  Because the RDBMS that is selected will 
    be used by an estimated 200 users, additional memory would be 
    needed to provide adequate performance for Rdb.
    
    An automatic AI-based query optimizer that uses statistics to 
    find the most efficient query plan.  
    Ingres is able to store detailed histograms of current data 
    value distributions.  It consults these statistics before 
    choosing a physical access plan to solve a query.  For 
    example, the optimizer would determine the best lookup plan 
    for the query "SELECT * FROM INMATES WHERE INMATES.AGE > 70" 
    knowing ahead of time that relatively few rows existed in the 
    database.  This could save, for example, a costly table scan.  
    This level of detail of statistics that Ingres can maintain 
    produces superior performance over a wide range of query 
    types.  In contrast, Rdb stores only the most rudimentary 
    type of statistic.  We expect poorer query performance from 
    Rdb than from Ingres, with greater CPU, disk, and memory 
    overhead.
    
    I/O reduction techniques to greatly improve I/O throughput.  
    Ingres has implemented a tunable fast commit (deferred write) 
    technique as well as shared cache, among other TP 
    optimization features.  These features mean that Ingres 
    intelligently caches data pages and that users often do not 
    have to access disk at all (even for multiple updates).  
    These features are absolutely crucial to TP-level 
    performance.  Rdb does not utilize these techniques and will 
    therefore have poorer I/O performance than Ingres.
    
    Database-level procedures that allow al users to share the 
    save precompiled code in memory for often-used transactions.  
    Each procedure may execute man SQL and 4GL statements before 
    returning control back to the client program.
    
    Shared compiled query plans that allow all users of an 
    application to share the same precompiled query execution 
    plans in memory.  These "repeated" queries greatly reduce CPU 
    overhead for query optimization.  Rdb does not support shared 
    compiled query plans, and thus each query MUST be optimized 
    every time it is executed by any user.
    
    Eight physical storage structures storage options, that 
    permit great flexibility in tuning the physical database 
    schema for optimum performance.  Rdb provides far fewer 
    physical storage options for the DBA.  This is expected to 
    affect I/O performance once again.
    
    Resource controls that make ad-hoc usage of the database 
    practical.  The Ingres RDBMS allows the DBA or systems 
    administrator to set limits on the I/O and database resources 
    that may be consumed by a user for any query.  The Ingres 
    query optimizer calculates the estimated cost of each query 
    and, if the estimated cost exceeds allowed limits, it aborts 
    the query before it ever runs.  Rdb does not have resource 
    controls, and thus ad-hoc usage of the database can have 
    unpredictable affects on systemwide performance.  For 
    example, an authorized user could easily issue an unqualified 
    inquiry that would potentially return millions of rows and 
    bring the system to its needs.
    
    Business rules that tare implemented in the database and are 
    precompiled and shared in memory by all users.  Business 
    rules are implemented suing database procedures, and 
    therefore have all the performance benefits of database 
    procedures.  Rdb does not support database-level business 
    rules.  (However, Rdb does support database-level referential 
    integrity, as does Ingres).  BUSINESS RULES STORED IN THE 
    DATABASE ONCE MEANS THAT THEY DON'T HAVE TO BE DUPLICATED IN 
    EACH AND EVERY PIECE OF APPLICATION CODE.  This means shorter 
    development, fewer errors, less maintenance, and better 
    performance.
    
    User-defined datatypes stored in memory and shared by all 
    users.  Implementing user-defined datatypes in the database 
    engine rather than in application code make more efficient 
    use of memory and reduces inter-process communication.
    

DEVELOPMENT/MAINTENANCE COSTS

Several features of the Ingres RBMS have a positive impact on development 
and maintenance costs.  Therefore, additional costs must be allocated to 
Rdb solution.  The features of the Ingres RBMS which are of benefit to 
application development and maintenance and there estimated cost savings 
are as follows:

    Business rules stored at the database level.  Both the Ingres 
    RBMS and Rdb store referential integrity rules at the 
    database level.  However, Ingres provides additional 
    capability to define not only referential integrity rules but 
    also business rules in the database.  Simple examples of 
    business rules are "No employee may make more that his/her 
    manager", and If inventory falls below a certain point, 
    reorder."  Database-level business rules will out development 
    and maintenance costs significantly.  RATHER THAN CODING EACH 
    RULE IN EVERY APPLICATION TO WHICH IT APPLIES, A RULE IS 
    IMPLEMENTED ONLY ONCE AND IS MAINTAINED IN ONE PLACE.  We 
    estimate that 10-20% of all application code can be 
    implemented using database-level business rules.  Therefore, 
    using a conservative figure, use of business rules in the 
    Ingres RBMS will save an additional 10% in development and 
    maintenance costs compared with Rdb.
    
    ACMS, the TP monitor software that would accompany Rdb, 
    requires an entirely different set of programming skills than 
    those of Rdb.  ACMS is notorious, even with Digital, as being 
    a difficult, obscure system to program and maintain.  It is 
    rare (again, even within Digital) to find programmers who are 
    competent in ACMS.  In contrast, Ingres would require a much 
    more commonly found skillset in SQL database programming and 
    high-level database 4GL.  This point carries clear training, 
    start-up, and maintenance costs implications.  It is not at 
    all unreasonable to estimate an additional 10-25% in 
    development costs to cover ACMS programming and maintenance 
    alone.
    
    User-defined datatypes, or objects, which allow the database 
    to precisely model business data and practices.  User-defined 
    datatypes are defined once and are stored in the database 
    sever for al users and applications.  Examples of 
    user-defined datatypes are longitude/latitude, 360-day year, 
    and matrix.  With Rdb, conventional data (text, numbers) must 
    be manipulated by each application to provide the same 
    results as user-defined data types.  We estimate that between 
    5-10% of application code can be replaced by user-defined 
    datatypes.  Therefore, using a conservative figure, use of 
    user-defined datatypes in the Ingres RBMS will save an 
    additional 5% in development and maintenance costs compared 
    with Rdb.
    
    Resource controls to prevent inappropriate queries by end 
    users from monopolizing system resources.  Without these 
    controls, access to ad-hoc query and reporting tools will 
    need to be restricted to prevent "runaway" queries from 
    impacting system performance.  In this case, MIS will have to 
    handle more requests from users for one-time reports.  The 
    amount of extra work for MIS is difficult to estimate, but 
    given the current number of one-time requests handled by MIS, 
    we feel that an increase of 10% in overall workload when 
    using Rdb instead of the Ingres RBMS is a conservative 
    estimate.
    
Adding the percentages above leads to an estimated increase in development 
and maintenance cost of 45% if Rdb is used instead of the Ingres RBMS.


ADMINISTRATIVE COSTS

Additional administrative costs have been added to the cost of the Rdb 
solution compared with the Ingres RBMS solution.  Ingres incorporates 
several features that will result in lower database and system 
administration costs, including:

    Just as ACMS requires a completely different development and 
    maintenance programming skillset than Rdb, so too does ACMS 
    require a different set of administrative skills.  We 
    estimate this to carry at least a 10% cost penalty in terms 
    of training and administration time.  Additionally, it is 
    difficult to find experienced ACMS administrators.  While 
    Ingres RBMS administration requires training as well, most of 
    the skills are standard RBMS DBA-type skills.
    
    Automatic disk space management for both fill creation and 
    incremental increases in file size.  Rdb does automatically 
    allocate pages in existing files, but management of 
    multi-file tables, which is totally automated in Ingres, 
    requires the intervention of a systems manager for Rdb.  We 
    estimate that the administrative overhead of Rdb for disk 
    space management is between 5-10%.  Therefore, an additional 
    5% has been added to the administrative costs for Rdb 
    compared with the Ingres RBMS.
    
    Advanced access controls that enable the database 
    administrator to quickly grant permissions on the Ingres RBMS 
    to many users, and to easily grant permissions on entire 
    applications with a single command.  Compared with access 
    controls in Rdb, we estimate that this feature will save 
    10-20% in database administration costs.  Therefore, we have 
    added a conservative 10% to the administrative costs for Rdb 
    compared with the Ingres RBMS.
    
    Menu-driven performance monitor for the database servers, 
    logging system, and logging system.  While Rdb provides 
    monitoring tools of comparable ability, Ingres' performance 
    monitor is better documented and much easier to learn and use 
    effectively.  We have added an additional 10% to the 
    administrative cost for Rdb to reflect this.
    
Adding the percentages above shows an estimated increase in administrative 
costs of 35% if Rdb is used instead of the Ingres RBMS.


OTHER CONSIDERATIONS

If a decision for the Ingres RBMS is made solely based on cost, there is 
ample justification as the discussion above illustrates.  However, because 
the selection of the RBMS is a strategic decision of far-reaching 
importance to NYC Department of Corrections, other factors must be 
considered as well.

    Rdb is architected for an thoroughly "wired" to VMS only.  
    While DEC has announced the long-term intention to port the 
    product (or at least its interface) to other platforms, this 
    is a future.  Additionally, ACMS is widely regarded as 
    "unportable" because of its VMS dependences.  Ingres, on the 
    other hand, runs on VAX/VMS plus over 40 other hardware 
    platforms, including Ultrix and other Unix platforms, OS/2, 
    and MS-DOS.  DOC's Ingres/4GL application can be ported to 
    any of these platforms just by recompiling.
    
    The main benefit of Ingres' portability to other platforms 
    will be to allow Department of Corrections the future option 
    of taking advantage of the excellent price/performance 
    feature of non-proprietary hardware platform, such as DEC 
    Ultrix on MIPS RISC machines.  Use of Ingres would provide an 
    excellent RBMS for VAX/VMS while offering many alternatives 
    for the future, should NYC Department of Corrections which to 
    take advantage of them.  The selection of Rdb and ACMS would 
    lock DOC out of the option of adding the newest, best 
    price/performance hardware to its existing network without 
    having to rewrite its applications.
    
    Ingres Corporation has an excellent track record of support 
    for VMS.  The first commercial release of Ingres was on 
    VAX/VMS in 1981.  VAX/VMS is the primary RBMS development 
    platform for Ingres.  Ingres was the first third-party RBMS 
    to run on VAXclusters, only two weeks after VAXclusters were 
    first available.  Also, Ingres was the first third-party RBMS 
    to run o VMS 5.0.  The Ingres Client/Multi-Server 
    architecture is well suited for all VAX/VMS configurations:  
    single VAXs, Symmetric Multiprocessors (SMPs), and 
    VAXclusters.  In fact, only two commercial RBMSs can 
    currently take full advantage of a VAXcluster: Rdb and 
    Ingres.  Ingres is closely integrated into VAX/VMS, using 
    such facilities as the VAX Distributed Lock Manager (on a 
    VAXcluster) and individual RMS files for each table. 

Has anyone asked Ingres what their numbers are on various benchmarks, in 
comparison to Rdb's?  (on the same platform, of course, to compare apples with 
apples) If Ingres performance on U*IX is anything to judge by, their 
performance claims wrt to Rdb/VMS are laughable.  I believe that Ingres
are known not to be high performing compared with their competition.

Also, has anyone asked them how they do on the NIST tests for ANSI SQL 
conformance?  Or what their plans/commitments are to become ANSI SQL2 
conformant?  (I suspect that even ANSI SQL89 conformance will be a problem 
for them, despite their claims to support 'standard SQL'.)

    Ohh and remember to ask:
    
    - How do I store my 3000 byte row
    - How do I get my 1 employee and 10 projects rows clustered to be
    fetched in 1 IO
    - How about the REDO LOG file, how many users are using it ?
      and what if the disk where it resides fail ??
    
    aso. 
    Of course you rpbably already know that Cdd/Repository is currently
    behind schedule because of poor performance in Ultrix/SQL (Ingres).
    
    They can claim MUCH, but performance and ansi compliance are DEFINITLY
    not among valid claims !!!!
    
    Lars

To be honest, several points in .0 strike home (I mean Ingres is superior to
rdb in some architectural issues). However, at the end of the day, the decision
to go for rdb vs Ingres is decided on points like 'how well does it meed the
customer needs', not on how certain things are implemented. Very few customers
will, for instance, base a decision on how well a database cache is managed in
one implementation vs another (or if they do that, then there is something
wrong with their reasoning).

Having said that, let me join the Ingres-bashing bandwagon:

- one point where Ingres is really weak is the complete DBA environment: things
like backups, restores, db monitoring, db verification ... are very poor. This
is especially true when going for big dbs (how big is big? 500MB starts
becoming interesting). There is no way to do partial restores (to recover from
one disk crash), use an older backup, apply multiple journals, ...[except by
complex manual procedures].

- another point is the monitoring tool (IPM or Ingres performance Monitor). It
has some nice feature, but it is anything except a _performance_  monitor. It
allows you to look at what is happening with your databases in terms of
sessions, locks being taken, log space being used (it has this nice display
showing the log file progressing). It also has this very nice feature that
allows you to find who blocks who in lock conflicts with just a few key strokes
(far superior to what rdb 4.1 will provide).

That tool does not give you any indication on resource consumption by
transactions, response times, tps, etc ...

/albert

>    <<< Note 1019.3 by BEAGLE::GODFRIND "I cross-charge, therefore I am" >>>
>
>To be honest, several points in .0 strike home (I mean Ingres is superior to
>rdb in some architectural issues). However, at the end of the day, the decision

Hmmm, at what are they superior in architectural issues?

I've studied Ingres rather thoroughly over the years, including talking
with their most senior designers, and I believe that in nearly every
respect (and despite heroic efforts by their engineers) they are the most
primative of the major relational database engines on the market.  The
age and research beginings of the product show in nearly every aspect of
engine.

Hal

    Hal,
    
    Would you care to enter some of your thoughts re your last note?

Check out the the special issue of "The Buffer" we did for V3.0.  While a
few numbers have changed, the basic INGRES architectural problems remain.
Larry Carpenter may still have the material on-line (I have the original
notes I made somewhere around here).

Hal

    Regarding Ingres performance.
    
    We were invited by a SW house to help them to do a conversion from
    Ingres to Rdb in a cellular billing application. Tests done by this
    SW house proved Rdb to be superior to Ingres in performance. With
    Ingres, they could not even get a batch job done in 8 hours that needed
    to access about 1 million records; 600,000 was the limit in 8 hours.
    
    If their performance is so good, where are their TPC-A numbers?
    
    Henny Olthof, Tp-DB Netherlands

One interesting thing I discovered just recently while teaching the Ultrix/SQL
support course (Ultrix/SQL is Ingres 6.3 on Ultrix).

Ingres has this feature to stop the optimizer from looking for a solution once
it has spent more time than it would take to execute the best solution found
sofar. Something like: "I just spent 10 seconds computing a solution. The best
I found so far needs 9 seconds. I stop here. I could go on looking for a better
solution, but what is the point?"

I demonstrated this using a query over a complex view, that joins two views,
each one itself joining two or three tables (actually the CURRENT_INFO view, as
on the rdb personnel database).

Using the default option (which is to let the optimizer time out), I got some
reaults.

Forcing the optimizer not to time-out, i.e. forcing it to look for the best
solution, irrespective of the time spent to get at it, the optimizer spent
over TWO minutes doing its calculations (and did not come up with a better
solution).

I have never seen a behaviour like that on rdb. 

/albert