[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:DEC Rdb against the World
Moderator:HERON::GODFRIND
Created:Fri Jun 12 1987
Last Modified:Thu Feb 23 1995
Last Successful Update:Fri Jun 06 1997
Number of topics:1348
Total number of notes:5438

281.0. "Record Clustering?" by CSTEAM::WADSWORTH (KIRBY WADSWORTH) Fri Dec 16 1988 23:40

    Tandem recently did some DEC-bashing at a propect account.
    
    They beat up Rdb badly saying something about the way we use record
    clustering was dangerous.
    
    Later, after we beat them at a Benchmark they reported decided to
    incoporate it into NonStopSQL. 
    
    What exactly are they talking about?
    
    Also, I was under the impression that NS-SQL implemented two phase
    commit, now I here that TRUE TPC will be released next summer.
    
    What gives?
T.RTitleUserPersonal
Name
DateLines
281.1More info required. There are two types of distributed database.DEBIT::DREYFUSMon Dec 19 1988 15:1152
>    They beat up Rdb badly saying something about the way we use record
>    clustering was dangerous.
 
Any more details?  The only issue that I have heard raised is that it is
not explicit and that it has restrictions.  The argument goes that
there should be syntax to cluster records and not a reliance upon
'coincedence' by using common indexes and mixed page formats in a database
area.  The restriction argument is really a request for improvement.  It
would be more powerful to cluster records without requiring them to share
a common primary key.
 
Changing an index or not setting up the storage area correctly could
lead to a non or poor use of clustering.  This could have serious
performance implications.  A little experience and use of RMU/Analyze
can solve this problem.
  
>    Later, after we beat them at a Benchmark they reported decided to
>    incoporate it into NonStopSQL. 

Clearly, we have a good implementation.
    
>    What exactly are they talking about?
    
We need more information from Tandem.

>    Also, I was under the impression that NS-SQL implemented two phase
>    commit, now I here that TRUE TPC will be released next summer.
 
One possibility is that the current Tandem approach is to
support homogeneous, integrated (I am sure these aren't the correct words)
distributed databases.  With this model they can distribute the database
over a Tandem cluster where the database is explicitly aware of the different
nodes in the cluster.  If one node dies, part of the database is not
accessible.  You can not treat part of the distributed
database as a separate database.  Because the distributed database is
one physical database, 2 PC is not required.

Compare this model to the federated distributed database.  In this model,
a logical, distributed database comprises multiple physical databases.
Each physical database has its own security schema and can be accessed
autonomously.  That is, each physical database is an autonomous, separate
database.

In order to coordinate an update across multiple physical databases you
need 2 PC.

Another way of looking at this is:  How many log files does Tandem currently
require for a 16-node distributed database? 

A federated distributed database will require one (two if mirrored) for each
physical database and one for the distributed transaction manager (the
distributed database). 
281.2Clear as EggnogCSTEAM::WADSWORTHKIRBY WADSWORTHThu Dec 22 1988 15:2911
    Whew!
    
    Thanks Dave.  That clears up the 2PC question, Tandem's audit trails
    are not distributed geographically so the database is indeed a single
    homogeneous structure.  
    
    I wasn't present when Tandem did its RDB bashing so I can't clarify
    exactly what it is they were criticizing.  I'll try to get more
    detail from those involved.
    
    kw