Każda z wcześniejszych wersji SQL miała jedną znaczną bolączkę jeśli chodzi o columnstore index. Otóż utworzenie takiego indeksu wiązało się z tym, że tabela stawała się tylko do odczytu. W wersji 2014 problem został trochę osłabiony, bo clustered columnstore index mógł już być aktualizowany. Problem rozwiązano tam w ten sposób, że w momencie utworzenia indeksu wszystkie tradycyjnie zapisane rekordy były przerabiane na columnstore index, ale dodatkowo „za tym indeksem” powstawał dodatkowy obszar, w którym było można dopisywać informacje o modyfikacjach danych. Jeżeli więc dodano nowy rekord, to wisiał on sobie w tej dodatkowej przestrzeni, za indeksem columnstore. Jeśli rekord usunięto to podobnie dokładano taką informację w postaci tradycyjnego rekordu w tym dodatkowym obszarze. A jeśli rekord zmodyfikowano, to informację dokładało się dwa razy: raz jako usunięcie a raz jako dodanie. Ten obszar nosił nazwę delta store i dotyczył tylko indeksu clustrowanego.
W wersji 2016 podobną funkcjonalność dodano do indeksu nieclustrowanego. Ładne porównanie możliwości columnstore indeksu zawiera tabelka ze strony:
https://msdn.microsoft.com/en-us/library/dn934994.aspx
Jedną z głownych zalet posaidania takiego indeksu jest obecnie to, że jeżeli z danych ma korzystać zarówno aplikacja transakcyjna OLTP jak i analityczna OLAP, to wcale nie trzeba tworzyć dwóch instancji SQL połączonych przez procesy ETL. Do tej samej tabeli mogą sie odwoływać transakcje OLTP (bo tabela ma nadal kształt zwykłych rekordów), jak i analityczne (bo query optimizer sam dobierze najbardziej efektywny indeks i będzie to prawdopodobnie columnstore index).
Aktualizowalny nieklustrowany columnstore index podobnie jak to było z indeksem clustrowanym posiada oprócz danych zapisanych w kolumnach również delta store do zapamiętywania bieżących modyfikacji danych. Jeśli taka modyfikacja się przytrafi, to w ramach transakcji trzeba będzie zmodyfikować dane z normalnego (rowstore) indeksu oraz dane w delta store indeksu column store. Ale to nie wszystko!
Dane często charakteryzują się specyfinczym „tokiem życia”. Świeżo po wprowadzeniu do tabeli są gorące – „hot”, tzn. mogą podlegać intensywnym zmianom. Ale przychodzi taki moment, kiedy rekord „stygnie” i staje się „cold” i nie jest już często modyfikowany. Może to być rekord księgowy po zamknięciu miesiąca albo zamówienie, które zostało zrealizowane. Od wersji 2016 nonclustered column store indeks może być filtrowany! Wystarczy więc wymyślić filtr, który oddzieli dane hot od tych cold i nawet dellta store nie będzie musiał być zmieniany.
Zastosowanie tych nowych możliwości w SQL 2016 jest nazywane jako: Real-Time Operational Analytics
Bardzo ładnie opowiada o tym główny projektant dla column store indeksów: Sunil Agarwal:
