(Возврат на основную страницу)
Узнайте о будущем SQL Server 2000 и предельных случаях масштабирования от эксперта Microsoft по большим базам данных.
Интервью взял Ли Тэ (Lee The) 1 февраля 2002 г.
Джим Грей (Jim Gray) сыграл ключевую роль в построении TerraServer, 12-терабайтного хранилища данных, содержащего снимки земной поверхности и использующего в качестве строительных блоков Microsoft SQL Server 2000. Web-узел TerraServer посещают в среднем 7 миллионов раз в день. Джиму Грею нравятся проекты такого рода. Он основал Bay Area Research Center (BARC) корпорации Microsoft и управляет им. Это исследовательская лаборатория, уделяющая основное внимание масштабируемым вычислениям путем построения суперсерверов и групповых систем из доступного на рынке аппаратного и программного обеспечения. Кроме того, эти модульные системы обладают встроенной отказоустойчивостью и могут в случае сбоя функционировать в течение длительного времени.
ЛТ: Как грядущая интеграция .NET и SQL Server повлияет на производительность, использование SQL Server в качестве источника данных для Web-сервисов и другие моменты? И как она будет осуществляться? Обязательно ли SQL Server станет узлом .NET? Или он просто подключит пространства имен и классы?
ДГ: Интеграция SQL Server с .NET — это огромное продвижение вперед. Это следующий этап после OLE DB — интеграции объектов с базами данных. SQL Server становится интегратором данных, способом работы с наборами объектов. Мы мчимся за объектно-ориентированной радугой и приближаемся к горшочку с золотом — расширяемой БД. Теперь мы сможем хранить объекты в БД и рассматривать базы данных как объекты. Производительность даже повысится за счет использования компилируемых языков вместо интерпретируемого T-SQL. А хранимые процедуры теперь станут объектами высшего сорта.
ЛТ: Похоже, SQL Server все больше и больше начинает брать на себя роль статического хранилища всевозможных типов данных. Вы можете предсказать, какие типы хранилищ данных заменит SQL Server? Реестр? Файловые службы? Хранилища электронной почты?
ДГ: Да, Oracle, DB2 и SQL Server движутся в направлении хранения «файлов»: фото, видео, голосовой и электронной почты, документов и многого другого. Интеграция SQL Server с объектной системой (.NET) делает эту возможность очень привлекательной. Microsoft давно нацеливалась на нее. Для людей, работающих с базами данных, это естественная эволюция. Другим она кажется неестественной. Имеет место конкуренция — каждый лагерь предлагает свой способ решения проблем. Нет сомнений, что конечный результат будет синтезом всех этих идей. Но, я думаю, все мы согласны, что управление хранением данных должно быть более легким и автоматизированным. У всех нас общая цель, и единственное, что стоит обсуждать, — как ее достичь.
ЛТ: Как современные СУБД решают проблему различия между реляционными БД и нереляционными данными, например, XML? Какие нововведения появились на горизонте в обеспечении прозрачности доступа к иерархическим и нереляционным данным? Что нового в отношении производительности и масштабируемости обработки нереляционных данных?
ДГ: Для решения проблемы различия реляционных и нереляционных данных сделано многое. SQL — язык, ориентированный на множества, а Cobol, C, Java, C# ориентированы на итерации (одну запись за раз, пожалуйста!). Языки программирования имеют богатые системы типов, в то время как БД — бедные. Платформа .NET все это изменит. База данных является Web-сервисом. Система типов универсальна. Можно добавлять БД к типам и наоборот. Больше нет понятий «внутри» и «снаружи» — БД находится и выше, и ниже системы типов. XQuery позволяет SQL работать с деревьями и графами, унифицируя SQL и XPath. Эта история еще не окончена, но XQuery на данный момент является лучшим вариантом. Мы пока еще изучаем, как обрабатывать данные в формате XML — разбить их на мелкие порции («нашинковать»), поместить в BLOb-поля или выбрать нечто среднее? Наиболее вероятный ответ — нечто среднее…
ЛТ: Каковы ваши предсказания относительно будущего SQL Server Analysis Services в деловом мире, судьбы OLAP (аналитической обработки в реальном времени), добычи данных и вообще интеллектуального начала в бизнесе? Достаточно ли усилий прилагает Microsoft, чтобы проповедовать полезность этих технологий для промышленности? Что мешает им стать основным и привычным направлением? Поможет ли в этом отношении новая программа Microsoft Data Analyzer?
ДГ: Data Analyzer поможет Analysis Services как в OLAP, так и в добыче данных. Один из аспектов SQL Server состоит в том, что каждый получает все. Не требуется платить по отдельности за тиражирование, OLAP, Data Mining или English Query. Так что факт, что эти возможности широко используются, не так уж очевиден. Я бы сказал, что каждая из этих возможностей используется очень широко. Когда я посещаю встречи групп пользователей или слежу за дискуссионными группами, я вижу огромный интерес и большое количество новых идей в этих областях. Мне представляется, что основная эволюция заключается в том, что люди, которые создавали при помощи SQL Server системы для работы, затем начали строить вспомогательные системы поддержки принятия решений, использующие данные этих систем. Большинство таких вспомогательных систем создано с помощью Analysis Services. Не сказал бы, что это основное направление, но интегрированные системы и инструменты облегчают построение этих аналитических систем. Это приемлемый метод работы.
ЛТ: Вы можете представить, что возрастет востребованность технологий Microsoft среди академических ученых-компьютерщиков? Считаете ли вы, что повсеместное использование Unix в академическом мире препятствует успеху Microsoft в деловом мире?
ДГ: Все мои академические друзья используют систему Windows для создания презентаций PowerPoint. Но во многих случаях они имеют также компьютер с Solaris или Linux, используемый для программирования. Конечно, для Microsoft было бы лучше, чтобы все использовали только ее продукцию, но этого никогда не произойдет. Обеспечение гетерогенности проекта SkyServer отняло у нас много энергии. Мы должны поддерживать Netscape 4 — 6 и Opera. Все клиентские инструменты должны работать в Linux. Это значительно усложняет разработку приложений, но это реальность. Microsoft действительно добивается прогресса в академическом мире, и это во многом связано с использующими наши инструменты людьми. Академические специалисты сейчас работают над языками, подобными Eiffel, чтобы сделать их совместимыми с нашей технологией .NET, так как Visual Studio .NET — великолепная среда для любого языка программирования. Преимущество для сотрудников и студентов академий состоит в том, что они получают мощную и удобную среду, содержащую отладчик и интегрированную справочную систему, обладающую большими возможностями редактирования и многими другими достоинствами.
ЛТ: Что вы скажете о будущем TerraServer? Продолжит ли Microsoft расширять покрытие Земли? Превратятся ли терабайты данных в петабайты? (Петабайтов нет даже в словаре Microsoft Word.)
ДГ: TerraServer существует пять лет. Он стал частью узла HomeAdvisor, и сотрудники HomeAdvisor неплохо поработали над его интеграцией с демографическими данными о наших соседях. Он продолжает входить в 1000 наиболее популярных Web-узлов, что просто поразительно! Он также является рекламой больших БД, построенных на SQL Server (12 TB) и кластеризации (кластер из 4x8 Compaq Windows Data Center). Кроме того, с точки зрения перспектив .NET, TerraServer превращен в Web-сервис, который является великолепным прототипом для любого, кто интересуется построением Web-сервисов, использующих изображения. Если вы еще его не посещали, обязательно сделайте это.
ЛТ: Какой уровень детализации обеспечивает SkyServer? Как можно связать данные такого вида, помещенные в единое хранилище, чтобы астрономы могли совершать открытия? Чему в проекте уделено основное внимание? Какой источник данных используется, какие преобразования производятся? Играют ли какую-нибудь роль Analysis Services?
ДГ: SkyServer подобен TerraServer, но выглядит по-другому. Он содержит изображение северного неба размером 0.25 арксекунд. В данный момент оно неполное, но мы работаем в этом направлении. Кроме пиксельных данных в БД содержится около 200 миллионов галактик и около миллиона спектров. Это непростая задача для Data Mining. Пока что мы используем чистый SQL, но также экспериментируем с кубами и Data Mining. Основное внимание в проекте уделяется изучению структуры ранней вселенной, вычислению космологических констант с повышенной десятичной точностью и, возможно, изучению темной материи (которая составляет 95% материи вселенной). Теперь, когда SkyServer работает, мы преобразовываем его в Web-сервис и работаем над объединением его с другими астрономическими архивами, чтобы сделать из Интернета Всемирный Телескоп. Я затрачиваю больше всего энергии именно на этот момент. Это очень хорошая проверка концепции Web-сервисов.
ЛТ: Какими вы видите базы данных следующего десятилетия? Какие действия станут производить над данными в будущем?
ДГ: Когда тома данных становятся огромными, вы не можете их быстро просмотреть и приходится использовать индекс. Значит, требуется определенный тип БД. Моя группа исследовала вопрос, как лучше поступить — поместить в БД всю информацию или только индексы. В результате обнаружил, что намного легче помещать в БД все: фото, видео, изображения, и, конечно, текст. Иногда это просто BLOb-данные, но часто требуется «разбирать» данные и, насколько возможно, извлекать из них метаинформацию. Допустим, мы создаем БД, содержащую все наши личные фотографии. Классический подход — хранить их в файловой системе, и только метаданные — в БД. Но ими намного легче управлять, когда все они находятся в БД. Гораздо проще выполнять резервное копирование и обеспечивать безопасность одного объекта — всей базы. Требуется принимать меньше решений по проектированию. Я предсказываю, что в конце концов все системы хранения информации будут эволюционировать в направлении БД.
ЛТ: Приверженцы таких платформ БД, как Oracle и DB2, продолжают утверждать, что, хотя SQL Server эффективен по стоимости, но по производительности и надежности он не может сравниться с другими платформами, под управлением Unix или Linux или на мэйнфреймах. Исходя из вашего опыта обеспечения производительности БД и работы с очень большими БД (very large database, VLDB) и вашего положения в Microsoft, могу предположить, что вы считаете по-другому. Как вы можете опровергнуть утверждения тех, кто скептически относится к БД Microsoft?
ДГ: Сильные стороны SQL Server — легкость использования и интеграция с Windows. Я считаю, что характеристики БД должны выстраиваться в таком порядке: качество, надежность, правляемость/ удобство, функциональность и производительность. Рассмотрим каждую из них подробнее.
Качество. Мы измеряем качество SQL Server, Oracle, DB2, Sybase и Informix с 1996 г. [проект RAGS Дона Слутца (Don Slutz)]. Откровенно говоря, в 1996 г. ни одна из этих СУБД не была хорошего качества — часто возникали сбои при сложных запросах или на запросы возвращались неверные ответы. Это действительно страшная тайна. Но за последние пять лет они значительно усовершенствовались. Теперь DB2, Oracle и SQL Server возвращают правильные и одинаковые ответы почти на все запросы (одна из СУБД не признает различий между строками нулевой длины и пустыми строками, а другая полагает, что поля varchar имеют длину максимум 255 символов, но на это я не обращаю внимания). Итак, я считаю, что качество основных БД SQL сейчас вполне приемлемо.
Надежность. Насколько системы склонны к потере данных? И здесь все СУБД добились значительного прогресса, но самый долгий путь прошел SQL Server. Система, унаследованная от Sybase, была недостаточно хороша в этом отношении. Некоторые операции над метаданными не защищались блокировками, резервное копирование снижало производительность работы и часто приходилось запускать модуль контроля непротиворечивости БД (database consistency checker, DBCC). В SQL Server 7.0 в 1999 г. Microsoft исправила большинство этих ошибок, а в SQL Server 2000 завершила исправление. Поэтому многие компании доверились SQL Server и работают с ним, не боясь потерять данные. Я несколько лет работал с TerraServer (terraservice.net) и SkyServer (skyserver.sdss.org) и ни разу не сталкивался со сбоем SQL Server. Это типичное явление. TerraServer фактически является кластером из четырех узлов, так что его готовность действительно высока. Том Барклай (Tom Barclay) демонстрировал устранение последствий сбоя узла TerraServer на реально работающей системе, что доказывает, как мы доверяем этому программному обеспечению. Итак, я считаю, что SQL Server надежен как скала.
Управляемость/удобство. Достаточно установить все три СУБД, чтобы увидеть, какая из них наиболее легкая в управлении и использовании. SQL Server интегрирован сам с собой и с операционной системой. Все остальные СУБД выглядят как компромиссы, их компоненты как бы «женились» на операционной системе и являются ее «гостями». В этом и заключается очевидное достоинство того, что SQL Server — система только для Windows. Инструменты, онлайновая документация, мастеры SQL Server являются лидирующими в отрасли. Другие производители пытаются добиться такого же бесшовного дизайна, но это действительно сложно, так как их компоненты фактически не проектировались для совместной работы.
Функциональность. У меня есть ощущение, что все эти СУБД обладают большей функциональностью, чем может использовать один человек. Конечно, мы все хотим как можно больше, и при выходе следующей версии действительно получаем больше. Лично я все еще пытаюсь работать со многими инструментами, присутствующими в текущей версии. Я почти каждый день использую SQL Server в приложениях и, признаюсь, есть еще несколько функций, которые я очень хотел бы в нем увидеть. Мои основные желания — интеграция C# с SQL Server (чтобы заменить T-SQL современным, объектно-ориентированным языком с настоящими типами данных) и многоузловые таблицы.
Производительность. Производительность SQL Server очень высока. Я использовал его в Web-серверах и системах поддержки принятия решений (Decision Support System, DSS). Мы считывали 5 миллионов записей в секунду и 350 Mб данных в секунду на двухпроцессорной системе! Оптимизатор SQL Server выбирает хорошие планы запросов, исполнительное ядро работает хорошо, система в целом самоуправляема. Ядро OLAP изумительно простое в использовании и очень быстро работает.
Вы можете взглянуть на результаты TPC, SAP и других тестов, чтобы убедиться в высокой производительности SQL Server. Тест производительности TPC-C показывает, что SQL Server имеет на 50% большую производительность и вдвое лучшее соотношение цена/производительность, чем любая Unix-система. Единственный близкий конкурент — DB2, работающая под управлением Windows, но, по данным теста TPC-C, SQL Server обладает лучшей производительностью и лучшим соотношением цена/производительность, чем любая другая система. В самом большом тесте производительности осуществляется управ- ление 53-терабайтной БД и обрабатывается миллиард транзакций TPC-C в день. Я считаю, что вопрос производительности SQL Server решен. Если SQL Server, работающий на 32 процессорах под управлением 32-битной Windows, обладает лучшей производительностью, чем СУБД, работающая на 64 процессорах под управлением 64-битной системы Solaris, то это говорит о многом. Системы на базе Windows продолжают энергично развиваться. IBM и другие компании работают над системами на базе Itanium (64-битный процессор Intel), которые будут содержать 64 и более процессоров. Для потребителей, которым нужно больше мощности, чем могут обеспечить 32-процессорные системы или желающих воспользоваться преимуществами множества маленьких компьютеров, мы можем предложить работающее масштабируемое решение на базе SQL Server 2000.
Джон Хайндмарш (John Hindmarsh)
Кризис идентичности, или как мы отличаем одно от другого.
Поиск ответов на философские проблемы восходит к Аристотелю и его последователям. Но и по сей день мы продолжаем задаваться вопросом, что отличает один элемент данных от другого, справедливо отказываясь принимать в качестве ответа «неизвестно». Идентификаторы необходимы в среде базы данных. Нельзя отличить одну запись от другой, если в каждой записи нет чего-то уникального, того, что можно идентифицировать и записать.
Энди Уоррен (Andy Warren)
Это третья статья моей серии «Порочная практика» (см. «Худшие приемы, часть 1 (из очень длинной серии!)» и «Порочная практика — объекты не принадлежащие DBO» в первых двух номерах журнала), пока что вызвавшей довольно мало откликов читателей. Не все со мной соглашаются, но, похоже, я не единственный, кто видит большое количество «порочных» привычек у разработчиков баз данных.
Итак, поговорим об еще одной порочной практике — не создавать первичный ключ для КАЖДОЙ таблицы и не использовать в КАЖДОЙ таблице кластерные ключи.
Я считаю, что в 9 случаях из 10 это происходит просто по ошибке. При создании таблиц в Enterprise Manager по щелчку значка первичного ключа на панели инструментов поле становится и первичным ключом, который обслуживается кластерным индексом. Это не самый лучший способ использования кластерных индексов, но это лучше, чем их отсутствие. Если таблицы создаются в Query Analyzer, выполнение оператора TSQL, создающего первичный ключ и кластерный индекс (или переключение в Enterprise Manager для выполнения этой операции), основывается исключительно на вашем желании.
Как администратор БД или главный разработчик, вы можете отслеживать и исправлять эти ошибки, до того как они повлияют на работу БД. У вас есть великолепная возможность убедиться, что ваши разработчики понимают важность использования первичных ключей и кластерных индексов. Иногда может показаться, что каждый из них ЗНАЕТ, почему эти вопросы важны. В данном случае нужно не предполагать, а спрашивать. Если они знали, но забыли, то не помешает мягкое напоминание быть внимательнее. Если же они не знали, пришло время их обучить.
Александр Чигрик (Alexander Chigrik)
Иногда бывает сложно определить, какие индексы использовать при обработке запроса. В этом случае оптимизатор запросов использует страницы распределения ключей (distribution page).
SQL Server 6.5, в отличие от SQL Server 7.0, не может автоматически обновлять статистику распределения, так что следует обновлять ее вручную, когда большие количества данных в таблице с индексированными столбцами добавляются, изменяются или удаляются.
В этой статье я расскажу о структуре страниц распределения, шаге распределения и плотности индекса, а также о том, как просматривать и обновлять статистику распределения.
Страницы распределения
В SQL Server 6.5 имеется пять типов страниц:
Каждый индекс может иметь только одну страницу распределения. Страницы распределения используются оптимизатором запросов, чтобы определить, какие индексы использовать при обработке запроса или чтобы определить, что эффективнее — использовать индекс или сканировать таблицу.
Performance
Облегчение настройки запросов SQL Server с помощью команд SET STATISTICS IO и SET STATISTICS TIME
Брэд М. МакГехи (Brad M. McGehee)
Эта статья посвящена не настройке запросов вообще (для этого нужна, по меньшей мере, отдельная книга), а настройке запросов с помощью команд Transact-SQL SET STATISTICS IO и SET STATISTICS TIME, про которые так часто забывают.
На первый взгляд задача настройки производительности кажется довольно простой. В сущности, нужно, чтобы запросы работали быстрее. Неважно, ускорится ли выполнение запроса с 10 минут до 1 или с 2 секунд до 1, конечная задача — уменьшить время, необходимое для исполнения запроса.
Но, если задача так проста, почему же зачастую ее так сложно решить? Есть множество причин, затрудняющих настройку запросов, но в этой статье основное внимание уделено лишь одной из них. Она заключается в непостоянстве среды, в которой работает настраиваемый запрос. Она ежесекундно меняется, поэтому трудно разобраться, что же на самом деле происходит с запросом.
Что я хотел этим сказать? Как и большинство других пользователей, вы можете пытаться настраивать производительность запросов либо на тестовом сервере с размешенной на нем копией рабочих данных, либо на рабочем сервере с оригинальными рабочими данными. В любом случае, от испытания к испытанию сервер хоть немного, но будет меняется. Помните: SQL Server динамически самонастраивается в соответствии с моментальными изменениями потребности в его ресурсах. Несомненно, настройка запроса на тестовом сервере осуществляется в менее динамичных условиях, чем при использовании рабочего сервера. Однако рассматриваемые проблемы касаются практически любого экземпляра SQL Server.
Майкл Бэллони (Michael Balloni)
для исполнения рутинных прикладных запросов лучше, чтобы механизм СУБД не занимался хэшированием и сортировкой сотен тысяч и миллионов строк, особенно когда конечный результат состоит всего из нескольких записей.
Часто при запросах к большим таблицам SQL Server использует соединения на основе хэш-таблиц и слияний, в то время как несложные соединения на основе вложенных циклов могут обеспечить большую производительность и снизить нагрузку на сервер. В таких случаях время исполнения запроса возрастает от нескольких миллисекунд до многих секунд, поскольку соединения на основе хэш-таблиц требуют обработки и временного хранения больших объемов данных, а соединения на основе слияния — сортировки и обработки не меньших объемов информации.
Ситуация, когда необходимые для оптимизации запроса индексы отсутствуют (или нежелательны), редко приемлема и лишь при исполнении административных запросов для установления единичных фактов и в тех случаях, когда можно позволить себе ожидать завершения запроса в течение нескольких минут или секунд, нужных для получения результата.
Том Пулен (Tom Pullen)
В этой статье описываются действия, необходимые для успешного выполнения транзакционной репликации из SQL Server 6.5 в SQL Server 2000. Проверка этой процедуры показала ее работоспособность. Предполагается, что у вас имеется опыт репликации данных SQL Server
(Возврат на основную страницу)