6/10/2009 3:33:34 PM

По поводу той базы данных, где таблица из тысячи колонок. Приходил полевой инженер по SQL Server из Майкрософт. Полтора дня работали с ним плотненько над этой проблемой. В результате наоптимизировали: та выборка, которая занимала 1 минуту 23 секунды сейчас выполняется за 800 милисекунд. Остальные, требовавшие раньше в районе секунды, делаются за 1-2 милисекунды.
Very impressed, что называется!

Запросы, конечно, другие стали. Несколько изменились даже их принципы. Таблицу с тысячей колонок практически не трогали, денормализовали еще больше, добавив еще одно поле, но избавившись от еще одного join’а.

Ну и, конечно, на таком уровне разбираться в SQL Server – надо много поучиться. Человек просто смотрит на запрос – и говорит: “тут у тебя индекс работать не будет, как ни строй, потому, что при таком объеме выборки количество уровней будет где-то 4, а значит ему нужно просканировать столько-то страниц. В любом случае это быстрее, чем делать полный индекс скан”. Или “вот тут у нас join с ограничивающим условием, это условие только вредит, так как в этом случае сервер сформирует суперсет, исключит то, что там в условии, но потом вынужден будет вернуть данные для построения окончательной выборки и выбросить их снова, двойная работа”. Или “тут индекс, конечно, используется, но вот тут используется еще один, а значит ему надо делать два поиска по индексам, поэтому план будет неинтересным, построим другой индекс”, строит – и план становится действительно куда более приятным.

Посоветовал пару книжек почитать.
Рассказал, как работается в Майкрософт. Интересно. Прессинг, говорит, существенный, но не со стороны менеджеров, а со стороны самого себя. Потому, что работая “в поле” сталкиваешься с очень разнообразными задачами и приходится постоянно читать тонны документации, общей и внутренней. Со стороны руководства, говорит, в МС не принято никакого давления. Типа, допустим, я не смогу решить вашу проблему за два дня. Дам рекомендации, уйду. Со стороны руководства это будет означать, что для решения проблемы двух дней просто мало. Никто никогда не скажет: “эх ты”, не отругает за “невыполнение” и т.д.
И это еще больше увеличивает self-прессинг. Прихожу, говорит, иногда домой после рабочего дня со сложной проблемой – и еще часов до 10 вечера, а то и дольше, ковыряюсь, разбираюсь – как же так и что же не так.
Еще интереснее: поскольку “полевых” инженеров не хватает на всех желающих, они могут сами решать, к какому клиенту отправиться и сколько времени они могут потратить на этого клиента. Нет такого, чтобы пришел начальник и сказал: “завтра ты весь день там-то, послезавтра полдня тут и полдня в офисе, на понедельник я тебе позже скажу”.

Интересно. Хотя я читал, что в МС подобного рода само-прессинг – явление распространённое. Потом привыкается, говорят.

Завтра иду на ReMix Australia. Даже в качестве делегата :) Будем представлять достаточно большую линейку продуктов. Должно быть интересно – я даже не все видел :)

P.S. А книжки почитать надо.

Comments

6/10/2009 10:15:43 PM

Artem

А что за книжки, если не секрет? Smile

Artem Russia

6/11/2009 1:51:25 PM

Alexey Raga

Не секрет. На работе записаны названия. На следующей неделе отпишусь, если не забуду Smile

Alexey Raga Australia

6/11/2009 4:05:54 PM

Vitalii

А как соптимизировали запросы типа
SELECT [Id], [Name], [nVarchar1], [Integer1], [XmlData1], [XmlData3] FROM [Message].[Messages] WHERE TypeID = 3765
Интересно решение, как изменили запрос/индекс, если саму табличку не трогали?

Vitalii

6/12/2009 3:08:48 AM

Alexey Raga

Тут-то всё просто: индекс на TypeID, с этим понятно.
Проблемы начинались, когда в WHERE появлялись эти самые nVarchar22 и прочие, причем нужно же было делать paging по всему этому, а это означает ROW_NUMBER() OVER(...), где "..." - это критерий сортировки, который тоже какой-нибудь DateTime15.
Вот тут начинались тормоза.

Частично решение: построение некластерных filtered indexes по не текстовым sparse columns (даты, числа, время) и использование полнотекстового поиска для текстовых и XML-колонок.
Этого хватает, если нет Join'ов в запросе.
Если есть Join'ы, то объем join'ящейся информации приходится ограничивать, скажем, 10000 строк (после фильтра), что существенно увеличивает скорость запроса и не ограничивает пользователя: 10000 строк по 50 записей на странице - это 200 страниц поиска, никто так далеко листать не станет, проще уточнить запрос.

Alexey Raga

Comments are closed

Powered by BlogEngine.NET 1.6.0.0

About the author

Alexey Raga Alexey Raga
.NET software developer.

E-mail me Send mail

Twitter


Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010

Sign in