Columnstore Indexes – part 76 (“Compression Delay”)

Continuation from the previous 75 parts, the whole series can be found at http://www.nikoport.com/columnstore/.

While playing with SQL Server 2016 CTP 3.2, I have found some interesting feature being mentioned inside the engine. The strange thing was called a compression delay and it was an option for Columnstore Indexes. I was surprised. I had to check on the internet and on Microsoft documentation pages but there was nothing to be found.
After joining the bits all together, contacting Microsoft and doing experiments, this blog post will show you the benefits and the importance of the Compression Delay.

This blog post is about Compression Delay feature of all Columnstore Indexes in SQL Server 2016. This is a feature that you can enable on your indexes in order to delay data compression of the Delta-Stores (open and the closed ones), thus converting Rowstore data into compressed Row Groups, the true Columnstore format.

The Intro

Why is there such a need to delay the data conversion from the Delta-Stores into the compressed Row Groups in the first place?
In SQL Server 2016 the OLTP Systems have received a significant improvement – support for the Columnstore Indexes (disk-based Nonclustered Columnstore & In-memory based Clustered Columnstore).
In both cases we have as the base the underlying OLTP-style table, with a Delta-Store object (or Tail Row Group for InMemory tables), that will hold the new data being inserted or updated by the final users. The data that is being frequently updated in OLTP-style systems is called Hot Data. The data that just being inserted into your table is definitely a Hot Data.
The important moment for the table is when the data becomes Cold or mostly infrequently read-accessed, and meaning that it can be compressed into Columnstore format.

That moment of conversion from Cold into Warm Data is something that can be so different on different systems and even within a specific system, different tables might have very different needs.
By default as of now we have the following delays pre-configured:
Disk-Based Columnstore: 0 Minutes This means that once you inserted data into a Delta-Store and it has reached it’s maximum size (which can vary under different circumstances, you can read more in Columnstore Indexes – part 73 (“Big Delta-Stores with Nonclustered Columnstore”)) the data will be compressed with the next invocation of Tuple Mover (by default one in 5 minutes at max or by the Alter Index Reorganize invocation).
In-Memory Columnstore: 0 Minutes (New!) for In-Memory Columnstore Index the situation is the same since the last version of SQL Server 2016 CTP, removing the difference that there was before. Once the Tail Row Group has over 1048567 rows, the background compression process will pick the 1048567 rows at a time and convert them to a compressed Row Group. Alternatively, of course, you can execute the migration process manually with the help of the stored procedure and then the data will be migrated instantly. 🙂

In SQL Server 2016 CTP 3.2 there is already another way of controlling the compression delay for both disk-based Columnstore Indexes (and hopefully the in-memory support will be done by RTM).

The best part is that this feature is enabled at all important levels of columnstore index table operations:
– Table Definition/Creation
– Create Columnstore Index command
– Alter Index command

This means that you can take control of your when your data is compressed at any point of time.
The syntax of this feature is very simple:

meaning that we can define a non-negative value in minutes of the compression delay for our table.

At this point we should definitely try it out and here is a simple structure for a table with Nonclustered Columnstore Index that contains the option of compression delay set to 5 minutes:

To my surprise I have received a following error message:

At which point I tried to experiment with the other options of defining the columnstore index outside of the table definition or redefining it with the help of Alter Index command – but all in vain … 🙁
From the other side, I have the contact of some wonderful people in development team who shared with me the workaround and even authorised for sharing with the community through the blog 🙂

You need to enable this specific trace flag for being able to play with this feature here and now, hopefully before it becomes enabled by default:

After enabling the trace flag I have re-executed my test script and it was created successfully this time:

Now this table will function in a different way, giving a delay of 5 minutes to any data that is ready for being compressed.
We can always change this setting by using the Alter Index command, for example in the following script I am setting it to be equal to InMemory tables – 60 minutes:

Brilliant stuff! 🙂

The Test

For the test I will use again the free ContosoRetailDW database from Microsoft, which I will restore from the downloaded backup that was copied into C:\Install folder:

I have also added a Clustered Columnstore on FactOnlineSales table, just because I love it so much :p

