When a clustered index is created, the table itself becomes the index structure sorted by the index key.
Imagine now that we have 5 columns in a table XPTO (a,b,c,d,e) and "a" is the primary key and we create a column store index over table XPTO with columns (b,c).
What is the structure of this index? Is a different structure comparing to the clustered table? Or does the column store have pointers to the clustered table (like an other non clustered index).
Finally, the same scenario but creating the column index with all attributes, what is the structure?
Best Answer
We can learn a lot by creating a test script! You should be able to run the SQL below on any SQL 2014 instance (probably SQL 2012 as well, but I didn't test it there).
From this script, we can see that the non-clustered columnstore index on (b, c) does store the data for the clustered index column (a) and it does so in the same manner (via segments) that it stores b and c. This allows the columstore to efficiently process queries that access a, b, and c. Technically, it even allows the columnstore to be used, in combination with a key lookup, in order to process a query that needs all of the columns in the table (although this is not likely to be favored by the optimizer given the expense of the key lookup).
In terms of your questions about the "structure" of the columnstore index, I think that's too deep a question to answer here. But if you are interested in learning more, I think that Niko Neugebauer's excellent 55-part (and growing) series on columnstore has a ton of valuable information on the structure and internals: http://www.nikoport.com/columnstore/