SQL Server 2016 SP1: Columnstore в Standard Edition и что это меняет на практике

SP1 для SQL Server 2016 анонсирован - выход ожидается в ноябре. Новость прилетела на конференции PASS Summit, и главное в ней не набор патчей, а одно решение: Columnstore Index, In-Memory OLTP и Row-Level Security переезжают во все редакции. Standard, Express, даже Web Edition.

Раньше Columnstore Index в Enterprise стоил, грубо говоря, денег на другом уровне. Теперь это меняется.

Что именно переходит в Standard

Если без воды - три вещи, которые до SP1 были строго Enterprise:

• Columnstore Index (и clustered, и non-clustered) - колоночное хранение данных для аналитических запросов. На агрегациях по большим объёмам даёт прирост скорости на порядки по сравнению с row-store.
• In-Memory OLTP (Hekaton) - таблицы в памяти с lock-free механикой для высоконагруженных OLTP-сценариев. В Standard будет лимит на объём памяти под In-Memory таблицы, но базовая функциональность открывается.
• Row-Level Security - политики безопасности на уровне строк прямо в движке, без логики в приложении. Для мультитенантных схем и строгого разграничения доступа к данным.

Лимиты у Standard Edition остаются: 128 ГБ RAM, 4 сокета / 24 ядра. Но для большинства задач среднего бизнеса, которые к нам приходят, это не потолок.

Почему это важно для клиентов

Нас интересует Columnstore - и конкретная ситуация, которая у нас сейчас открывается.

Есть клиенты, у которых SQL Server Standard стоит давно. Аналитические отчёты работают на обычных row-store таблицах - это значит, что тяжёлый запрос с агрегацией за квартал по миллионам строк честно прочитывает всю таблицу, строка за строкой. Медленно. Заказчик это чувствует, особенно когда отчёт нужен к утреннему совещанию, а генерируется полчаса.

До SP1 разговор был предсказуемый: «хотите быстрее - нужен Enterprise». Enterprise стоит в разы дороже Standard. Для компании с тремя-четырьмя SQL Server-инсталляциями это разговор о серьёзных деньгах, и часто заказчик просто мирился со скоростью.

Теперь у нас появляется другой разговор. Columnstore Index можно добавить к существующей таблице, не меняя структуру данных целиком - non-clustered columnstore index создаётся поверх row-store таблицы. Аналитические запросы начинают использовать его автоматически, через оптимизатор.

Что конкретно планируем переделать

Мы смотрим на несколько отчётных витрин, которые сейчас работают на Standard Edition и имеют характерный профиль: ETL загружает данные ночью, днём идут тяжёлые SELECT с агрегациями, запросы на изменение данных - редкость.

Это почти идеальный сценарий для Columnstore: данные относительно статичные (мало DML), читаются аналитически (агрегации, GROUP BY, широкие диапазоны дат).

Что будем делать после выхода SP1:

• Добавить non-clustered columnstore index на ключевые fact-таблицы. Это не потребует переписывать ETL или менять схему - просто CREATE COLUMNSTORE INDEX.
• Проверить планы запросов - убедиться что оптимизатор действительно идёт через columnstore, а не игнорирует индекс. SET SHOWPLAN_XML / фактический план выполнения в SSMS в помощь.
• Сравнить реальное время до и после на репрезентативных запросах. Без цифр - не считается.
• Посмотреть на сжатие - columnstore-хранение сжимает данные агрессивнее row-store, это влияет на размер файлов данных и на I/O.

Витрины, где идёт активный OLTP поверх тех же таблиц, трогать аккуратнее: columnstore и активный DML - не лучшие друзья, хотя в SQL Server 2016 это стало лучше чем в 2014. Там смотрим отдельно.

Про In-Memory OLTP и Row-Level Security

In-Memory OLTP в Standard открывается с ограничением на объём памяти под in-memory таблицы - цифра пока не финализирована Microsoft до GA SP1. Для наших клиентов это скорее инструмент для очень специфичных горячих таблиц (очереди, счётчики, сессионные данные), а не для массового переезда. Смотрим, но не торопимся.

Row-Level Security - полезная вещь для тех, у кого в одной базе живут данные нескольких организаций или подразделений и нужна гарантия изоляции на уровне движка, не на уровне WHERE в приложении. У нас есть один такой клиент, где это будет уместно. Обсудим после SP1.

Где сейчас

SP1 ещё не вышел - ждём ноября. Но уже сейчас стоит проинвентаризировать: какие инсталляции на Standard, какие там отчётные запросы, и где Columnstore даст реальный эффект. Переговоры с заказчиком по апгрейду до Enterprise - это длинный процесс согласования бюджета. Апгрейд схемы с добавлением нескольких индексов - это другой разговор.

Для DWH и BI-проектов SP1 - это нечастое событие: фича уровня Enterprise приходит в Standard без доплаты. Грех не использовать.