NonStop SQL Research Articles

Parallelism and its price

We describe the use of parallel execution techniques and measure the price of parallel execution in NonStop SQL/MP, a commercial parallel database system from Tandem Computers. Non-Stop SQL uses intra-operator parallelism to parallelize joins, groupings and scans. Parallel execution consists of starting up several processes and communicating data between them. Our measurements show (a) Startup costs are negligible when processes are reused rather than created afresh (b) Communication costs are significant — they may exceed the costs of operators such as scan, grouping or join. We also show two counter-examples to the common intuition that parallel execution reduces response time at the expense of increased work — parallel execution may reduce work or may increase response time depending on communication costs.

Distribution, parallelism, and availability in nonstop SQL

Distribution, parallelism, and availability in nonstop SQL

A benchmark of NonStop SQL release 2 demonstrating near-linear speedup and scaleup on large databases

A benchmark of NonStop SQL release 2 demonstrating near-linear speedup and scaleup on large databases

A benchmark of NonStop SQL on the debit credit transaction

NonStop SQL is an implementation of ANSI SQL on Tandem Computer Systems Debit Credit is a widely used industry-standard transaction. This paper summarizes a benchmark of NonStop SQL which demonstrated linear growth of throughout from 14 to 208 Debit Credit transactions per second as the hardware grew from 2 to 32 processors. The benchmark also compared the performance of NonStop SQL to the performance of a record-at a time file system interface

High performance SQL through low-level system integration

NonStop SQL [TM] achieves high performance through an implementation which integrates SQL record access with the pre-existing disk I/O and transaction management subsystems, and moves SQL function downward from the client to the server level of these subsystems. System integration and movement of function to the server reduce message traffic and CPU consumption by putting SQL optimizations at the lower levels of the system. Examples of such optimizations are message traffic savings by filtering data and applying updates at the data source, I/O savings by SQL-optimized buffer pool management, and locking and transaction journaling techniques which take advantage of SQL semantics. Achieving message traffic reduction is particularly important in a distributed, non shared-memory architecture such as the Tandem NonStop System. The result of this implementation is an SQL system which matches the performance of the pre-existing DBMS, while inheriting such pre-existing architecturally-derived features as high availability, transaction-based data integrity, and distribution of both data and execution.