Posted: 28 Oct 2011 06:30 PM PDT
There are two kind of storage in database. Row Store and Column Store. Row store does exactly as the name suggests – stores rows of data on a page – and column store stores all the data in a column on the same page. These columns are much easier to search – instead of a query searching all the data in an entire row whether the data is relevant or not, column store queries need only to search much lesser number of the columns. This means major increases in search speed and hard drive use. Additionally, the column store indexes are heavily compressed, which translates to even greater memory and faster searches. I am sure this looks very exciting and it does not mean that you convert every single index from row store to column store index. One has to understand the proper places where to use row store or column store indexes. Let us understand in this article what is the difference in Columnstore type of index.
Column store indexes are run by Microsoft’s VertiPaq technology. However, all you really need to know is that this method of storing data is columns on a single page is much faster and more efficient. Creating a column store index is very easy, and you don’t have to learn new syntax to create them. You just need to specify the keyword “COLUMNSTORE” and enter the data as you normally would. Keep in mind that once you add a column store to a table, though, you cannot delete, insert or update the data – it is READ ONLY. However, since column store will be mainly used for data warehousing, this should not be a big problem. You can always use partitioning to avoid rebuilding the index.
A columnstore index stores each column in a separate set of disk pages, rather than storing multiple rows per page as data traditionally has been stored. The difference between column store and row store approaches is illustrated below:
In case of the row store indexes multiple pages will contain multiple rows of the columns spanning across multiple pages. In case of column store indexes multiple pages will contain multiple single columns. This will lead only the columns needed to solve a query will be fetched from disk. Additionally there is good chance that there will be redundant data in a single column which will further help to compress the data, this will have positive effect on buffer hit rate as most of the data will be in memory and due to same it will not need to be retrieved.
Let us see small example of how columnstore index improves the performance of the query on a large table.
As a first step let us create databaseset which is large enough to show performance impact of columnstore index. The time taken to create sample database may vary on different computer based on the resources.
USE AdventureWorks
GO-- Create New TableCREATE TABLE [dbo].[MySalesOrderDetail]([SalesOrderID] [int] NOT NULL,[SalesOrderDetailID] [int] NOT NULL,[CarrierTrackingNumber] [nvarchar](25) NULL,[OrderQty] [smallint] NOT NULL,[ProductID] [int] NOT NULL,[SpecialOfferID] [int] NOT NULL,[UnitPrice] [money] NOT NULL,[UnitPriceDiscount] [money] NOT NULL,[LineTotal] [numeric](38, 6) NOT NULL,[rowguid] [uniqueidentifier] NOT NULL,[ModifiedDate] [datetime] NOT NULL
) ON [PRIMARY]
GO-- Create clustered indexCREATE CLUSTERED INDEX [CL_MySalesOrderDetail] ON [dbo].[MySalesOrderDetail]( [SalesOrderDetailID])GO-- Create Sample Data Table
-- WARNING: This Query may run upto 2-10 minutes based on your systems resourcesINSERT INTO [dbo].[MySalesOrderDetail]SELECT S1.*FROM Sales.SalesOrderDetail S1
GO 100
Now let us do quick performance test. I have kept STATISTICS IO ON for measuring how much IO following queries take. In my test first I will run query which will use regular index. We will note the IO usage of the query. After that we will create columnstore index and will measure the IO of the same.
-- Performance Test
-- Comparing Regular Index with ColumnStore IndexUSE AdventureWorks
GOSET STATISTICS IO ONGO-- Select Table with regular IndexSELECT ProductID, SUM(UnitPrice) SumUnitPrice, AVG(UnitPrice) AvgUnitPrice,SUM(OrderQty) SumOrderQty, AVG(OrderQty) AvgOrderQtyFROM [dbo].[MySalesOrderDetail]GROUP BY ProductIDORDER BY ProductID
GO-- Table 'MySalesOrderDetail'. Scan count 1, logical reads 342261, physical reads 0, read-ahead reads 0.
-- Create ColumnStore IndexCREATE NONCLUSTERED COLUMNSTORE INDEX [IX_MySalesOrderDetail_ColumnStore]ON [MySalesOrderDetail](UnitPrice, OrderQty, ProductID)GO-- Select Table with Columnstore IndexSELECT ProductID, SUM(UnitPrice) SumUnitPrice, AVG(UnitPrice) AvgUnitPrice,SUM(OrderQty) SumOrderQty, AVG(OrderQty) AvgOrderQtyFROM [dbo].[MySalesOrderDetail]GROUP BY ProductIDORDER BY ProductID
GO
It is very clear from the results that query is performance extremely fast after creating ColumnStore Index. The amount of the pages it has to read to run query is drastically reduced as the column which are needed in the query are stored in the same page and query does not have to go through every single page to read those columns.
If we enable execution plan and compare we can see that column store index performance way better than regular index in this case.
Let us clean up the database.
-- CleanupDROP INDEX [IX_MySalesOrderDetail_ColumnStore] ON [dbo].[MySalesOrderDetail]
GOTRUNCATE TABLE dbo.MySalesOrderDetail
GODROP TABLE dbo.MySalesOrderDetail
GO
In future posts we will see cases where Columnstore index is not appropriate solution as well few other tricks and tips of the columnstore index.
There are days, when I am kept wondering about SQL and Life overall. Today is Saturday and I was about to write about SQL Server. Just like any other morning, I woke up at 5 and opened my blog editor. I usually do not open 