Column-Stores vs. Row-Stores How Different Are They Really?

Transcription

1 Column-Stores vs. Row-Stores How Different Are They Really? Volodymyr Piven Wilhelm-Schickard-Institut für Informatik Eberhard-Karls-Universität Tübingen 2. Januar 2 Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 / 8

2 To Buy or not To Buy Soll man sich wirklich Column-Stores kaufen? Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 2 / 8

3 To Buy or not To Buy Key Questions. Emulate of column-store in a row-store 2. Unmodified row-store vs. column-oriented design 3. Optimizations of column-stores 4. Invisible join vs. denormalized fact table Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 3 / 8

4 How to compare DBMS s Comparing of row-store with column-store row-store vs. column-store Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

5 How to compare DBMS s Comparing of row-store with column-store row-store vs. column-store Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

6 How to compare DBMS s Comparing of row-store with column-store row-store vs. column-store column-like row-store vs. column-store Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

7 How to compare DBMS s Comparing of row-store with column-store row-store vs. column-store column-like row-store row-store vs. vs. column-store row-like column-store Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

8 Join Details particular key value satisfies the predicate (the hash table should easily fit in memory since dimension tables are typically small and the table contains only keys). An example of the execution of this first phase for the above query on some sample data is displayed in Figure 2. First Phase Apply region = 'Asia' on Customer table custkey region nation Asia China... 2 Europe France... 3 Asia India Apply region = 'Asia' on Supplier table suppkey region nation... 2 Asia Europe Russia Spain Apply year in [992,997] on Date table dateid year Hash table with keys and 3 Hash table with key Hash table with keys 997, 2997, and 3997 Figure 2: The first phase of the joins needed to execute Query Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 5 / 8

9 roup-by Motivation columns need foreign key Invisible column Joinof the fact table, creatingexperiments a list of all the positions Summary h can have significant in the foreign key column that satisfy the predicate. Then, the Join Details position lists from all of the predicates are intersected to generate introduce a technique a list of satisfying positions P in the fact table. An example of the lumn-oriented databases execution of this second phase is displayed in Figure 3. Note that Second Phase ema style tables. It is a position list may be an explicit list of positions, or a bitmap as values that need to be shown in the example. sets of disadvantages ins into predicates on These predicates can (in which case a hash ed methods, such as a Fact Table orderkey 2 custkey 3 3 suppkey 2 orderdate revenue ing, discussed in Sec es on fact table columns, other selection predi-, and any of the predivious work [5] can be pplied in parallel and p operations. Alternacan be pipelined into number of times the ter all predicates have cted from the relevant lel). By waiting until ng this extraction, the ized. on improving perfore reminiscent of semin-oriented layout, and s described below. Hash table with keys and 3 probe = matching fact table bitmap for cust. dim. join probe Hash table with key = Bitwise And probe Hash table with keys 997, 2997, and 3997 = = fact table tuples that satisfy all join predicates Figure 3: The second phase of the joins needed to execute Volodymyr Piven (UniversitätQuery Tübingen) 3. from the Column-Stores Star Schema vs. Row-Stores benchmark on some sample2. Januar 2 6 / 8

