Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
Здравствуйте!

Вот, два достаточно тривиальных запроса:
SELECT TRACK_ID, NODE, MIN(EVENT_TIME) RECEIVE_TIME
FROM [dbo].[PROTOCOLS]
GROUP BY TRACK_ID, NODE

SELECT TRACK_ID, NODE, MIN(EVENT_TIME) RECEIVE_TIME
FROM [dbo].[PROTOCOLS] WITH(INDEX=[NonClusteredColumnStoreIndex-20130718-124508])
GROUP BY TRACK_ID, NODE

С точки зрения планировщика первый запрос с обычным индексом почему-то быстрее, чем с колоночным. В колоночном индексе есть все 3 поля + некоторые другие.

Почему так??? Зачем во втором плане Hash Match?

К сообщению приложен файл. Размер - 27Kb
18 июл 13, 16:26    [14585024]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
GROUP BY
Guest
Ares_ekb
Почему так??? Зачем во втором плане Hash Match?

ибо
GROUP BY TRACK_ID, NODE


во первом случае, насколько я понял (русифицированная ssms это что-то), есть индекс подходящий для stream aggregate
18 июл 13, 16:30    [14585068]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
GROUP BY,

почему первый план такой более-менее понятно... Но почему второй хуже? Мне же обещали, что Columnstore-индексы повысят производительность в разы! :)
18 июл 13, 16:44    [14585185]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
GROUP BY
Guest
Ares_ekb
Но почему второй хуже?

я бы сделал выборку на живых данных первым и вторым способом и посмотрел бы IO и Time статистику, может не так уж и плох второй план.


Ares_ekb
Мне же обещали, что Columnstore-индексы повысят производительность в разы! :)

этот вопрос лучше задать обещавшим

Columnstore - это не более чем новый тип индекса, который имеет свои плюсы и минусы. Если бы не было минусов то все все все индексы заменили бы на него и жили припеваючи.
18 июл 13, 16:57    [14585259]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ares_ekb,

Не быстрее, а дешевле.
Оптимизатор учел ваше число строк, и руководствуясь моделью оценки (зашитыми коэффициентами и формулами) посчитал стоимость плана. Вы форсировали индекс, убедились что оптимизатор действительно считает план с cs индексом более дорогим.
Если число строк изменится, оптимизатор может выбрать другой индекс.

Не нужно напрямую связывать стоимость и "быстро/медленно", стоимость вычисляется на основе модели, которая не может полностью отражать реальность, на то и называется модель. Если текущая модель вас не устраивает и вы считаете, что стоимость второго плана при заданных условиях и количестве строк должна быть меньше, то оставляйте подсказку, это будет означать, что вы в данном случае знаете лучше оптимизатора, какой индекс использовать.
18 июл 13, 17:24    [14585428]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35390
Блог
для начала нужно посмотреть, в каком режиме работает columnstore-индекс

наведите "прицел" на него в плане запроса
18 июл 13, 17:34    [14585509]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
GROUP BY,

обычный индекс
(строк обработано: 988614)
Таблица "PROTOCOLS". Число просмотров 1, логических чтений 41618, физических чтений 2, упреждающих чтений 41614, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 52234 мс, затраченное время = 73902 мс.
columnstore
(строк обработано: 988614)
Таблица "PROTOCOLS". Число просмотров 4, логических чтений 16898, физических чтений 21, упреждающих чтений 54483, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Таблица "Worktable". Число просмотров 0, логических чтений 0, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 33828 мс, затраченное время = 74854 мс.

На горячую:
обычный индекс
(строк обработано: 988614)
Таблица "PROTOCOLS". Число просмотров 1, логических чтений 41618, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 50484 мс, затраченное время = 69530 мс.
columnstore
(строк обработано: 988614)
Таблица "PROTOCOLS". Число просмотров 4, логических чтений 16852, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Таблица "Worktable". Число просмотров 0, логических чтений 0, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 32718 мс, затраченное время = 69961 мс.

Непонятно как это интерпретировать. Типа данных читается при использовании columnstore меньше, но зато приходится просматривать индекс 4 раза... А почему он просматривает их 4 раза и почему генерит такой сложный план?.. Поле TRACK_ID типа char(36), может в этом причина...

