Posts Tagged ‘Tandem

Mixing Batch and OLTP Queries

Tandem and Teradata have demonstrated that the same architecture can be used successfully to process transaction-processing workloads as well as ad-hoc queries. Running a mix of both types of queries concurrently, however, presents a number of unresolved problems. The problem is that ad-hoc relational queries tend to acquire a large number of locks (at least from a logical viewpoint) and tend to hold them for a relatively long period of time, (at least from the viewpoint of a competing debit-credit style query). The solution currently offered is “Browse mode” locking for ad-hoc queries that do not update the database. While such a “dirty_read” solution is acceptable for some applications, it is not universally acceptable. The solution advocated by XPRS, is to use a versioning mechanism to enable readers to read a consistent version of the database without setting any locks.While this approach is intuitively appealing, the associated performance implications need further exploration. Other, perhaps better, solutions for this problem may also exist.

A related issue is priority scheduling in a shared-nothing architecture. Even in centralized systems, batch jobs have a tendency to monopolize the processor, flood the memory cache, and make large demands on the I/O subsystem. It is up to the underlying operating system to quantizeand limit the resources used by such batch jobs in order to insure short response times and low variance in response times for short transactions. A particularly difficult problem, is the priority inversion problem, in which a low-priority client makes a request to a high priority server. The server must run at high priority because it is managing critical resources. Given this, the work ofthe low priority client is effectively promoted to high priority when the low priority request is serviced by the high-priority server. There have been several ad-hoc attempts at solving this problem, but considerably more work is needed.

Tags : , , , , , , , , , ,

Tandem NonStop SQL

The Tandem NonStop SQL system is composed of processor clusters interconnected via 4-plexed fiber optic rings. The systems are typically configured at a disk per MIPS, so each ten MIPS, processor has about ten disks. Disks are typically duplexed and managed in the standard way [BITT88]. Each disk pair has a set of processes managing a large RAM cache, a set of  locks,and log records for the data on that disk pair. Considerable effort is spent on optimizing sequential scans by prefetching large units, and by filtering and manipulating the tuples with sql predicates at these disk servers.

Relations are range partitioned across multiple disk pairs [TAND87] which is the only strategy provided. The partitioning attribute is also used as the primary, clustering attribute on each node, making it impossible to decluster a relation by partitioning on one attribute and then constructing a clustered index at each node on a different attribute. Parallelization of operators in a query plan is achieved by inserting a parallel operator (which is similar to Volcano’s exchange operator [GRAE90]) between operator nodes in the query tree and joins are executed using nested or son-merge algorithms. Scans, aggregates, updates, and deletes are parallelized. In addition several utilities use parallelism (e.g. load, reorg, …). A hash join algorithm which uses hash declustering of intermediate and final results has recently been implemented [ZELL90]. [ENGL89] contains a performance evaluation of the speedup and scaleup characteristics of the parallel version of the Non-Stop SQL system.

The system is primary designed for transaction processing. The main parallelism feature for OLTP is parallel index update. Relational tables typically have five indices on them, although it is not uncommon to see ten indices on a table. These indices speed reads, but slow down inserts, updates, and deletes. By doing the index maintenance in parallel, index maintenance time can be held constant if the indices are spread among many processors and disks. In addition, the NonStop SQL is fault tolerant and suppons geographically distributed data and execution.

Tags : , , , , , , , , , , , , , , , , , , , , , , ,