Browse Prior Art Database

Method and Mechanism for column-store table with a shadow row-store table in mixture workload RDBMS for performance improvement

IP.com Disclosure Number: IPCOM000236767D
Publication Date: 2014-May-15
Document File: 4 page(s) / 184K

Publishing Venue

The IP.com Prior Art Database

Abstract

A shadow table in row-store is defined on a column-store table to improve the performance for the join between this column-store table with other row-store tables. The shadow row-store table is maintained by database automatically to ensure data consistency with the parent column-store table, meanwhile the join between the parent column-store table with row-store tables is routed to the shadow row-store table.

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

Page 01 of 4

Method and Mechanism for column

Method and Mechanism for column-

--store table with a shadow row

store table with a shadow row

store table with a shadow row-

--store table in mixture workload RDBMS for

store table in mixture workload RDBMS for

store table in mixture workload RDBMS for

performance improvement

RDBMS rolled out since the late of 1970 with over 30 years history, the traditional way for data layout in RDBMS is of putting the values row by row in storage by pages (blocks). These years with data volume growth and storage cost reduced, business intelligence is a new landscape for information technology. This also means a new challenge for warehouse (OLAP area for RDBMS). Since 2000, the new data layout on column-oriented appeared and has several commercial products. Column-store has several nature characteristics including reducing I/O significantly and high compression ratio, which have great advantages for OLAP.

Most column-store RDBMS products are developed from a traditional row-store RDBMS, so support the data can be stored in column organized or row organized by tables or by table partitions. Meanwhile most of the servers are supporting the query can touch the tables in row-store and the tables in column-store together, like a JOIN between a row-store table and a column-store table. This gives more flexibility for users especially for mixture workload, in which a server takes OLTP and OLAP tasks together and put OLTP data in row-organized tables and OLAP data in column-organized tables. However if the join between two different data-organization, one must be converted to another kind to complete the job. For most RDBMS supporting both column-store and row-store, if a join between a row-store table and a column-store table, this column-store table will be converted into row organized in runtime in general, then join with row-store table with the traditional row table join method. For the way, the performance is worse than the join between two column-store tables, even worse than two row-store tables as the extra conversion as shown in below figure. However the mixture storage architecture provides more fl...