Conference ulysse::rdb_vms_competition

    Hi, I'm currently locking horns with the UK arm of Teradata and may be
    able to help a little.
    
    The DBC gets it's speed from being able to decompose complex 
    queries into n smaller ones which are executed in parallel, the results
    of each sub-query are then merged and presented to the user. When
    it comes to scanning large volumes of data then we just can't touch it.
    However, it cannot decompose individual record requests or simple
    updates and in these areas it's performance should be no better than
    the VAX. The DBC has a very few tuning knobs, no hashing, no record
    clustering etc and so Rdb should out-perform it in these areas.
    
    I should say at this point that I have no hard evidence of this, its
    all personal supposition. 
    
    Other arguments you might use are :
    
      a. Cost, its not cheap, upgrades are expensive. Rdb is bundled ...
         etc.
    
      b. The machine is just a database server and will support no other
         functionallity
    
     As for your other points
        - I got no real feel for the size of the box, but the memory size
          looks a little small
	- SQL will be passed from the IBM to the DBC and data and errors
          will be returned, so, its should'nt place muchof a load on
          whatever the front end happens to be.
        - Teradata have a 'fastload' facility for doing bulk data loads, it
          is fast. However if Rdb has enough disks, is tuned properly and
          has a powerful CPU behind it and  we may be able to compete.
        - I believe the statements no before and no after journalling mean
          precisely what they suggest. I have a DBC reference manual on
          my desk and journaling seems to be done at the table level.
    
         I hope that helps.

Thanks for the reply, it definitely helps me understand better. 

It also makes me have another question, if you don't mind.  Basically, the
Teradata folks have defined indexes for the tables.  In designing the Rdb
solution I am limited to the same indexes.  However, since Rdb uses both 
hashed and sorted indices, I wasn't sure which to use, so I asked the customer.
He came back and said he called Teradata and they said that the indices they
used were "hashed".

But you said that they don't support hashing.  Now this is a very unsophisticated
client so they might have gotten the message garbled....  Do you know how their
indices work?  Should I challenge them on this point (i.e., the claim that they
are hashed)?

Thanks again for any insight you can provide.

P.S.:  Anybody know of any relationship managers within Digital for Teradata?

Rusty.

     I've just re-read the section on the Teradata manual describing
     supported index types.
    
     There are two types of index, primary and secondary, these may be 
     unique or non-unique, this is under DBA control.
       The primary index, every table must have one defined, uses a hashing
     algorithm to determine where rows are stored on the AMPS of a DBC 
     system.
       Each optional secondary index is created as a sub-table, and thus 
     consumes disk space. Each row of a secondary index sub-table contains
     the index value and one or more row-ids ( the DBKEY ). The manual 
     'suggests' that either a hashing algorithim or bit map are used to 
     locate key values in the sub-tables, It does not go into any great
     detail. This structure could be a simple b-tree, the manual does not 
     go into any great detail.
     
     However, the DBA has no control over record placement and there is 
     definitely no co-incidental record clustering or variable page size
     optons etc. It doesn't seem to need these features.
    
     I don't understand how it handles primary key range retrievals or 
     part-primary key retrievals, maybe thats a question you could put
     to them.
    
     Apologies for my earlier mis-leading comments. On your last point, it
     would probably be worth contacting your national product manager and
     asking him who manages Digital/Teradata relationships. Don't raise
     your hopes to high though.
    
     As an aside they have a VAX based cobol pre-compiler for VMS + MVS.
     Also Ingres have recently announced a Gateway to the DBC and
     I know Oracle are working on one, however, with their new whiz
     bang parallel server maybe they just dont need this anymore. 
     I digress.
    
     Hopes this helps, feel free to give me a call if wish.
         
    
       
    
     
      

    Re .0,.2
    It sounds like you're benchmarking a workload against Teradata,
    to help the customer decide whether to buy a VAX or a Teradata system,
    and you're letting Teradata define how tim implement the benchmark
    on VAX.  This sounds like a recipe for failure.
    
    The customer's benchmark specification should define what operations
    need to be supported.  It's then *your* job to design an Rdb database
    to support those operations.  The customer shouldn't care what kind
    of indexes you use, as long as the specified operations work.  And
    the *competitor* certainly shouldn't be allowed to dictate your
    design!

