Как стать автором
Обновить

Почему большие БД работают не как хочется, или про несбыточные мечты SQL-запросов

Время на прочтение 11 мин
Количество просмотров 25K
Всего голосов 21: ↑21 и ↓0 +21
Комментарии 24

Комментарии 24

Стоило бы отметить колоночные индексы. То за что я люблю Ms Sql 2014.


В банках кстати покупают обычно Oracle и Oracle Bi, потому что АБС обычно на оракле и пишут. Мол можно бизнес логику перенести!
В качестве Bi инструмента используем Tableua. ну очень хороший Bi инструмент, самый первый !


1.Вопрос каким Bi инструментом пользуетесь?
2.Используете ли Tabular модель хранения, говорят она не умеет масштабироваться?
3.Используете ли партиции для более эффективного расчета ??
4.Как Масштабируетесь?
5.Расскажите еще че нить интересное :)


Ms поглотил DATAZEN и внедрил наработки в SSRS 2016, там тоже много нового и интересного !

Для построения BI мы используем стек от Microsoft. SQL Server для БД, SSAS для кубов,
отчеты и API — на SSRS или ASP, и т.д.

Tabular сейчас в продакшене не используем.

Партиции в кубах — используем, но с ними есть свои особенности при росте объемов.

А про масштабирование — в двух словах не расскажешь, планируем в следующих статьях осветить эту тему более подробно.
QlikView как минимум не хуже Tableau, а ассоциативный анализ вообще крут. Впрочем, всех съест MS Power BI всё равно равно или поздно. :)
Почему минутные запросы могут работать час

Я бы еще добавил ссылку на отличный пост от Дмитрия Пилюгина: Медленно в приложении, быстро в SSMS… про parameter sniffing и не только. А так пост годный, прочитал с удовольствием.

Отличная идея, спасибо, добавили

Приветствую! Поглядите, пожалуйста, мой вопрос хоть и не вам, но вы думаю в курсе :) Он вот тут. Т.к. автор слился, а прояснить хочется — поэтому вопрошаю к вам! Если конечно не затруднит!
Привет!

Существенное изменение плана выполнения запроса как правило подразумевает,
что запросы будут выполнятся медленее, так же могут увеличиться обращения к диску, потребление памяти, процессора.
Полагаю, что при таких требованиях от производителя ПО, в БД уже созданы все необходимые статистики и реализован штатный механизм их обннолвения.
в БД уже созданы все необходимые статистики и реализован штатный механизм их обннолвения.

Ого :) Я думал статистику всегда собирает и актуализирует сам MS SQL. Мне просто не до конца ясно, зачем штатный механизм (ы) отключаются, а все это, насколько я понял, реализуется скриптами в самом ПО? Т.е. зачем нужны эти лишние телодвижения, никак не пойму!
Так и есть, по умолчанию, статистики создаются и обновляются автоматически.
Но автоматику можно отключить, создать все вручную, использовать хинты (подсказки) в запросах и обеспечивать тем самым оптимальные планы не полагаясь на автоматику.
Которая не редко дает сбои, о чем пишут множество статей, включая эту: )
Вопрос а если таблица большая но статичная что будет если обновить статистику и отключить ее для данной таблицы?
Отключение авто-обновлений статистик производится на уровне БД.
Если другие таблицы в БД обновляются, делать этого не стоит.
В статичной таблице статистики обновляться не будут т.к. нет необходимости.

Идея о разовом обновлении статистик конкретной статичной таблицы вполне здравая.
Сделать это на таблице можно таким запросом — update statistics TableName with resample

Есть так же неплохая команда EXEC sp_updatestats;
Она анализирует необходимость обновления статистик и обновляет только те, для которых это необхходимо.
Применяется ко всем таблицам и их статистикам внутри БД в которой она запущена.
Спасибо. Но как же вот это NORECOMPUTE или я что то не догоняю
UPDATE STATISTICS '+@tablename+' WITH FULLSCAN, NORECOMPUTE

Отключить параметр автоматического обновления статистики AUTO_UPDATE_STATISTICS для указанной статистики. Если указан этот параметр, оптимизатор запросов завершает текущее обновление статистики и отключает обновление в будущем.
Чтобы возобновить действие параметра AUTO_UPDATE_STATISTICS, снова выполните инструкцию UPDATE STATISTICS без параметра NORECOMPUTE или выполните процедуру sp_autostats.
Пардон, да, вы правы.
Такую штуку на практике никогда не использовал, для статичной таблицы профит вероятно будет. Особенно если там высокая OLTP нагрузка.
Можно ли еще пару вопросов
1 используете ли вы партитирование
2 и используете ли вы sql clr
Партиционирование используем в паре таблиц, там где требуется их чистить.

SQL CLR используем
тут с sqlclr есть момент неприятный в них можно делать только небольшие вычисления. Если вдруг в ней начинает использоваться (распределятся) много памяти — все считайте тормоза.
какой клиент используют аналитики для работы с OLAP-кубами? разрабатываете ли MDX-запросы, или их генерирует клиентское приложение?
Привет!

В качестве клиента используется привычный всем MS Excel, он же и генерирует все MDX запросы к кубам.
А кроме Excel — к кубам ходят некоторые отчеты и API, вот там MDX разрабатываем.
Никогда бы не подумал, что в Яндексе используется MS SQL Server! :)
Поверьте очень неплохая система! Особенно версия по linux! По производительности удобству разработки отладки даст фору ораклу. Был опыт в разработки системы с которой оракл не справился а sql проглотил за милую душу. Размерчик так себе в оракле за 20 ТБ далеко :(
Я-то знаю, что хорошая, много лет работаю. Просто Яндекс с его обычно open source ландшафтом и продуктами с MS SQL у меня как-то воообще не ассоциировался.

И как, Linux версия правда работает? В продуктив уже можно?
Ну у нас полгода работает на критически важном сервисе
из минусов usafe clr не будут пока работать
Одни сплошные +
очень хочется ин мемори функуии и процедуры чтобы расширили сплтами дистинктом (count distict не пашет
И update from тоже пока не реализовали. а так все инмемори лежит в си-шных длл вот думаю будет время разберусь похоже там много чего можно наковырять интересного

Да и производительность процентов на 30 выше
Зарегистрируйтесь на Хабре , чтобы оставить комментарий