Conference ulysse::rdb_vms_competition

1159.0. "DECmpp Support for Rdb/VMS? - Posted for review" by ACESMK::RLEE () Wed Jun 03 1992 00:40

    The following information is posted to solicit some replies to the
    following database technology proposal.
    
    The idea is to support Rdb/VMS with a DECmpp DECstation 12000 series
    U*X machine acting as an active parallel processor Rdb dbkey cache for
    an application that will take fuzzy terminal operator input to find an
    exact phone number or list of phone numbers - and meet a sub-second
    user response time requirement.
    
    Looking forward to your constructive advice!
    
        -bob lee-
       "TP megalomaniac"





       Client Objective:
       ----------------

       Replace existing Operator Assistance application supporting 1000
       concurrent users which provides sub-second phone number retrievals using
       database entry key consisting of mixed Katakana, Hiragana, and Kanji
       characters into a minimum-sized 100 Gigabyte database. 

       There currently exists approximately 1.6 million unique keys in the
       existing database.

       The system must support high availability in earthquake prone regions.



	                                                            (continued)






       Challenge:  Supporting 1000-concurrent users:
       ---------

       Possible Solutions?

       1. Provide 10 VAX-based processors running VAX ACMS with each node
          supporting 100-concurrent users with 100 single-threaded VAX ACMS
          server processes.  Support Rdb/VMS database with over 130 Gigabytes of
          RAID-5 supported storage using SF35/SF220 disk arrys.

          Issue:  System performance.

       2. Provide 10 VAX-based processors running VAX ACMS each supporting
          100-concurrent users with 10 DECmpp's providing Rdb/VMS "dbkey"
          array-processor cached lookup.  Support Rdb/VMS database with over
          100 Gigabytes of RAID-5 supported storage using SF35/SF220's.

          Issue:  Multiple operating systems support.  Cost.


       Challenge:  Pattern matching user-entered keys:
       ---------

       The problem with Japanese data entry is that operators can enter data in
       either of two phonetic language representations:  Katakana or Hiragana.

       With rule-based language support, the entered key must be matched to an
       appropriate final representation which can consist of mixed Kanji - an
       iconic language with multiple semantic and phonetic mappings 
       - and both Katakana and Hiragana.

       Possible solutions?

       1.  Existing data entry utility developed for Japanese Digital Standard
           MUMPS.

       2.  DECmpp application using Third Eye's Elexir software.


	                                                            (continued)



       Challenge:  Access to 100 Gigabyte database:
       ---------

       Fact:  The database is very stable - but will require periodic background
              updates.  

       Following is a list of questions that the sales team should try to
       ask the client:

       Q:  How many updates and what is the scheduled frequency of update runs?

       Q:  Can the database be partitioned using phone number area and  central
           office codes?

       Q:  Can the database keys be partitioned by geographic address  and
           subscriber name information?

       Possible solutions:

       1.  Use Rdb/VMS in conjunction with VAX ACMS server programs.

           Possible issues:

         * VAX ACMS server programs are single-threaded.  To support 1000
           concurrent users - there would need to be 1000 processes bound to the
           database.  With 10 VAX nodes, that would be 100 server processes per
           node.

         * Standard exact database key lookup requires use of the Rdb/VMS hash
           algorithm - which recommends a physical database sizing that must
           allow for at least 30% more disk space than required to minimize hash
           key collisions, and reduce page search length when hash key
           collisions occur.

           If disk space budget does not allow for 30 Gigabytes of free space in
           the database, then hash algorithm efficiency will be affected
           negatively.  Sorted indexes could be used for search - but the key
           space is large. Worst case key searches would require too much CPU
           time and would violate constraint of sub-second user response time.

         * For a server process to map a 100 Gigabyte database, each process
           will require sufficient virtual memory to perform Rdb/VMS page I/O.
           Even with Rdb/VMS V4.1 global buffering, support for such ACMS server
           processes could require more VMS resources than available.

           It might be possible to "partition" database servers so that  servers
           are assigned to map a specific database "partition". This could be
           used to help reduce per process virtual memory requirements.

	                                                            (continued)



       2.  Use Rdb/VMS in conjunction with VAX ACMS server programs, ACA
           Services, and DECmpp architecture.

         * This solution assumes that actual Rdb/VMS database keys - "dbkeys"
           which consist of alphanumeric sequences of:

          <logical_area_number>:<page_number_in_area>:<record_number_on_page>

           can be pre-loaded with the application specific Japanese-based
	   database key to DECmpp processors for exact matching.

           Using ACA Services client API, a VAX ACMS server process could 
           supply an application specific database key to a DECmpp ACA server
           API process which could submit a parallel exact match query to a 
           maximum of 16,384 array processing elements to retrieve the actual
           Rdb/VMS "dbkey" for the ACMS Server Process.

           In the worst case, a scan of the database key space of 1.6 million
           keys, a single DECmpp would have to perform 100 full processing
           element loads.  10 DECmpp's would have to perform 10 full processing
           element loads. 

           ACMS Server Process could then use "direct" Rdb/VMS access via 
           DECmpp-supplied Rdb/VMS "dbkeys" to actual database records using
           standard Rdb/VMS interfaces.

           Since the ACA Server process can be coded to support multi-threaded
           processing in the ULTRIX environment - if each DECmpp ACA server
           process is designed to support 100 threads and each server mapped the
           entire database, then 10 distinct DECmpp ACA server processes are
           required to support 1000-concurrent users, on each DECmpp.

           In short:  Use the DECmpp architecture to provide parallel processing
           record locating service for an Rdb/VMS database.  Avoid Rdb/VMS
           search algorithms since they will either be VAX-compute or  I/O
           intensive - which could violate the sub-second user response time
           constraint.

           Advantages:  

           1. If Rdb/VMS is used to store actual database records, then database
              development and maintenance can be "standardized" and could easily
              be supported by client's MIS department.
           2. ACA Services provides an object-oriented open interface that can
              support simple "high-availability" search for server processes by
              following a logical name search list. It interoperates across
              VMS- and ULTRIX-based systems.

           Possible issues:  

           1.  DECmpp's DECstation 5000/2xx performance.
           2.  VAX ACMS & Rdb/VMS performance.
	   3.  LAN performance.
           4.  Supporting mixed operating system software environment.
           5.  Finding programming staff for DECmpp software development.