Re: .3  Thanks for the explanation!  Makes a lot more sense.

Re: .4  You are correct on all points.  Except it's even worse than you
speculated.  Teradata held a 2-day "logical data modelling" workshop and
then ran the benchmark and got the results.  Then we (TPRC) got a call from
the sales rep who has been working this account (currently 100% IBM shop).
We are being forced to use Teradata's logical data model and the benchmark
is purely single user (end user computing group), so we can't really take
advantage of SMP or VAXclusters to improve price/performance.  So, what stupid
#@$#@ idiot would ever get involved in such a foolhardy assignment?  (Did I
mention that there *isn't* a benchmark specification?).

On the flip side, the sales rep has been working this account exclusively for
several months and has developed excellent working relationships with upper
level mgmt. (CFO level).  Folks above the end-user computing person who is
running this show have indicated (heresay) that there is no way they want to
get a Teradata, and are committed to becoming a 2-vendor shop.  They are in
the process of purchasing a VAX 4000 for another application and are very
interested in ALL_in_1  (did I do that right?).  As the person running the
benchmark said, there is a growing groundswell of support within the company
for Digital.

So, some VP somewhere within Digital has decided to pursue this one and, as
a good corporate citizen, despite my misgivings, I will give it my best shot.
To be honest, I think it might be the correct decision.  Sometimes these things
aren't cut-and-dry, and benchmark results can be overlooked/slanted by buyers
as appropriate to justify whichever decision they want to make.  I believe that
we can "loose" the benchmark and still get the order.....anybody got any wind-
mills that I can go after?

    The configuration we are proposing is essentially VAX/DBC, with cobol
    clients on the front end passing data rrequests to the DBC.
    
    One business requirement was to be able to process n000 records in a
    specified period of time. I asked the teradata consultant what he
    thought would be the best way to do this. His response was NOT to use
    the ingres gateway or  their pre-compiler but to use a combination 
    of DBC utilities ( BTEQ,FASTLOAD) from a SINGLE cobol client i.e. do it
    single user , the single user session being decomposed on the DBC to
    make use of its parallel architecture.
    
    The point is : this is essentially a single user job making full use of
    the parallellism of the DBC. I asked how he thought 20 Cobol clients on
    the front end doing classic batch processing, each handling their own
    range of records in order to achieve the same throughput would compare, 
    the answer, about the same ! There is a moral to this story.
    
    About those indexes, as you'd expact if you try to do partial key or
    range retrievals on a dbc primary index it's going to do a sequential
    scan. You would need to define a secondary index on top of it to avoid
    this happening.
        

    Wait a minute -- These guys are trying to offload the IBM system,
    right?
    
    If they use a Teradata box, then the SAS and FOCUS applications still 
    need to run on the IBM machine, only the database workload is shifted
    to the Teradata.  If they move to a VAX, then the SAS and FOCUS
    applications will also run on the VAX, thus more effectively offloading 
    the IBM machine.
    
    Meanwhile, I think you should reiterate that the Teradata "Logical"
    design includes a number of physical database definitions, and these
    physical definitions may not be the best possible design for Rdb/VMS.

    Re .5
    If the sales rep has an excellent relationship with the customer's
    upper management, you should be able to present two versions of
    the benchmark: one run the way the end-user person is asking you
    to, and one run the best way you know how.  Let upper management
    help decide whether the criteria were reasonable, and which benchmark
    result to weight more heavily.

    You are correct.  We have been given the option of "doing the benchmark
    twice"....once with the logical design of Teradata, once with our
    logical design--just as you suggest.  Unfortunately, that doubles the
    work and increases the time (60 million rows on 35 tables need to be
    loaded).  Now we have to determine if the juice is worth the squeeze.
    
    But, we are definitely going to be "de-emphasizing" the benchmark
    portion (we can't win the business on performance) and focusing on
    other aspects of our products (interoperability, NAS, decision support
    tools, design tools, large skill base, etc.)....
    
    Thanks for the comments, these help me concretize my thoughts as we
    proceed with our development.  Rusty.