Let’s create a sample table for the Nonclustered Columnstore Index, setting the Compression Delay instantly to 30 Minutes.

Now let’s load 1.100.000 rows from the FactOnlineSales table into our test table so that we have enough data to fill out a whole Delta-Store, but in a way that will not trigger the Bulk Load API compressing data automatically into a compressed Row Group (loading less data then 102.400 rows will be exactly as flying under the radar). In this case I simply went and loaded 100.000 rows 11 times 🙂

I will use CISL, my free and open-sourced library of Columnstore Indexes scripts for monitoring the behaviour, executing it twice with the interval of 5 minutes, thus allowing automated Tuple Mover to finish it’s execution in the background (it runs every 5 minutes):

Compression Delay - CISL RowGroupsDetails results with DelayYou can see that even after 5 minutes delay the closed Delta-Store has not changed from Closed to Compressed Row Group. This is achieved because Compression Delay setting did now allowed the automated Tuple Mover to convert the data from Delta-Store.

To prove it let’s truncate the table and reset the Compression Delay to 0:

Let’s monitore again with the help of the cstore_GetRowGroupsDetials stored procedure from CISL:

Compression Delay - CISL RowGroupsDetails results without Delay
This time we have a compressed Row Group, since nothing has prevented the automated Tuple Mover to convert the closed Delta-Store, and so it worked as expected.

InMemory Columnstore

For InMemory Columnstore you can simply use the script below to create the memory optimised filegroup and then the test table where I go and load directly 1.1 Million Rows at one time, since for In-Memory we do not have an automated Bulk Load API optimisation for automated conversion to compressed Row Group enabled:

But then the interesting part starts: In the SQL Server 2016 CTP 3.2 you can not execute the ALTER INDEX command:

But in SQL Server 2016 RC1 you can already drop and then add a Columnstore Index to the Memory-Optimised Table:

Naturally the main idea would be to fall back and define at the table creation moment:

But in SQL Server 2016 CTP 3.3 the error message persists, proving that this feature is not fully compatible yet:

In SQL Server 2016 RC1 the above query executes well without any mistakes. 🙂

I do my best to avoid writing about InMemory tables with Columnstore Indexes, because I expect many things to improve at the RTM timeframe. I also suggest not to do a fast judgement on this brand new feature.

Current Compression Delay

You might wonder if there is a way to discover the current compression delay for each of the tables, especially since sys.tables DMV does not contain any new columns, or is there another trace flag to find it out ?
Its much easier then that – the information about the compression delay setting is stored in the sys.indexes DMV and here is the query for finding out the current compression delay for all Columnstore Indexes:

Compression Delay - Current settings
Here you can see exactly the settings I have chosen for my tables and the most interesting case is of course the dbo.FactOnlineSales table itself – it contains the value of -1, which to my understanding represents a default value.

The Clustered Columnstore

When thinking about Clustered Columnstore Indexes, one might believe that the feature of Compression Delay is quite useless, we do the ETL and we want all our Delta-Stores to be converted to Compressed Row Groups.
Well, but what if we have multiple steps of ETL and for example in this 2 step exercise
Step 1. We have loaded the data.
Step 2. We shall run some updates over it. Having all data converted at this step will be an expensive operation of creation of even more new Delta-Stores, while deprecating the data inserted in the previous step and introducing some serious fragmentation into our Clustered Columnstore Index.
Compression Delay here would prevent closed Delta-Stores to become compressed and would allow to have overall resource spending and better final result.

Final Thoughts

We do not get way too many knobs to control the SQL Server and I really hope that this one is staying within SQL Server engine. The importance of the control on the table level of the Delta-Store conversion to compressed Row Groups is not to be underestimated. Especially with the appearance of InMemory Columnstore Indexes, the need of the precise control of the available resources and lowering the logical fragmentation (deleted bitmap content) are the key to get the best performance possible out of the system.
In an high-performance OLTP System getting an explanation that the Reporting/Analytics engine is slowing it down is something that will not stick well and this new feature Compression Delay will allow to address some of the issues.

to be continued with Columnstore Indexes – part 77 (“SSIS 2016 & Columnstore”)

Leave a Reply

Your email address will not be published. Required fields are marked *