10 Join Details Third Phase Fact Table Columns custkey suppkey orderdate fact table tuples that satisfy all join predicates bitmap value extraction bitmap value extraction bitmap value extraction = = = dimension table 3 nation China France India Positions nation Russia Spain dateid Positions Values position lookup position lookup year join = = = India China Russia Russia Join Results of expressing the join ingly common case (f dimension table that r contiguous. When thi predicate rewriting ca ten from a hash-looku predicate where the fo range. For example, i ter a predicate has be of inserting each of t hash table for each for ply check to see if the so, then the tuple join are faster to execute f directly without lookin The ability to apply valid dimension table this property does no a non-sorted field resu even for predicates on mension table by that Figure 4: The third phase of the joins needed to execute Query they are no longer an Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 3. from the Star Schema benchmark on some sample data ever, 2 the latter7 concer / 8

11 Technical Details Versuchaufbau 2.8 GHz single processor Dual core Pentium R D 3 GB of RAM RedHat Enterprise Linux 5 Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 8 / 8

12 r amotivation fully vertically tion aboutinvisible their respective Join entities in the expected Experiments way. Figure Summary cluding that tuple problem, Technical and Details that (adapted from Figure 2 of [9]) shows the schema of the tables. As with TPC-H, there is a base scale factor which can be used is essential to imted to scale the size of the benchmark. The sizes of each of the tables Schema ofarethe definedssbm relative to this Benchmark scale factor. In this paper, we use a scale DBMS. It in- factor of (yielding a LINEORDER table with 6,, tuples). /X, as well as ed data [4]. Like CUSTOMER store can dramatiloads, CUSTKEY but doesn t ow-store physical NAME ADDRESS CITY e of C-Store, nothe literature (e.g., REGION NATION tive to a row-store mething that prior PHONE MKTSEGMENT ance of a row and le plans that scan tuples ( early maa carefully constores outperform ns they read from ons for improving ced techniques for ementation in Shore of Shore to a verproposes an optilicating header in- Size=scalefactor x 3, SUPPLIER SUPPKEY NAME ADDRESS CITY NATION REGION PHONE Size=scalefactor x 2, LINEORDER ORDERKEY LINENUMBER CUSTKEY PARTKEY SUPPKEY ORDERDATE ORDPRIORITY SHIPPRIORITY QUANTITY EXTENDEDPRICE ORDTOTALPRICE DISCOUNT REVENUE SUPPLYCOST TAX COMMITDATE SHIPMODE Size=scalefactor x 6,, PART PARTKEY NAME MFGR CATEGOTY BRAND COLOR TYPE SIZE CONTAINER Size=2, x ( + log2 scalefactor) DATE DATEKEY DATE DAYOFWEEK MONTH YEAR YEARMONTHNUM YEARMONTH DAYNUMWEEK. (9 add!l attributes) Size= 365 x 7 Figure : Schema of the SSBM Benchmark Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 9 / 8

13 First Test Baseline performance of C-Store and System X Time (seconds) RS.2 RS(MV) CS CS(Row-MV) Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 / 8

14 First Test Baseline performance of C-Store and System X Time (seconds) RS.2 RS(MV) CS CS(Row-MV) Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 / 8

15 Row-Store Row-Store Execution Vertical Partitioning Each attribute is a two-column table (values, position) Index-All Unclustered B + -Treeindex for every column of every table Materialized View Optimal set of materialized views for every query Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 / 8

16 Row-Store Average performance across all queryies Time (seconds) T 64. T(B).2 MV 79.9 VP 22.2 AI T T(B) MV VP AI Traditional Traditional (bitmap) Materialized View Vertical Partitioning Index-only Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 2 / 8

17 Row-Store Reasons Tuple Overheads VP Single column-table requiers.7 -. GByte (compressed) T Entire 7 column is 6 GByte (decompressed) or 4 GByte (compressed) Column Joins Hash-join is slow Perhaps the best for Index-All Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 3 / 8

18 Column-Store Column-Store Execution Compression Late Materialization Block Iteration Invisible Join Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

19 Column-Store Column-Store Execution Compression Late Materialization Block Iteration Invisible Join Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 4 / 8

20 Column-Store Average performance across all queryies Time (seconds) T t I C L Tuple Block Invisible Join Compression Late Materialization ticl TICL ticl TiCL ticl TicL Ticl Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 5 / 8

21 Column-Store Analysis Block: 5% - 5% Compression: almost factor 2 averagely Late materialization: factor 3 Invisible Join: 5% - 75% Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 6 / 8

22 Column-Store Analysis Block: 5% - 5% Compression: almost factor 2 averagely Late materialization: factor 3 Invisible Join: 5% - 75% Optimization for star schemas Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 6 / 8

23 Column-Store Average performance across all queryies Time (seconds) Base PJ, No C PJ, Int C PJ, Max C No C Int C Max C Not compressed Dictionary compressed into integers Compressed as much as posible Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 7 / 8

24 Summary Significant optimizations: Compression Late materialization Without optimizations column store acts just like a row store Invisible join makes denormalizationis useless Volodymyr Piven (Universität Tübingen) Column-Stores vs. Row-Stores 2. Januar 2 8 / 8