(Возврат на основную страницу)
Скептики, которые ставят под сомнение решение Microsoft интегрировать .NET CLR с SQL Server 2005, стремятся использовать язык провидцев наподобие Иеремии и Кассандры, чтобы отстоять свою точку зрения. Они верят, что помещение CLR внутрь процесса — крайне плохая идея, которая может подвергнуть опасности расширяемость и надежность SQL Server. Такие разговоры легко пресечь, но стоит понять, за что же сражаются эти ребята.
Скептики говорят, что в самой глубине этой проблемы лежат большие различия парадигм, на которых базируются языки для среды .NET, такие как C#, Visual Basic .NET и применяемый в SQL Server язык TransactSQL. Языки CLR по своей природе являются процедурными, в то время как TSQL в большой степени относится к основанным на множествах языкам. То, что работает с одними, не обязательно будет взаимодействовать с другими. И хотя можно использовать основанные на множествах языки для выполнения задач вне реляционного мира, делать это часто не рекомендуют. Это верно и для применения процедурных языков в реляционном пространстве.
«В процедурном кодировании вы срываете банк и начинаете пересчитывать пенни по штучке, — говорит консультант по SQL Джо Селко, автор оригинального стиля программирования на SQL. — В базирующемся же на множествах кодировании вы срываете банк и взвешиваете всю кучу пенни как одно целое».
Грэм Малькольм, профессионал SQL Server и Content Master, приводит такой пример. Предположим, что пользователю нужно быстро решить широко распространенную в бизнесе задачу — выяснить, кто из клиентов делал заказы за последние два месяца. Малькольм предлагает подумать об этом в терминах диаграмм Вьенна. Тогда один круг будет содержать всех клиентов, а другой — заказы. «Пересечение кругов будет представлять тех клиентов, которые сделали заказы за последние два месяца. По существу, диаграмма Вьенна является визуальным представлением операций с множествами, в частности пересечения множества клиентов с множеством заказов».
По словам Малькольма, в TSQL это можно делать с завязанными глазами. «Чтобы решить ту же самую задачу только средствами процедурного языка, вам бы пришлось: взять первого клиента и найти его первый заказ; проверить дату; если дата попадает в последние два месяца, поместить клиента в результирующий список; в противном случае найти его следующий заказ и повторить все снова, пока не будет найден заказ, относящийся к последним двум месяцам, либо пока не будут исчерпаны заказы этого клиента. Теперь можно перейти к следующему клиенту».
Так что же доводит программистов на SQL до апоплексического удара? То, что, по их словам, незнакомые с TSQL программисты предпочтут пользоваться процедурными языками, даже если ясно, что это далеко не лучшая идея.
В результате раздутые коды и другие побочные эффекты процедурных языков серьезно повредят производительности и надежности баз данных SQL. «Эти ребята уже пишут курсоры, потому что они не понимают декларативного, ориентированного на множества программирования. Так почему они вдруг перестанут это делать, если есть языки, которые не поддерживают операции с множествами? — спрашивает Селко. — И хуже того, они решат, что их родной язык универсален, и примутся модифицировать данные по своим правилам. Фукции MOD() не одинаковы в разных языках. C# и VB не пришли к соглашению, что использовать для булевых значений — (0,+1) или (0, 1). Это еще больше все запутывает».
Я уверен, что CLR — это потрясающая вещь, и полагаю, что его противники абсолютно правы в том, что CLR в большой степени будет использоваться неправильно. Архитекторы баз данных резко отличаются от непосредственных разработчиков тем, что они думают множествами, а не ориентируются на атомарные задачи. Я испытал это сам и убеждаюсь снова и снова, наблюдая за действиями других разработчиков. При необходимости выбрать между ориентированным на множества оператором SQL или процедурой они непременно склонятся к загрузке данных в набор записей (в терминологии ADO) и будут «курсировать» по записям. Для разработчика сумма означает, что следует прокатиться по всему множеству записей, суммируя их пункты. Человек, мыслящий категориями SQL, напишет как можно больше на SQL, воспользовавшись функцией суммирования в операторе выборки. Так как же лучше поступить? Оба правы и неправы одновременно. Ведь надо не стремится к тому, чтобы написать все на одном языке, а думать об архитектуре всего приложения. Чтото такое же простое, как упомянутую выше сумму, конечно же, следует решить средствами SQL. Однако если у вас возникнет искушение воспользоваться курсором SQL, еще раз подумайте о его влиянии на сервер SQL и напишите сложную логику обработки в коде промежуточного слоя приложения. Это заставит дорогой сервер SQL лучше выполнять то, что он делает, и не придется наращивать его до 8процессорной конфигурации изза плохо продуманной архитектуры. Архитектору необходимо легко перенести этот код в отдельный слой. CLR нужно использовать строго для выполнения тех функций, с которыми не справится SQL, и именно так следует проектировать любую архитектуру, достойную рассмотрения. Сложные типы данных и манипулирующие ими функции представляют собой пример применения CLR, где он даст грандиозный эффект. Так, PostgreSQL предлагает геометрические типы данных наподобие точек, линий и многоугольников, которыми оперируют операторы SQL. Это приведет к тому, что запросы будут использовать медленные пользовательские SQLфункции. CLR позволит ввести такие функциональные возможности для улучшения производительности сервера SQL.
Этот мир становится все более недружелюбным для баз данных и клиентских приложений. Каждый день нападающие готовят хитроумные атаки для компрометации наших ценных данных. К счастью, SQL Server 2005 обладает новыми усиленными средствами обеспечения безопасности, в которые напрямую заложены такие принципы, как глубокая оборона и минимальные привилегии. Как объясняется в документации, корпорация Microsoft реализовала ряд новшеств системы безопасности, которые включают уменьшение площади атак и упрощение безопасного развертывания SQL Server и баз данных, в то же время предлагая гораздо более защищенный инструментарий и документы о поддержании высокой защищенности в меняющейся панораме средств безопасности.
В этой статье я проанализирую наиболее интересные усовершенствования безопасности в SQL Server 2005 с точки зрения разработчика. Сконцентрируемся только на механизме реляционных баз данных. Поддержка таких систем, как служба отчетов, аналитическая служба и прочих, обладающих собственной инфраструктурой безопасности, заслуживает отдельного исследования, адекватно раскрывающего их возможности.
Называйте это, как хотите, — вопросами качества данных, грязными данными или проблемой пропущенных данных, — эта проблема реальна и затрагивает каждого администратора баз данных. Посмотрите, как Шридхар Баласубраманиам подошел к проблеме «дыр».
Непрерывность важна. Работодатель ищет кандидата с непрерывным послужным списком. Когда вы берете ссуду на покупку дома, правила могут в качестве особого условия оговаривать непрерывную занятость в течение двух лет. Недавно в одном приложении я должен был устранить повреждения таблицы с «дырами», и в этой статье я имитировал этот опыт. Демонстрационная таблица loan_history (листинг 1 и табл. 1) хранит информацию о ссудах за некоторый диапазон дат. Данные в эту таблицу я импортировал из внешнего источника с применением подходящих фильтров, а заданная дата всегда попадает в один и только в один диапазон. Однако, когда пользователи читали определенные отчеты, в некоторых диапазонах дат отсутствовали сведения об изрядном количестве ссуд. К примеру, в табл. 1 нет данных за период с 6/21/03 по 6/22/03, соответствующих идентификаторам 3 и 4 для ссуды 100. Бизнес требовал от меня: 1) идентифицировать ссуды, у которых имелись «дыры», 2) «урезать» данные для улучшения производительности.
Используя подход с примением checksum — и тем самым избегая преобразований IsNull, — я смог уменьшить размер таблицы с 2,2 миллиона записей до 1,5 миллионов. Сокращение составило 70 000 строк. Полагаю, что полученный урок заключается в том, насколька важно использовать столбцы идентификаторов и агрегирующие функции. В моем случае запрос на идентификацию ссуд, у которых имеются пробелы, выполнялся всего 10 секунд для таблицы с 2,2 миллиона записей (и первичным ключом to_date, loan#), тогда как запрос на определение checksum и уникальных checksum занял только около минуты.
Пожалуйста, обратите внимание, что в приведенном в Books Online определении CHECKSUM имеется небольшая оговорка: «Если одно из значений в списке выражений меняется, то значение checksum для списка тоже обычно меняется. Однако есть малая вероятность того, что этого не произойдет». Не знаю, как вас, а меня очень раздражает эта «малая вероятность». Я не уверен, что это не одно из стандартных «антитребований» Microsoft. И хотя до сих пор у меня не возникло проблем, мне очень хочется знать, были ли затруднения у коголибо из вас. Буду также признателен, если ктото найдет изъяны в этом методе или поделится идеями его усовершенствования.
См. Эрланд Соммарског. Массивы и списки в SQL Server. Часть 1. // SQL Server для профессионалов. 2005. № 10.
Мы продолжаем обзор методов работы с массивами в SQL Server. В этой части статьи также представлены сводные данные об их производительности.
На днях я был у Энди, когда зазвонил его Blackberry. Поскольку в выходные это происходит по 4 раза в час, мы не удивились, но он продолжал надрываться в течение 10 минут. Оказалось, что в работе SQL Server возникли проблемы. У меня было немного свободного времени, и я отправился в офис, чтобы помочь разобраться в причинах проблемы.
Мы обнаружили запрос, который обычно выполняется за секунды, а сейчас ему требовались минуты. Такое случалось и раньше, и вернуть производительность на прежний уровень можно было с помощью разнообразных продвинутых экспертных методик. Обычно они включали перезагрузку, покрикивание на сервер и даже несильный пинок по стойке сервера.
На самом деле причина была в безобразной хранимой процедуре всего из нескольких строк, но самая большая из них представляла собой левое соединение с таблицей, содержащей 35 миллионов записей. Несмотря на размеры таблицы и левое соединение, а в действительности это 3 левых соединения, запрос обычно выполняется с 7000 операций чтения.
Поэтому мы запустили Query Analyser и проверили сервер. Мы увидели различные исполнения этой хранимой процедуры, возвращавшиеся с 150 000+ операций чтения и более. И с 50 000+ миллисекунд работы центрального процессора. Это вызвало панику у бизнеспользователей, которые обнаруживают, что их приложению требуются минуты, чтобы вытянуть экран.
Сервер был очень сильным. Это был 8процессорный ящик с 8 Гб оперативной памяти, который обычно легко справлялся с нагрузкой. Но тогда запросы обрабатывались медленно, среднее значение коэффициента использования процессора составляло 95%, и все шло не так. Мы проверили планы исполнения запросов и увидели, что возмутительно большая часть хранимой процедуры уходила на сканирование индекса, съедая более 80% времени выполнения запроса.
Ничего не менялось, и в то самое утро она работала впервые, но по какойто причине план исполнения запроса изменился. Мы попробовали разные приемы, но в конце концов Энди вернулся к прежней версии этой хранимой процедуры, возвращавшей те же самые значения, но структурированной немного иначе — с временными таблицами и разбиением запроса на несколько частей. Назад к 11 000 операций чтения, но это же гораздо лучше, чем 100 000+ операций чтения.
В то же время мы заметили другую хранимую процедуру, которая вызывалась с сервера и которой требовались 900 000 операций чтения. Энди запихнул ее в Query Analyzer и запустил, получив в результате 50000 операций чтения и намного меньшее время выполнения. Я предположил, что в сложной хранимой процедуре ведутся проверки безопасности, поэтому мы попробовали запустить ее от имени учетной записи сервера, и все же получили из Query Analyzer намного лучшую производительность. Поскольку она не вызывала больших проблем, мы оставили ее в покое.
Оба этих случая относятся к примерам странного поведения, вопросы о которых я слышал и с которыми сталкивался лично. Кажется, нет никаких разумных причин такого поведения. Поэтому мы решили обратиться к истокам и просить помощи.
(Возврат на основную страницу)