Your SlideShare is downloading. ×
0
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
SQL Server 2012 In Memory Column Store Index Deep Dive
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SQL Server 2012 In Memory Column Store Index Deep Dive

3,858

Published on

SQL Server 2012 In Memory Column Store Index Deep Dive for Data Warehousing and Reporting

SQL Server 2012 In Memory Column Store Index Deep Dive for Data Warehousing and Reporting

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,858
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
111
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Referencehttp://tr13.techreadytv.com/sessions/db307/
  • Point of SlideThe objective of this slide is to highlight the current challenge faced when querying data warehouses with tremendous amount of data: WAIT TIME.
  • Point of SlideThe objective of this slide is to highlight that ColumnStore Index will speed up the query performance along with other administration and maintenance benefits.DescriptionBenefits of ColumnStore Index can be summarized as:Interactive experiences with data  fast response timeEasy to use  reducing the amount of admin tasksLower TCO  reducing total cost.
  • Point of SlideGive a brief overview on the definition of ColumnStore.
  • Point of SlideGive a brief overview on the definition of ColumnStore covering the following points:It’s a new type of index in SQL ServerNew query processing mode:Processes data in batchesAccelerates targeted workloads:Data warehousingRead mostly, large data volumes, star schema, often sliding windowTypical data warehouse queriesStar joins, aggregations, filteringSQL Server relational data warehousesScale up SMP, up to 10s of TB
  • Point of SlideHighlight difference between Heaps/B-Trees and ColumnStore in terms of how data is stored.DescriptionBriefly describe how heaps and B-Trees work: http://msdn.microsoft.com/en-us/library/ms189051.aspxExplain how ColumnStore works:Columnstore indexes in SQL Server have key characteristics that differentiate it from a traditional row-based store. Some of them are described below:Columnar data format – Unlike the traditional row-based organization of data (called rowstore format), in columnar database systems such as SQL Server with columnstore indexes, data is grouped and stored one column at a time. SQL Server query processing can take advantage of the new data layout and significantly improve query execution time.Faster query results – Columnstore indexes can produce faster results for the following reasons:Only the columns needed must be read. Therefore, less data is read from disk to memory and later moved from memory to processor cache.Columns are heavily compressed. This reduces the number of bytes that must be read and moved.Most queries do not touch all columns of the table. Therefore, many columns will never be brought into memory. This, combined with excellent compression, improves buffer pool usage, which reduces total I/O.Advanced query execution technology processes chunks of columns called batches in a streamlined manner, reducing CPU usage.Referencehttp://sharepoint/sites/gtr_sql/Shared%20Documents/24985_SQL%20Server%20Denali,%20Specialty%20Track%20Advanced%20Fast%20Data%20Warehouse%20Query%20Processing%20using%20Columnstore%20Indexes%20(Apollo)/CommonILT/34753_SQL-Server-2012-Fundamentals_M09_ColumnStoreIndex.docx
  • DescriptionEach physical partition of a columnstore index is broken into one-million-row chunks called segments (a.k.a. row groups). The index build process creates as many full segments as possible. Because multiple threads work to build an index in parallel, there may be a few small segments (typically equal to the number of threads) at the end of each partition with the remainder of the data after creating full segments. That's because each thread might hit the end of its input at different times. Non-partitioned tables have one physical partition.Each partition is compressed separately. Each partition has its own dictionaries. All segments within a partition share dictionaries. Dictionaries for different partitions are independent. This allows partition switching to be a metadata-only operation.A segment is stored as a LOB, and can consist of multiple pages. We elected to bring columnstore index data into memory on demand rather than require that all data fits in memory so customers can access databases much bigger than will fit in main memory. If all your data fits in memory, you'll get reduced I/O and the fastest possible query performance. But it's not necessary for all data to fit in memory, and that's a plus.Referencehttp://social.technet.microsoft.com/wiki/contents/articles/3540.sql-server-columnstore-index-faq.aspx
  • DescriptionThis example including the 2 following slides clarify the theory explained in previous ones
  • DescriptionClarify the previous slide.
  • DescriptionAlong with the columnstore index, SQL Server introduces batch processing to take advantage of the columnar orientation of the data. The columnstore structure and batch processing both contribute to performance gains, but investigating performance issues might be more complex than if only one factor were involved.What is batch mode processing?Batch mode processing uses a new iterator model for processing data a-batch-at-a-time instead of a-row-at-a-time. A batch typically represents about 1000 rows of data. Each column within a batch is stored as a vector in a separate area of memory, so batch mode processing is vector-based. Batch mode processing also uses algorithms that are optimized for the multicore CPUs and increased memory throughput that are found on modern hardware. Batch mode processing spreads metadata access costs and other types of overhead over all the rows in a batch, rather than paying the cost for each row. Batch mode processing operates on compressed data when possible and eliminates some of the exchange operators used by row-mode processing. The result is better parallelism and faster performance.
  • DescriptionColumnStore is a non-clustered index.Only one allowed per table.If a base table is a clustered index, all columns in the clustering key must be present in the nonclusteredcolumnstore index. If a column in the clustering key is not listed in the create index statement, it will be added to the columnstore index automatically.Columnstore indexes work with table partitioning. No change to the table partitioning syntax is required. A columnstore index on a partitioned table must be partition-aligned with the base table. Therefore, a nonclusteredcolumnstore index can only be created on a partitioned table if the partitioning column is one of the columns in the columnstore index.
  • DescriptionCannot be a unique index.Cannot be created on a view or indexed view.Cannot include a sparse column.Cannot act as a primary key or a foreign key.Cannot be changed using the ALTER INDEX statement. Drop and re-create the columnstore index instead. (You can use ALTER INDEX to disable and rebuild a columnstore index.)Cannot be created by with the INCLUDE keyword.Cannot include the ASC or DESC keywords for sorting the index. Columnstore indexes are ordered according to the compression algorithms. Sorting is not allowed.
  • Point of SlideExplain how to create the index in SSMS
  • Point of SlideDecision support query performance is often improved when columnstore indexes are used on large tables, but some queries and even whole workloads may perform worse. By using a cost-based approach, the query optimizer typically decides to use a columnstore index only when it improves the overall performance of the query. However, the cost models the optimizer uses are approximate and sometimes the optimizer chooses to use the columnstore index for a table when it would have been better to use a row store (B-tree or heap) to access the table. If this occurs, use the IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX query hint, or use an index hint to direct the optimizer to a row store index. The optimizer might still include some information from the columnstore index. Therefore, in rare cases, this option might not resolve the performance problem. If your workload performance is not helped by a columnstore index, and you cannot use index hints to correct the issue, drop the columnstore index to revert to row store processing.ReferenceSection “Potential of a poor performance”: http://msdn.microsoft.com/en-us/library/gg492088(v=SQL.110).aspx
  • Point of SlideUsage of Columnstore indexes allocates memory from their own object pool to create columnstore objects like segments and dictionaries. Referencehttp://sharepoint/sites/gtr_sql/_layouts/WordViewer.aspx?id=/sites/gtr_sql/Shared%20Documents/24985_SQL%20Server%20Denali,%20Specialty%20Track%20Advanced%20Fast%20Data%20Warehouse%20Query%20Processing%20using%20Columnstore%20Indexes%20(Apollo)/Specialty/24985_Columnstoreindex_M01_IndexMgtTshoot.docx.docx
  • Point of SlideHighlight the use of the different query hint to guide the Optimizer in choosing/ignoring the appropriate index.
  • Point of SlideDemonstrate the effect of the query hint shown in the query plan
  • Point of SlideTwo properties are set to Batch if CS is used: Actual Execution Mode and Estimated Execution Mode.
  • ReferenceFor all troubleshooting section: http://sharepoint/sites/gtr_sql/_layouts/WordViewer.aspx?id=/sites/gtr_sql/Shared%20Documents/24985_SQL%20Server%20Denali,%20Specialty%20Track%20Advanced%20Fast%20Data%20Warehouse%20Query%20Processing%20using%20Columnstore%20Indexes%20(Apollo)/
  • Point of SlideObjective of this slide and next ones is to give an example demonsrating how to create a ColumnStore Index From a Clustered Index.
  • Transcript

    • 1. SQL SERVER 2012 MOMENTUM WORKSHOP: COLUMNSTORE INDEX DEEP DIVE © 2011 Microsoft Last Updated: Saturday, December 14, 2013
    • 2. IS THIS YOUR DATA WAREHOUSE EXPERIENCE? Waiting…
    • 3. COLUMNSTORE INDEXES • Interactive experiences with data • Near instant response times on large data sets • Ad hoc and reporting queries • Easy to use Waiting • Reduced need for summary tables, indexed views, OLAP cubes • Fewer indexes to design and maintain • Reduced need to manually tune queries • Lower TCO • Reduced people costs • Lower hardware costs
    • 4. AGENDA • ColumnStore Definition • How Does ColumnStore Accelerate Queries? • What is a ColumnStore Index? • How Do I Use It? • When Should I Use It? • When Should I Not Use It? • Design Schemas and Queries to Take Best Advantage of the Power of ColumnStore Indexes • How to Add Data to a Table with a ColumnStore Index • Anticipate and Troubleshoot Challenges Related to Memory Usage and Query Plans when Using ColumnStore Indexes • When to/When Not to Build ColumnStore Indexes • Best Practices for Creating ColumnStore Indexes
    • 5. COLUMNSTORE DEFINITION ColumnStore offering in SQL Server New query processing mode Accelerates targeted workloads • New type of index • Processes data in batches • Typical data warehouse queries • SQL Server relational data warehouses, up to 10s of TB
    • 6. COLUMNSTORE DEMO
    • 7. HOW DOES COLUMNSTORE SPEED UP QUERIES? (1) … C1 C2 C3 C4 C5 C6 Heaps, B-trees store data row-wise ColumnStore indexes store data column-wise • Each page stores data from a single column Highly compressed • About 2x better than PAGE compression • More data fits in memory Each column can be accessed independently • Fetch only needed columns • Can dramatically decrease IO
    • 8. HOW DOES COLUMNSTORE SPEED UP QUERIES? (1) C1 C2 C3 C4 C5 C6 ColumnStore Index Structure • Segment contains values from one column for a set of rows • Segments for the same set of rows comprise a row group • Segments are compressed • Each segment stored in a separate LOB • Segment is unit of transfer between disk and memory
    • 9. COLUMNSTORE INDEX EXAMPLE OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101107 106 01 1 6 30.00 20101107 103 04 2 1 17.00 20101107 109 04 2 2 20.00 20101107 103 03 2 1 17.00 20101107 106 05 3 4 20.00 20101108 106 02 1 5 25.00 20101108 102 02 1 1 14.00 20101108 106 03 2 5 25.00 20101108 109 01 1 1 10.00 20101109 106 04 2 4 20.00 20101109 106 04 2 5 25.00 20101109 103 01 1 1 17.00
    • 10. HORIZONTALLY PARTITION (ROW GROUPS) OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101107 106 01 1 6 30.00 20101107 103 04 2 1 17.00 20101107 109 04 2 2 20.00 20101107 103 03 2 1 17.00 20101107 106 05 3 4 20.00 20101108 106 02 1 5 25.00 OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101108 102 02 1 1 14.00 20101108 106 03 2 5 25.00 20101108 109 01 1 1 10.00 20101109 106 04 2 4 20.00 20101109 106 04 2 5 25.00 20101109 103 01 1 1 17.00
    • 11. VERTICALLY PARTITION (SEGMENTS) OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101107 106 01 1 6 30.00 20101107 103 04 2 1 17.00 20101107 109 04 2 2 20.00 20101107 103 03 2 1 17.00 20101107 106 05 3 4 20.00 20101108 106 02 1 5 25.00 OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101108 102 02 1 1 14.00 20101108 106 03 2 5 25.00 20101108 109 01 1 1 10.00 20101109 106 04 2 4 20.00 20101109 106 04 2 5 25.00 20101109 103 01 1 1 17.00
    • 12. COMPRESS EACH SEGMENT* OrderDateKey 20101107 20101107 20101107 20101107 20101107 20101108 ProductKey StoreKey RegionKey Quantity SalesAmount 106 01 1 6 30.00 04 2 1 2 17.00 2 2 1 103 109 04 103 03 106 106 OrderDateKey 20101108 ProductKey 20101108 102 20101108 106 20101109 109 20101109 106 20101109 106 103 05 3 1 02 RegionKey StoreKey 1 02 2 03 1 01 2 04 04 01 2 1 4 5 20.00 17.00 20.00 25.00 Quantity 1 SalesAmount 5 14.00 1 25.00 4 5 1 10.00 20.00 25.00 17.00
    • 13. HOW DOES COLUMNSTORE SPEED UP QUERIES? (2) SELECT region, sum (sales) … C2 C1 C3 C4 C5 C6 Fetches only needed columns from disk • • Less IO Better buffer hit rates
    • 14. EXAMPLE OF FETCHING ONLY NEEDED COLUMNS ProductKey SalesAmount OrderDateKey OrderDateKey RegionKey Quantity SalesAmount 20101107 StoreKey ProductKey 106 30.00 20101107 103 17.00 20101107 01 1 6 04 2 1 20101107 2 2 20101108 2 1 04 03 05 3 1 02 RegionKey StoreKey 1 02 2 03 1 01 2 04 04 01 2 1 4 20101107 109 103 106 106 20.00 17.00 20.00 25.00 OrderDateKey 20101108 ProductKey 20101108 102 Quantity 20101108 106 14.00 1 20101109 109 25.00 5 20101109 20101109 106 10.00 1 106 20.00 5 4 5 1 103 SalesAmount 25.00 17.00
    • 15. HOW DOES COLUMNSTORE SPEED UP QUERIES? (3) Advanced query-processing technology • Batch-mode execution of some operations • Processes column data in batches • Groups of batch operations in query plan • Compact data representation • Highly efficient algorithms • Better parallelism
    • 16. WHAT IS COLUMNSTORE INDEX? Base table OR Clustered index Heap Nonclustered Nonclustered Nonclustered ColumnStore index index index Indexed view Filtered index - No CS index on indexed view - No CS as filtered index • ColumnStore (CS) index is nonclustered (secondary) • Base table can be clustered index or heap • One CS index per table • Multiple other nonclustered (B-tree) indexes allowed • But may not be needed • CS index must be partition-aligned if table is partitioned
    • 17. WHAT IS COLUMNSTORE INDEX? RESTRICTIONS Data Types Index Creation Maintain table Process queries • Only on common business data types • int, real, string, money, datetime, decimal <= 18 digits • 1024 columns • NC index only • Limited operations • Can read but cannot update the data • Can switch partitions in and out • All read-only T-SQL queries run • Some queries are accelerated more than others
    • 18. HOW DO I USE IT? INDEX CREATION Create a ColumnStore index • Create the table • Load data into the table • Create a non-clustered ColumnStore index on all, or some, columns CREATE NONCLUSTERED COLUMNSTORE INDEX ncci ON myTable(OrderDate, ProductID, SaleAmount) Object Explorer
    • 19. HOW DO I USE IT? RUNNING QUERIES Let the query optimizer do the work Optimizer makes a cost-based decision Data access method • • • • Columnstore index Clustered (row-based) index Nonclustered (row-based) index Heap Processing mode • Batch mode • Row mode
    • 20. HOW DO I USE IT? MEMORY MANAGEMENT • • • • Memory management is automatic ColumnStore is persisted on disk Needed columns fetched into memory ColumnStore segments flow between disk and memory T.C1 T.C1 T.C1 T.C1 T.C1 T.C4 T.C2 T.C3 T.C3 T.C2 T.C3 T.C2 T.C3 T.C3 SELECT C2, SUM(C4) FROM T GROUP BY C2; T.C2 T.C4 T.C4 T.C2 T.C4 T.C4
    • 21. HOW DO I USE IT? RUNNING QUERIES Using Index Hints with ColumnStore Queries Use the ColumnStore index select distinct (SalesTerritoryKey) from dbo.FactResellerSales with (index (ncci)) Use a different index select distinct (SalesTerritoryKey) from dbo.FactResellerSales with (index (ci)) Ignore ColumnStore index select distinct (SalesTerritoryKey) from dbo.FactResellerSales option (IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX)
    • 22. HOW DO I USE IT? RUNNING QUERIES
    • 23. RUNNING QUERIES DEMO
    • 24. HOW TO ADD DATA TO A TABLE WITH A COLUMNSTORE INDEX Method 1: Disable the ColumnStore index Disable (or drop) the index • ALTER INDEX my_index ON MyTable DISABLE Update the table Rebuild the columnstore index • ALTER INDEX my_index ON MyTable REBUILD
    • 25. HOW TO ADD DATA TO A TABLE WITH A COLUMNSTORE INDEX Method 2: Use Partitioning Load new data into a staging table Build a ColumnStore index CREATE NONCLUSTERED COLUMNSTORE INDEX my_index ON StagingT(OrderDate, ProductID, SaleAmount) Switch the partition into the table ALTER TABLE StagingT SWITCH TO T PARTITION 5
    • 26. HOW TO ADD DATA TO A TABLE WITH A COLUMNSTORE INDEX Method 3: Union All Build ColumnStore index on partitioned primary table Create staging table with no ColumnStore index Periodically build CS index on staging table • Switch staging table into an empty partition of the primary table Insert new data into (row-based) staging table Query both tables; UNION ALL to combine results
    • 27. TROUBLESHOOTING: CREATING THE COLUMNSTORE INDEX • Memory • • • • • • Ensure enough memory Memory requirement related to #columns, data, DOP Memory available ≠ memory on the box with concurrent activity By default, query is restricted to 25% even when RG not enabled Check Showplan XML for memory grant info Rough estimate: Memory grant request in MB = [(4.2 * Num of columns in the CS index) + 68] * DOP + (Num of string cols * 34)
    • 28. TROUBLESHOOTING: CREATING THE COLUMNSTORE INDEX Parallelism • Index build is parallel only if table has > 1 M rows Size and other info: check new catalog views • Sys.column_store_segments • Sys.column_store_dictionaries
    • 29. TROUBLESHOOTING: QUERY PERFORMANCE Is the ColumnStore index being used? Are other nonclustered indexes being used? Are there issues unrelated to the ColumnStore index? • All needed columns present? • Cardinality estimate? If selective, optimizer will choose a B-Tree • Too many indexes + bad statistics can confuse the optimizer • Consider using hints and/or disabling other indexes • Sorts, spills, table spools? • Is a lot of data being returned to the client? • Not all bottlenecks are query processing
    • 30. TROUBLESHOOTING: QUERY PERFORMANCE • Is batch mode being used to process most of the data? • • • • • ColumnStore index? Outer joins? DOP? Loop join? Check cardinality estimate Other operators? o Batch-enabled: – Scan, filter, project – Local hash partial aggregation – Hash inner join, hash table build
    • 31. TROUBLESHOOTING: QUERY PERFORMANCE Filters or joins on strings? • Filters on strings are not pushed into storage engine • Joins on integers are more efficient Filter with “OR”? • IN-lists but not OR filters pushed down Hash tables don’t fit into memory? • Usually due to small memory grant based on CE error, not physical memory limitation • Fall back to row mode processing • Slower than a row mode join
    • 32. WHEN TO BUILD A COLUMNSTORE INDEX Read-mostly workload Most updates are appending new data Your workflow permits using partitioning (or drop rebuild index) to handle new data • Typically a nightly load window Most queries fit a star join pattern or entail scanning and aggregating large amounts of data Build a ColumnStore index on your large fact tables Consider a ColumnStore index if you have a very large dimension table
    • 33. WHEN NOT TO BUILD A COLUMNSTORE INDEX Frequent updates You need to update data and partition switching or rebuilding index does not fit your workflow Frequent small look up queries • B-tree indexes may give better performance Your workload does not benefit
    • 34. BEST PRACTICES FOR CREATING A COLUMNSTORE INDEX Use a star schema when possible • Build CS index on fact tables • Consider for large dimension tables Include all the columns in the CS index • Don’t use to seek into a row • Order of listed columns not important Convert decimal to precision <= 18 if possible Use integer types whenever possible
    • 35. BEST PRACTICES FOR CREATING A COLUMNSTORE INDEX • Ensure enough memory to build the CS index • Consider table partitioning to facilitate updates • Consider modifying queries to hit the “sweet spot” • Star joins • Inner joins • Group By • Keep statistics up to date • Use MAXDOP > 1 • Check query plans for use of ColumnStore index and batch mode processing • Consider creating the CS index from a clustered index • Better segment elimination when predicate on key • Slightly better compression (no RID)
    • 36. CREATE THE CS INDEX FROM A CLUSTERED INDEX Min 2011-01-01 Min 1 Min 18 Min 10.65 Max 2011-01-25 Max 415 Max 230 Max 88.62 CREATE TABLE T2 (TxDate DATE, CustId INT, ProdId INT, Amt FLOAT); CREATE CLUSTERED INDEX ci ON T2 (TxDate, CustId); CREATE NONCLUSTERED COLUMNSTORE INDEX ncci ON T2 (TxDate, CustId, ProdId, Amt); SELECT CustId, sum(Amt) FROM T2 WHERE TxDate < '2011-01-15' GROUP BY CustId; Min 2011-01-26 Min 19 Min 165 Min 22.63 Max 2011-02-14 Max 392 Max 400 Max 120.41 Min 8 Min 5.95 Min 2011-02-14 Min 5 Max 2011-03-02 Max 378 Max 258 Max 96.25
    • 37. CREATE THE CS INDEX FROM A CLUSTERED INDEX Min 2011-01-01 Min 1 Min 18 Min 10.65 Max 2011-01-25 Max 415 Max 230 Max 88.62 CREATE TABLE T2 (TxDate DATE, CustId INT, ProdId INT, Amt FLOAT); CREATE CLUSTERED INDEX ci ON T2 (TxDate, CustId); CREATE NONCLUSTERED COLUMNSTORE INDEX ncci ON T2 (TxDate, CustId, ProdId, Amt); SELECT CustId, sum(Amt) FROM T2 WHERE TxDate < '2011-01-15' GROUP BY CustId; Only need to read 3 segments Min 2011-01-26 Min 19 Min 165 Min 22.63 Max 2011-02-14 Max 392 Max 400 Max 120.41 Min 8 Min 5.95 Min 2011-02-14 Min 5 Max 2011-03-02 Max 378 Max 258 Max 96.25
    • 38. CREATE THE CS INDEX FROM A CLUSTERED INDEX Min 2011-01-01 Min 1 Min 18 Min 10.65 Max 2011-01-25 Max 415 Max 230 Max 88.62 What if the query is: SELECT CustId, sum(Amt) FROM T2 WHERE ProdId IN (365, 385, 391, 393) GROUP BY CustId; Or Min 2011-01-26 Min 19 Min 165 Min 22.63 Max 2011-02-14 Max 392 Max 400 Max 120.41 SELECT CustId, ProdId, sum(Amt) FROM T2 WHERE CustId BETWEEN 50 AND 100 GROUP BY CustId, ProdId; Min 8 Min 5.95 Min 2011-02-14 Min 5 Max 2011-03-02 Max 378 Max 258 Max 96.25
    • 39. SUMMARY: COLUMNSTORE IN A NUTSHELL ColumnStore technology + Advanced query processing Astonishing speedup for DW queries Great compression

    ×