К сообщению приложен файл (columnstore.sqlplan - 34Kb) cкачать
18 июл 13, 19:20    [14585995]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
Критик,

вот:

К сообщению приложен файл. Размер - 21Kb
18 июл 13, 19:25    [14586008]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ares_ekb
но зато приходится просматривать индекс 4 раза... А почему он просматривает их 4 раза

У вас ведь с CS параллельный план. 4 - это не значит, что индекс целиком просматривается каждым потоком. Попробуйте поставить option(maxdop 2) и посмотреть на scan count.

Ares_ekb
почему генерит такой сложный план?.. Поле TRACK_ID типа char(36), может в этом причина...

Что именно кажется сложным?
Картинка с другого сайта.

74 секунды - это очень много для 6 миллионов даже для обычного индекса. У вас результат запроса 987674 строки, подозреваю, что вы все их гоните на клиент и все это время попадает в статистику ожидания. Попробуйте повторить тесты записывая в локальные переменные, чтоб исключить время передачи.
Типа такого
declare @a ..., @b ..., @c ...;
SELECT @a = TRACK_ID, @b = NODE, @c = MIN(EVENT_TIME)
FROM [dbo].[PROTOCOLS] WITH(INDEX=[NonClusteredColumnStoreIndex-20130718-124508])
GROUP BY TRACK_ID, NODE


В целом, CS индекс дает выигрыш за счет, доступа только к нужным колонкам, сжатию и режиму обработки батч.
Выгоден на широких больших таблицах, и запросах, которые молотят много данных, но на выходе имеют относительно небольшое число строк, по сравнению с исходным.
18 июл 13, 21:19    [14586308]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35390
Блог
а сколько процессорных ядер выделено серверу?
19 июл 13, 00:28    [14586968]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
SomewhereSomehow,

спасибо за подробное объяснение! Я прочитал несколько статей на эту тему и кажется начал что-то понимать. Второй план не такой сложный, а просто распараллеленный. И это же объясняет почему время ЦП больше общего затраченного времени - используется несколько ЦП, и их время суммируется. И scan count при maxdop(2) стал равен 2-ум!

Только не понятно, почему фактическое время в этих запросах отличается достаточно сильно, а планы по стоимости практически идентичные...
обычный индекс
Таблица "PROTOCOLS". Число просмотров 1, логических чтений 53807, физических чтений 3, упреждающих чтений 53798, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Время ЦП = 51328 мс, затраченное время = 56847 мс.
columnstore
Таблица "PROTOCOLS". Число просмотров 4, логических чтений 17164, физических чтений 21, упреждающих чтений 56157, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Таблица "Worktable". Число просмотров 0, логических чтений 0, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Время ЦП = 27127 мс, затраченное время = 10576 мс.
columnstore maxdop(2)
Таблица "PROTOCOLS". Число просмотров 2, логических чтений 17162, физических чтений 21, упреждающих чтений 56151, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Таблица "Worktable". Число просмотров 0, логических чтений 0, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Время ЦП = 38937 мс, затраченное время = 21825 мс.

И, кстати, из OLTP загрузилось немного данных, и теперь чуток выигрывает план с columnstore!

К сообщению приложен файл (columnstore2.sqlplan - 76Kb) cкачать
19 июл 13, 14:01    [14589751]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1616
Критик,

судя по всему, все 4. Но это виртуалка и не слишком быстрая. Админы говорят, что при выделении большего количества ядер тормоза, как правило, усиливаются. Возможно, это тоже на чем-то сказывается...
19 июл 13, 14:04    [14589770]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
GROUP BY
Guest
Ares_ekb
Только не понятно, почему фактическое время в этих запросах отличается достаточно сильно, а планы по стоимости практически идентичные...
вам же уже ответили
SomewhereSomehow
Не быстрее, а дешевле.


стоимость в плане - это не время выполнения запроса, а оценочное количество ресурсов (IO/CPU) которое будет на него затрачено
19 июл 13, 14:38    [14590058]     Ответить | Цитировать Сообщить модератору
 Re: Columnstore index при группировке почему-то не выбирается планировщиком  [new]
Crimean
Member

Откуда:
Сообщений: 13147
на правах комментария - очень часто чем запрос быстрее, тем он "дороже" в смысле той самой "стоимости". но это, вроде как, логично же?
19 июл 13, 17:43    [14591231]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить