Browse Prior Art Database

Efficiently Handling Table Storage By Enabling Parallel Inserters And Improving Performance Of Scan And Rollback

IP.com Disclosure Number: IPCOM000235038D
Publication Date: 2014-Feb-25
Document File: 3 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method and system is disclosed for efficiently handling design problems related to appending data at end of the table by enabling parallel inserters and improving performance of scan and rollback. The method and system disclosed herein uses separate tuple storage for each inserter and utilizes a map structure to control visibility of tuple storage for improving scan performance.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 3

Efficiently Handling Table Storage By Enabling Parallel Inserters And Improving Performance Of Scan And Rollback

Relational database management systems (RDBMS) must provide a way to append data at the end of a table. To do this, RDBMS have to coordinate access to one or more tails. With many inserters at a given time, synchronization is required to control access to insert contexts. Also, a shared tail may be written by several transactions. Some inserting transactions may have committed while other inserters may be still in progress. As a consequence, read transactions must have a method of filtering uncommitted (or committed but not visible) tuples from the tail. Further, upon rollback of a failed transaction, rows inserted by the failed transaction must be annotated in some way so that these rows can be filtered by future transactions.

In IBM* Netezza** system, all inserters into a table share an insert context and a single piece of tail storage; i.e. a 128KB page and insert context. Access to the tail page is

controlled by a mutex for serializing inserters. Pages written by an inserting transaction that subsequently rolls back must be re-written with a rollback annotation. Overall, this can be an expensive operation in terms of I/Os.

In IBM DB2*** systems with BLU acceleration, there can be many tail contexts allowing many (up to a certain K) inserters to operate in parallel. Since BLU is columnar, the tail context is a set of pages each containing data for one column. Moreover, access to the tail is blocked to the K+1 inserter. Further, BLU has a mechanism to allow scanners to skip recently inserted pages containing no data visible to the transaction. Upon rollback, BLU visits each written page and removes the inserted rows.

A method and system disclosed herein combines two mechanisms to efficiently append data at end of a table. Firstly, the disclosed method and system uses separate tuple storage for each inserter. By using separate storage for each inserter, no synchronization is required for the tail storage. Thus, unfettered parallelism of inserters is allowed. Secondly, a map structure is utilized to control visibility of tuple storage. Since the map structure controls views of storage related to all transactions, storage for new tuples is not made visible until the transaction commits. Thus, the disclosed method and system improves scan performance because scanners never process storage that contains uncommitted data.

In an exemplary embodiment, each inserting transaction allocates tail storage for its new tuples. The new tuples may come from loads and insert statements. New tuples may also come from update statements in a multi-version implementation where an update is decomposed into a delete operation and an insert operation. Since only a single transaction is written to the storage, no synchronization between transactions is needed and an arbitrary number of inserters can proceed in parallel.

Subsequently, the disc...