C-StoreHowDifferentareColumn-StoresandRow-Stores.pptVIP

C-Store: How Different are Column-Stores and Row-Stores? Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY May. 8, 2009 Row and Column Stores Limitation of Current Comparison Assuming a row store does not use any column-oriented physical design. Columns of the same logical tuple is traditionally stored together. In fact it is possible to simulate a column store in a row store. Simulating a Column Store in a Row Store Vertical Partitioning Indexing Every Column Materialized views C-Tables Vertical Partitioning + Run-Length Encoding Simulation 1: Vertical Partitioning Each column makes its own table N columns result in N tables, each table stores tuple-id, attr pairs. Need to do tuple reconstruction In C-store, columns are sorted in the same order. In MonetDB, base columns are kept in insertion order, updates only happen to cracker columns. In this “simulation” scenario, an integer “tuple-id” column is associated to each column. Use hash join on “tuple-id” column to reconstruct tuples. Two Problems of Vertical Partitioning It requires the “tuple-id” column to be explicitly stored in each column. Waste space and disk bandwidth. Most row-stores store a relatively large header on every tuple further waste space. Tuple Header A tuple header provides metadata about the tuple. For example, in Postgres, each tuple contains a 27 bytes header including information such as Insert transaction timestamp. Number of attributes in the tuple. NULL flags Length of tuple header Tuple Header in a Column Store A column-store puts tuple header in separate columns Some information in the tuple header can be removed For example, in MonetDB, each logical column stores key, attr pairs. Hence, the number of attributes is always 2. And there is no need for NULL flags, say we simply don’t store the tuple with NULL value. Simulation 2: Indexing Every Column Base relations are stored using a standard, row-oriented physical design. And an additional secondary B-Tree is built