Abstract * Foil Index for this file
Given by Gang Cheng Marek Podgorny (Geoffrey Fox) at CPS600 Spring Semester on April 1995. Foils prepared July 6,1995
Abstract * Foil Index for this file
| This discusses the last three parts of presentation |
| What is situation at NPAC including hardware, InfoMall activities and the DR-LINK product of Textwise (Liz Liddy) |
| Detailed Discussion of Parallel Oracle on SP2 and nCUBE |
Results of NPAC's Benchmarking Activities
|
This table of Contents
Abstract
Full HTML Index
| Gang Cheng |
| Marek Podgorny |
| (and a bit of Geoffrey Fox) |
| gcheng@npac.syr.edu,marek@npac.syr.edu |
| NPAC |
| 111 College Place |
| Syracuse |
| New York 13244-4100 |
Full HTML Index
| This discusses the last three parts of presentation |
| What is situation at NPAC including hardware, InfoMall activities and the DR-LINK product of Textwise (Liz Liddy) |
| Detailed Discussion of Parallel Oracle on SP2 and nCUBE |
Results of NPAC's Benchmarking Activities
|
Full HTML Index
Full HTML Index
| Beta test sites with Oracle, nCUBE and IBM for their parallel RDBMS products |
| Direct contacts with PRDBMS developers at Oracle and IBM |
| Hands-on Expertise in large-scale (up to 100 GB DB size) DSS benchmarking |
| Experience in parallel computing and applications in industry, parallel system integration and data visualization |
Full HTML Index
nCUBE 2
|
Full HTML Index
IBM SP2
|
Upcoming upgrade:
|
Full HTML Index
| Planning, design, implementation, and interpretation of Decision Support benchmarks using parallel database technology |
| InfoMall product, supported by technology vendors |
| Standard and customer defined benchmarks |
| NPAC provides state-of-the-art infrastructure, MPP and parallel database expertise, and trained personnel |
| InfoMall assumes most of the risks and hazards involved in the benchmarking process |
| Non-disclosure arrangements available |
Full HTML Index
InfoMall project
|
Full HTML Index
| This research activity of Professor E. Liddy of Information Studies School at Syracuse University is being commercialized by InfoMall member -- the start-up company Textwise. |
The Surface Realizations i.e. particular strings of words in documents or database quert, do not reflect the breadth, richness or precision of meaning intended by either
|
Simple word level representation cannot produce the recall and prescision possible when the full conceptual intent of queries and documents is the basis of retrieval
|
DR-LINK achieves this deeper conceptual representation of texts by utilizing all the levels of language at which meaning is conveyed:
|
Full HTML Index
| Accepts lengthy ambiguous complex Natural Language Queries |
| Translates Natural Language queries into precise Boolean representations of the user's implied requirements for relevance of a document to query |
| Produces summary-level semantic SFC (Subject Field Codes) vector representations of query and documents for quick filtering of large databases |
| Catures Text Structure dimensions of time, source, state of completion, credibility, definiteness, intentionality and causality |
Fulfills Proper Noun requirements of queries by:
|
| Provides both high recall and high precision via controlled expansion of Complex Nominals |
| Evaluates Implicit and Explicit Semantics to assign similiarity between Query and Documents using its Integrated Matcher |
| Predicts how many documents need to be viewed to acieve the user-specified level of recall via the Cut-Off Criterion |
Full HTML Index
| Raw |
| Documents |
Full HTML Index
Full HTML Index
| A high-performance RDBMS for loosely coupled and MPP systems |
| Currently supported systems: IBM SP2, nCUBE2, SGI SMP, SUN SMP, HP SMP, Amdahl, Encore, KSR, CM5, |
| Also known as multi-instance Oracle: Multiple instances running against a single, shared database |
| A evolutionary approach on existing sequential Oracle RDBMS |
Full HTML Index
Two independent options
|
| Parallel Server option available for most Unix platforms |
| Parallel Data Query available for few SMPs |
| combination of PS and PDQ mostly in beta, available for a handful of SMP clusters and MPP machines |
Full HTML Index
| parallelizes execution of a single SQL query |
| parallel execution carried out by concurrent Unix processes communicating via shared memory |
| single Oracle instance sufficient - no PS necessary |
| uses multiple CPUs on SMP architectures but can run on single CPU machines as well with modest performance benefits |
| essential for Decision Support |
| irrelevant for OLTP |
Full HTML Index
| lets multiple Oracle instances access the same database |
| requires a cluster of single CPU workstations, a cluster of SMPs, or an MPP to run |
| requires a Distributed Lock Manager to ensure data consistency |
| requires all disk storage accessible by each Oracle node |
| supports PDQ distributed across multiple instances |
| essential for OLTP and Òapplication partitioningÓ |
| relevant for scalability of ad hoc DS queries |
Full HTML Index
| First introduced with Oracle 6.2 |
| version 6.2 = version 6.0 (sequential) + Parallel Cache Management |
| version 7.1 = version 6.2 + parallel query processing |
| newest version 7.1.3 = sequential Oracle + Parallel Server Option + Parallel Query Option |
| production release on nCUBE is in Jan. 1995 |
| All parallel implementation is transparent to users |
| Key technology: Parallel Cache Management and Parallel Query Processing |
| Key components: a Distributed Lock Manager and a Parallel Query Optimizer |
Full HTML Index
Oracle 7 Server Architecture
|
Oracle 7 Database Files:
|
Full HTML Index
Full HTML Index
| Every time the Oracle 7 Server is started, the System Global Area (SGA) is allocated and the Oracle 7 Server background processes are started. The combination of memory buffers and background processes is called an Oracle Server Instance. |
| The SGA is a group of shared memory buffers allocated by the Oracle 7 Server for an instance |
| The background processes asynchronously perform distinct tasks on behalf of all database users of the instance |
Full HTML Index
| Start an Oracle Server instance on each node |
| Each instance has its own set of redo log files |
| All instances can concurrently execute transactions against the same database and each instance can have multiple users executing transactions |
Full HTML Index
| Each node of a parallel system runs an instance of the Oracle7 Server that accesses a shared database |
Full HTML Index
Full HTML Index
| Multiple Instances on different nodes share a single physical database |
| The data is accessed by all nodes through a parallel file subsystem |
| All instances have common data & controls files and their individual log files |
| All instances can simultaneously execute transactions against the single database, and each instance can have multiple users executing transactions |
| Data is kept consistent using PCM Technology |
| Implemented by the Distributed Lock Manager |
Full HTML Index
Oracle Components
|
IBM Components
|
Full HTML Index
| Concurrency control of buffer caches among instances |
| Maintain independent, yet consistent cache of blocks for all instances |
| Allow multiple nodes to simultaneous read/write to database (disks) |
| Maximizes concurrent data access and minimizes (disk) I/O activity |
| Block-level PCM locks, row-level locking preserved |
| A fault-tolerant DLM: if a node goes down, the DLMs will automatically recover and reconstruct the lock database on behalf of the failed DLM |
Full HTML Index
| Three possible failures |
Full HTML Index
Time Steps:
|
| In this situation, Node 1 and 3 have the same information in each memory cache, but Node 2 has an inconsistent cache. |
Full HTML Index
| The example of previous and following foil, illustrates why concurrency control is needed in a parallel DB server environment. |
| It shows how contention for shared resources(data,disk access) is being handled under a multi-node parallel system sharing a single database. |
| The blackened boxes in the figure are the same blocks in each node (not rows !) requested by different nodes(instances) and located in different SGA bufferes. |
| Concurrency control needs to be implemented to ensure a consistant database, |
| i.e. the same block from the disk must be reflected as exactly the same copy in different buffers. |
| This is achieved by PCM locks. |
Full HTML Index
| 3 Oracle Instances Accessing Shared database |
Full HTML Index
| An instance acquires a PCM lock as a resource for update purposes |
| All buffer caches must contain the same copy of a resource |
PCM blocks:
|
Full HTML Index
Time
|
| The PCM is handled separately from transaction lock -- when instance wish to update the same data (e.g.: Instance X and Y attempt to update Row 1), normal transaction locking is involved. |
Full HTML Index
Parallel Query Processing
|
Parallel Data Load
|
Parallel Index Creation
|
Parallel Recovery
|
Full HTML Index
Typical Data Flow with 5 steps:
|
Full HTML Index
Full HTML Index
| 1 Parse --- a query optimizer determines optimal execution plan, parallelize query if a full scan was included in the execution plan (note the query is parallelized dynamically at execution time, automatically adapting changes in data partition and server configuration) |
| 2 Execute --- perform operations |
| 3 Fetch (Queries) --- return rows from query server processes |
| The execution and fetch phases can be performed in parallel ( pipelined parallelism) by multiple server processes |
Full HTML Index
| The shared query server is known as Query Coordinator who is responsible for parallelizing operations and interpreting the results from query servers |
| Not all operators can be parallelized in Oracle 7.1.3 |
Oracle Server Parallizable Operations
|
| See following two figures |
Full HTML Index
| Full Table Scan without Parallel Query Option |
| Multiple Query Servers Performing a Full Table Scan |
Full HTML Index
Full HTML Index
Oracle 7 on nCUBE2 and IBM SP2 are actually implemented as shared-disk (vs. shared-nothing) architecture
|
Shared database by sharing disks through parallel file system or parallel I/O system:
|
Full HTML Index
Automatic file striping and disk partitions by the operating system on nCUBE2
|
Manually file striping at database table level on IBM SP2
|
Full HTML Index
Full HTML Index
Transaction Processing Council
|
Wisconsin Benchmark (aka Dewitt)
|
Full HTML Index
Set Query
|
The Neal Nelson Database Benchmark (tm)
|
SPEC (Standard Performance Evaluation Corporation)
|
The Customer -- or worse >> The Consultant
|
Full HTML Index
| Few insert/update/delete transactions, read-only queries. |
| Non-selective & data-intensive; few in number, large in size |
| May return a large volume of data: e.g.: mailing list |
| Queries frequently scan a large percentage of the data in the database |
| Often used to mine data in a recursive, drill-down fashion |
Full HTML Index
A common suite for DSS benchmarking and comparing:
|
| Our TPCD benchmarking project has gone through most of the above examples |
Full HTML Index
| TPC-D definition requires that either one (power test) or many (scale-up test) query streams are run and timed against at least three sizes of a predefined database, with sizes growing exponentially (e.g., 1G, 10GB, 100GB sequence) |
| Query stream consists of 17 complex queries plus two concurrently running update operations |
| No extensive database tuning in allowed - optimizer hints are explicitly forbidden |
| timings for individual queries are not part of the TPC-D metric |
| Database structure well represents most common DSS DBs in applications, i.e. one largest table takes ~70% of the total DB size. |
Full HTML Index
| model complex queries against a relatively large and complex database |
All currently parallelizable relational operators (Oracle 7 Server) are used, including:
|
Full HTML Index
| Query stream design: Query 17 takes more than 95% of the time needed to execute the stream |
| Overal design unnecessarily mimics TPC OLTP benchmarks |
| Metrics more suitable for Data Warehouse applications than for ad hoc DS queries |
| Benchmark expensive to run (huge disk space requirements) |
Full HTML Index
Is TPC-D suitable for parallel DBMS evaluation?
|
| Scalability of a parallel database system relies on both CPU resources and I/O resources. |
| By using multiple instances (CPUs), parallel server/query decreases query response time and increases throughput. |
| By using partitioned data on multiple disks (with multiple I/O channels), parallel server/query achieves higher I/O bandwidth for large DBs. |
| The two characteristics are equally important and must be benchmarked together. In current TPC-D specification, neither performance metrics is defined. |
Full HTML Index
| For DS applications, query stream execution time is largely irrelevant. It is far more important to understand performance and scalability of elementary SQL operations and of typical queries encountered in customer application. |
| Loading and indexing may take a large portion of the overall time in preparing a large DB. Both parallel loading and indexing become important functionality of a parallel RDBMS. Their performance for large DSS databases should be defined and benchmarked, together with the query benchmarks. Currently none of them is defined or mentioned in the TPC-D specification. |
Full HTML Index
| TPC-D design contains flaws that make its use questionable even for sequential database systems |
| Given the complexity of the parallel database systems, attempts to reduce their performance estimate to one number are most likely futile |
| TPC-D defines no metrics useful for understanding behavior of parallel RDBMSes. TPC-D designers should re-examine academic research work pertinent to the field |
| Future research work towards definition of DS benchmark for parallel databases seems important |
Full HTML Index
| Data partitioning must be very carefully designed to balance I/O and CPU |
| Parallel Loading is great ! --- almost linear speedup |
| Backup may be important to save time (we don't have) |
| The most difficult and trouble-making phase is the database preparation/loading/indexing phase which always involves storage management parameters |
| you must be both a DBA and sysadm and benchmarking relies critically on system stability |
| Be prepared to bring down the whole parallel system a couple of times a day |
| Be prepared that the results are negative (nothing may be obtained !) |
| you need at least twice the disk space of your original database size |
| performance tuning is extremely difficult with Oracle 7 parallel server |