(Возврат на основную страницу)

Содержание номера за Июль 2007 год

Беседа с Пэт Селинджер

Возьмите Пэт Селинджер (Pat Selinger), фирма IBM, и Джеймса Гамильтона (James Hamilton), фирма Microsoft, усадите их побеседовать друг с другом, и вы услышите все то, что вам хотелось знать о технологии баз данных и о чем вы не побоялись спросить.

Селинджер, почетный сотрудник (имеет титул IBM Fellow) и вице­президент (vice president of area strategy, information, and interaction for IBM Research) фирмы IBM, определяет стратегию ведущейся в IBM исследовательской работы, тематика которой простирается от классических систем баз данных до обмена текстовой и речевой информацией, а также мультимодального взаимодействия. После окончания Гарвардского университета со степенью доктора философии (Ph.D.) в области прикладной математики Пэт почти 30 лет проработала в фирме IBM, чередуя исследовательскую деятельность с разработкой IBM­ продуктов баз данных.

Присоединившись в 1975 году к работе исследовательского подразделения IBM Research, Селинджер становится руководителем команды, которая создает System R — первое доказательство возможности практического применения технологии реляционных баз данных. Ее инновационную работу в области оптимизации на основе стоимости (cost­based query optimization) используют практически все фирмы, занимающиеся созданием реляционных баз данных. В 1986 году Селинджер основала Database Technology Institute — программу, которая объединяет исследовательское подразделение фирмы IBM и коллективы, занимающиеся разработкой программного обеспечения; цель этой программы — ускорение внедрения результатов научных изысканий в промышленные продукты. В 1997 году Пэт перешла из исследовательского подразделения фирмы IBM в подразделение, занимающееся разработкой, в качестве вице­президента в области технологии и архитектуры управления информацией (vice president of information management architecture and technology) лаборатории IBM Silicon Valley Lab, расположенной в Сан­Хосе, Калифорния, став во главе создания технологии для следующего поколения систем управления данными. В свою нынешнюю должность она вступила в 2004 году.

В 1994 году Селинджер удостоилась титула IBM Fellow. Среди прочих профессиональных отличий наивысшего уровня, которых может добиться инженер, она в 1999 году была избрана в Национальную инженерную академию (National Academy of En­gi­neering).

Эту пространную беседу с Пэт обо всем, что касается баз данных, ведет Джеймс Гамильтон, который большую часть своей профессиональной деятельности занимался разработкой в сфере баз данных. Последние восемь лет он работал с командой SQL Server в фирме Microsoft. До того как присоединиться к команде Microsoft, он 11 лет проработал в фирме IBM, где был ведущим архитектором СУБД DB2. До этого Джеймс возглавлял проект фирмы IBM по созданию компилятора для языка программирования C++. В 1986 году Гамильтон окончил университет University of Victoria со степенью бакалавра (B.Sc.) в области компьютерных наук и имеет степень магистра, полученную в университете University of Waterloo.

James Hamilton (Д.Г.)-Давайте начнем с той роли, которая принадлежит оптимизатору запросов в системе управления реляционной базой данных, а также с Вашего изобретения оптимизаторов на основе стоимости.

Pat Selinger (П.С.)-Как известно, фундаментальный принцип реляционной базы данных — это хранение данных в строках и столбцах. В основе такого хранения лежит значение: в том смысле, что именно значения представляют собой данные. В указателях не содержится никакой информации. Вся информация отражается в наборе таблиц, и эти таблицы имеют определенные, хорошо знакомые вид и форму: таблица заказов, таблица заказчиков, таблица служащих и так далее. Набор столбцов в каждой из этих таблиц фиксирован: имя, фамилия, адрес.

Реляционные системы обладают языком высокого уровня, который называется SQL и является множественно­ориентированным языком запросов. Эта концепция является уникальной, и именно она отличает системы реляционных баз данных от всего того, что существовало до или будет после них.

Концепция множественно­ориентированного языка запросов позволяет запрашивать список всех программистов, которые работают в отделе 50, или перечень всех заказов стоимостью свыше $5000, или список всех заказчиков из Сан­Хосе, которые сделали заказы на сумму свыше $5000, и так далее. Данные, хранящиеся в реляционных базах данных, могут быть объединены многими различными способами исключительно на основе их значений.

Каким образом вы превратите такой ориентированный на множества вопрос очень высокого уровня, который задает пользователь, в точную инструкцию, позволяющую выполнить навигацию по диску и получить данные из каждой отдельной записи, принадлежащей каждой отдельной таблице? Этот процесс есть оптимизация запроса: идея заключается в преобразовании высокоуровневого языка SQL в низкоуровневую инструкцию или последовательность дей­ствий, через которые вы проходите, чтобы получить доступ к данным.

Оптимизаторы запросов были созданы как технология, позволяющая добиться работы такого языка программирования высокого уровня — языка доступа к данным, языка SQL. Без этого вы, в конечном итоге, использовали бы «грубую силу»: давайте возьмем каждую строку и посмотрим, соответствует ли она описанию того, что было запрошено. Это отдел 50? Это заказ на сумму свыше $5000? Крайне неэффективно было бы каждый раз просматривать все данные.

Итак, у нас есть методики доступа, которые позволяют выполнять поиск только в подмножестве данных, и, значит, вы должны предусмотреть, какая из этих методик доступа подходит для каждого данного типа запроса.

Хитрость оптимизации запросов на основе стоимости заключается в том, что надо рассчитать стоимость каждого из различных способов доступа к данным; определить стоимость каждого из различных способов объединения данных, хранящихся в нескольких таблицах; оценить размеры результатов запроса, а также экономию, которых вы добились бы, запоминая данные в буферных областях; рассчитать количество строк, к которым вы реально обратитесь, если используете индекс для обращения к данным, и так далее.

Чем подробнее можете вы смоделировать стоимость доступа к данным, тем лучше окажется сделанный вами выбор пути доступа. В прошлом, в конце 70­х, мы разработали методику оптимизации запросов на основе стоимости и предоставили модель, которая оказалась достаточно хороша для того, чтобы можно было осуществить поиск в очень большом пространстве выбора в разумных пределах времени, а затем дать очень точную оценку стоимости и, следовательно, указать очень хороший путь доступа.

 (Д.Г.:)-Удивительно, что столько лет спустя эта работа остается доминирующим подходом к оптимизации запросов в реляционных базах данных. Оптимизаторы на основе стоимости продемонстрировали настоящий успех в переходе технологии из исследовательской сферы в промышленность. Не могли бы Вы немного подробнее рассказать о том, почему эта методика оказалась столь успешной?

 (П.С.:)-Сама сущность оптимизации запросов на основе стоимости, как ни странно, обеспечила возможность до известной степени автоматизировать разработку приложений. То есть разработчик приложений не должен обладать доскональными знаниями о том, как расположены данные на диске, где именно находятся записи и какие именно пути доступа ведут к ним. Способность выполнять по­настоящему качественную оптимизацию запросов на основе стоимости — это огромный прогресс с точки зрения производительности приложений. Отсюда — непреодолимое стремление рынка иметь эффективную оптимизацию запросов на основе стоимости.

Я принимала участие в создании оптимизатора запросов для системы System R, который целиком и полностью вошел в состав такого продукта фирмы IBM, как система управления реляционными базами данных DB2, где этот оптимизатор получил дальнейшее развитие. Устранены многие допуски, которые были сделаны для упрощения, с целью облегчить решение данной проблемы в конце 70­х, и сейчас используемая модель стала глубже, обладает большими возможностями и включает в себя более обширный набор методик доступа к данным.

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

Эта технология еще не исчерпала всех возможностей своего развития: например, существует проблемная ситуация, когда поведение реальных данных отличается от поведения, предполагаемого моделью. Многие оптимизаторы не обеспечивают по­настоящему хорошего моделирования сильно коррелированных данных. Например, 90210 — это почтовый индекс, который используется только в Калифорнии. Индексы не распространяются равномерно по штатам, и индекс 90210 не используется в каждом штате федерации. Для пользовательского запроса достаточно привязки к индексу 90210, и применение еще одного предиката, например штат равен Калифорния, не меняет результата. Дополнительный предикат не уменьшает количество записей, потому что индекс 90210 используется только в Калифорнии.

 (Д.Г.:)-Один из недругов промышленных оптимизаторов запросов — сложность, и иногда этот фактор может приводить к тому, что схема запроса утрачивает свою стабильность. Небольшие изменения, внесенные в запросы или в запрашиваемые данные, могут приводить к совсем иным схемам. Заказчики часто просят у меня такую хорошую схему, которая является стабильной, но не совсем оптимальной и вместе с тем часто меняющейся непредсказуемым образом. В каком направлении нам следует вести поиск, чтобы добиться прогресса в решении проблемы оптимальная­схема­запроса­против­стабильной­схемы­запроса?

 (П.С.:)-Я думаю, нам следует двигаться в двух направлениях. С одной стороны, вы должны обладать способностью исполнять хорошие схемы и во время исполнения такой схемы хотите получать уведомления в тех случаях, когда реальные данные значительно отклоняются от ваших ожиданий. Если вы ожидали получить пять строк, а получили миллион, есть вероятность того, что ваша схема не будет работать надлежащим образом, потому что вы выбрали ее, исходя из предположения о пяти строках. Таким образом, обеспечение способности вносить промежуточные коррективы — это та область развития оптимизаторов запросов, которой занимается фирма IBM.

Во­вторых, вы должны продолжать углублять используемую модель, потому что необходимо предоставить приемлемые схемы, прежде чем вы сможете заняться их тонкой настройкой в динамическом режиме. Понимание корреляционной зависимости между строками или между столбцами в различных таблицах — вспомните пример с почтовым индексом, который я приводила ранее, — является очень важной вехой на пути, ведущем к более глубокому пониманию данных и, следовательно, к возможности осуществить еще более эффективную оптимизацию запросов.

Факты таковы, что по мере того, как заказчики все чаще и чаще используют полнокомплектные пакеты или имеют «случайных» пользователей, которые не посещали в течение года SQL­школу, существует реальная потребность в возможности выполнить эффективную оптимизацию запросов. Вы не можете иметь администраторов баз данных, которые вбегают в комнату с возгласом: «Подождите, не нажимайте пока клавишу Enter. Я должен взглянуть на ваш запрос, чтобы посмотреть, все ли с ним в порядке». Отказ от оптимизации запросов на основе стоимости критичен с точки зрения повышения производительности приложения и снижения суммарной стоимости владения.

 (Д.Г.:)-Давайте на минуту остановимся на оптимизации запросов и посмотрим, где еще, кроме систем управления базами данных, может быть использована эта технология. В последние годы фирма IBM и индустрия в целом делают инвестиции в вычислительные системы с автонастройкой (auto­tuning computing) и самоуправляемые вычислительные системы (autonomic computing). Как, по­вашему, есть место для оптимизации запросов на основе стоимости в области таких приложений?

 (П.С.:)-Безусловно. Это новая обширная область наших исследований. Фирмы имеют массу данных, которые довольно хорошо структурированы, — записи о заказах, заказчиках, служащих — но эти данные составляют, может быть, 15 процентов общего объема данных, которыми располагает фирма. Остальная часть — это файлы документов, это XML­код, это изображения, это данные, размещенные на веб­страницах, — вся эта информация также нуждается в организации и управлении.

XML­формат предоставляет механизм, обеспечивающий некоторые возможности управления информацией, но эти данные не обладают достаточно регулярной структурой. Они очень динамичны. Каждая запись могла бы иметь вид, отличный от следующей записи даже в коллекции взаимосвязанных вещей, таких как заказы или документы.

Поэтому вам необходимо иметь язык запросов, такой, например, как XQuery, который будет способен осуществлять навигацию и задавать множественно­ориентированные вопросы о таких данных нового вида. Решение этой задачи вскрывает другой набор методик доступа к данным и требует дополнений для процедуры оптимизации запросов. Но я думаю, что, безусловно, необходимо продолжать движение в направлении автоматической оптимизации запросов, а не возвращать программистов к прежним играм с пониманием точных структур данных и выполнением навигации в программе приложения вручную. Это просто затратный путь.

 (Д.Г.:)-Учитывая новые методики оптимизации, системы с управлением от обратной связи (feedback­directed systems) и динамическое принятие решений на этапе исполнения (dynamic execution time decisions) — все важные области продолжающегося исследования, — какие шаги представляются Вам наиболее важными, заглядывая вперед, лет, скажем, на пять или около того?

 (П.С.:)-Я думаю, стоимость владения беспокоит каждого заказчика, не только из­за экономического спада, который некоторые из них еще переживают или который им только что пришлось пережить, но и потому, что снижается стоимость процессоров, дискового пространства и памяти, всего прочего — но стоимость труда растет.

Более того, вы должны учитывать соотношение: сколько администраторов вам необходимо для обслуживания данных объемом в 1 терабайт. Если вы не сможете существенно улучшить этот показатель по мере того, как накапливаете все больше и больше терабайт данных, то очень скоро вам придется нанять на работу половину населения планеты, чтобы администрировать этот объем информации. Поэтому мы изобретаем способы, позволяющие администраторам обрабатывать в 20, 100, 1000 раз больше данных, в сравнении с тем, что они обрабатывают сегодня.

В то же время мы находимся под прессом — необходимо объединять, искать, понимать и использовать преимущества такой информации, которая существует в менее структурированной форме: в виде электронной почты, например. Фирмы хотят иметь возможность просматривать электронную почту или досье заказчиков, чтобы обеспечить своим клиентам более высокий уровень обслуживания, и, по мере того как мы это делаем, мы должны организовывать, понимать и анализировать больше разновидностей информации.

Если мы посмотрим, во что это обойдется, нам придется изменить правила игры в отношении стоимости организации, администрирования и поиска таких данных. Инициатива создания вычислительных систем с самоуправлением, с которой мы выступили в фирме IBM и которую сейчас приняла также индустрия, — это спасительная отсрочка, которая намерена обеспечить такую возможность.

(Д.Г.:)-Вы очень большое внимание уделяете снижению стоимости администрирования. Как насчет стоимости разработки приложений?

 (П.С.:)-У вычислительных систем с самоуправлением есть две стороны: одна сторона — это разработка приложений; вторая — администрирование. В области разработки приложений заказчики хотят иметь универсальный набор инструментальных средств. Вот почему фирма IBM оказывает столь большое содействие платформе с открытым исходным кодом Eclipse и поощряет разработчиков вносить свою лепту в эту платформу: с тем, чтобы можно было иметь такой универсальный набор инструментальных средств и такой универсальный набор навыков, которые позволяют людям с их помощью работать с самыми различными платформами. Высокоуровневое программирование — язык запросов XQuery, SQL­стандарты, платформа Enterprise JavaBeans и COM­объекты — вносит свой вклад в то, чтобы обеспечить возможность объединять строительные блоки для ускоренной разработки приложений вместо того, чтобы просто использовать кодирование для навигационного доступа к данным.

(Д.Г.:)-Работая в индустрии, которая существует уже почти 30 лет, я нахожу странным, что, несмотря на столь внушительный срок, наша беседа оставляет такое впечатление, будто подавляющее большинство проблем еще ждет своего решения.

 (П.С.:)-Это одна из поразительных сторон управления данными. Управление данными включает в себя все проблемы языков программирования, все проблемы операционных систем. То же самое относится к хранилищам данных. Из­за изменений в архитектуре аппаратного обеспечения компьютеров — имеются в виду такие вещи, как память большого объема и так далее, — существуют новые возможности, позволяющие приспособить механизмы данных к использованию возможностей аппаратуры.

Важнейшие события происходят в управлении информацией. Информация — это поистине движущая сила того, как работает правительство, как ведут свой бизнес наши заказчики. Информация жизненно необходима для экономики.

(Д.Г.:)-Недавно Вы вернулись в исследовательское подразделение фирмы IBM после успешной работы в команде, занимающейся разработкой. Расскажите о вашей новой роли вице­президента, отвечающего за стратегию, информацию и взаимодействие.

(П.С.:)-Роль, на которую я согласилась, — это расширение понятия того, что мы называем информацией. Из 30 лет своей работы с данными 27 я по­тратила на структурированную их часть: механизмы реляционных баз данных, оптимизацию запросов, обеспечение более быстрого их исполнения, изобретение новых методик доступа к данным и так далее. Как я упомянула ранее, это около 15 процентов всей информации, а остальные 85 процентов приходятся на долю данных, представленных в менее структурированной форме.

В этой своей новой роли я занимаюсь тем, что добиваюсь полной картины: собирая воедино все формы информации и управляя всей этой информацией, для чего может потребоваться совсем иной взгляд на проектирование, нежели того требует структурированная информация. Понимание системой того, что заключается в таких данных, не отличается особой глубиной, поэтому исследователи оказываются все более вовлеченными в решение задачи понимания семантики и речи, и в онтологию, и в классификацию, и в аналитические исследования различных других видов с тем, чтобы суметь понять, что собой представляют эти данные, и извлечь из них информацию.

(Д.Г.:)-Можете рассказать о некоторых проектах, в которых Вы сейчас участвуете?

(П.С.:)-Одно из направлений, на которое мы тратим много времени, — проект UIMA (unstructured information management architecture — архитектура управления неструктурированной информацией). Это архитектура, которую мы рассматриваем как каркас, обеспечивающий возможность представлять неструктурированную информацию, а также анализировать ее и управлять ею. По сути дела, это платформа, к которой вы можете подключать, например, анализ текста и онтологический поиск, где вы могли бы взять информацию и аннотировать ее — имя президента, название университета — а затем получить возможность сделать обобщение, основываясь на категориях, семантике и онтологии, и отвечать на вопросы об этой информации. Например, производитель автомобилей мог бы задать вопрос: какие чувства испытывают люди, которые обращаются с жалобой на проблемы с тормозами в таком­то и таком­то автомобиле? как нам обрабатывать такие вопросы? можем мы улучшить нашу службу работы с клиентами на основе полученных результатов?

Такие вещи, как регулируемая совместимость, также являются очень хорошими примерами, когда фирмы просят, например, проанализировать электронную почту и убедиться на основе сделанной выборки, что ничего предосудительного не происходит. Как вы можете обеспечить фирмам такие инструменты, которые позволят делать это автоматически?

(Д.Г.:)-Самое время отвлечься от чисто структурированного хранения, поскольку, как вы упомянули, реляционные системы в настоящее время управляют менее 15 процентами промышленных данных. Я оспорю эту цифру; если бы мы не ограничивались производственными данными, то обнаружили бы, что значительно менее 5 процентов всех данных в мире хранятся в РСУБД. Забавно, что в реляционном мире мы управляем почти всеми структурированными данными; однако управление менее структурированными данными пока еще остается почти непаханым полем.

(П.С.:)-И это поле предоставляет такое разнообразие форматов и систем управления. В одной только области управления контентом существуют тысячи фирм, и никто не имеет большой доли на рынке. Вы можете пересчитать основных реляционных поставщиков по пальцам одной руки, но если вы начнете перечислять фирмы управления контентом, вы быстро исчерпаете пальцы не только своих рук и ног, но и ваших соседей. Огромное количество фирм занимается очень специализированными видами управления. Пора приступить к сбору этих фрагментов в одно целое и получить более широкий обзор.

Метаданные намерены играть роль ключевого фактора в обеспечении возможности выяснить, где находятся все эти данные, сообщить нам, как к ним обратиться, и дать нам представление о том, как обнаружить другие данные.

(Д.Г.:)-Назовите некоторые задачи, которые существуют в этом мире с расширенными границами, над которыми Вы работаете именно сейчас, — особенно в отношении нетрадиционных типов данных, вроде фотографий, видео и голосовых данных? Где, по­вашему, будут существовать крупные исследовательские задачи на следующее десятилетие?

(П.С.:)-Я думаю, при наличии всех этих отдельных технологий всегда есть место для их совершенствования. Помимо этого, исключительно полезным делом может оказаться выяснение способа, позволяющего создать одно целое из комбинации этих технологий. Если бы технология распознавания речи могла извлечь пользу из тех знаний, которые предоставляет анализ текста для тех вещей, которые я уже расшифровала, мы могли бы использовать такую информацию, чтобы сузить фокус нашей вероятной беседы.

Возможно существование массы взаимосвязей, которые не до конца исследованы. Исследование таких синергизмов — это очень захватывающая область.

(Д.Г.:)-Есть ли еще какие­нибудь области, которые Вы рассматриваете как недостаточно исследованные и по отношению к которым Вам хотелось бы видеть проявление большего интереса?

(П.С.:)-Я рада была бы видеть рост числа тех людей, которые занимаются проблемой метаданных. Метаданные помогают интегрировать информацию, особенно информацию различных видов и форматов, и предоставить сведения о том, какого рода характеристики можно извлечь из этой информации. Такие вещи обладают большим потенциалом для повышения ценности той информации, в хранении которой мы столь преуспели. Я рада была бы видеть больший объем работ по этой теме в переводе на отображение и обнаружение — обнаружение взаимосвязей, обнаружение корреляции и так далее

(Д.Г.:)-Есть ли такие области, которые, как Вам кажется, мы исследовали с избытком?

(П.С.:)-Еще один блокирующий механизм для систем управления данными мне просто не интересен, но к счастью исследовательская работа в подобных областях замирает.

(Д.Г.:)-Я представляю две картины, рисующие будущность неструктурированных данных. Одна — имеет файловую систему, дополненную инструментами поиска, а в основе другой — возрастающая роль структурированных хранилищ, которые являются намного более универсальными и в гораздо большей степени приспособлены к обращению с динамическими схемами и контентом. Есть место для файловых систем и инструментов поиска? Когда, по­вашему, они выйдут из игры?

(П.С.:)-Я не думаю, что какие­либо существующие сейчас или будущие механизмы хранения заменят собой все остальные средства. Например, есть множество ситуаций, в которых файловые системы — это просто прекрасно, ничего большего вам не надо, и люди вполне с ними счастливы. Мы должны иметь возможность добираться до таких источников данных с помощью метамеханизма, который знает, как достичь всех этих различных репозиториев данных и обратиться к ним, а также понимает все эти разнообразные форматы —.jpg, .mpg, .doc и так далее — и знает, как интерпретировать такие данные.

Идея централизованного репозитория межгалактических размеров не является ни обоснованной, ни практичной. Вы не можете просто сказать заказчику: «Поместите все ваши данные в мой репозиторий, и я решу все ваши проблемы». С моей точки зрения, правильным является такой ответ: заказчики будут хранить свои данные в различных местах, ими будут управлять различные приложения в файловых системах и механизмах баз данных. Они не собираются сосредотачивать их в хранилище данных одного вида. Это просто непрактично. Это нереально экономически. Моя работа в фирме IBM заключается во вне­дрении такой стратегии, которая обращается к данным по месту их хранения и интегрирует их виртуально без необходимости обязательной физической интеграции этих данных.

Таким образом, файловые системы по­прежнему останутся с нами. Они, возможно, получат дополнения в виде специальных методик поиска по мере того, как будут наращиваться возможности и производительность RAID­систем и дисковых серверов, файловых серверов и так далее, а возможности реляционных систем будут расширяться в отношении того, что именно они могут обрабатывать, но мы не собираемся заменять все технологии каким­то одним­единственным решением.

(Д.Г.:)-Считаете ли Вы, что основу будущих систем управления контентом составляют, главным образом, системы реляционных баз данных, или Вы видите их как независимые хранилища, построенные с помощью того, чему мы научились за прошедшие 30 лет работы с реляционными технологиями

(П.С.:)-Мне нравится та архитектура, которую мы имеем в менеджере контента, реализованном в DB2, где СУБД DB2 является библиотечным сервером — картотекой, так сказать. Эта архитектура использует некоторую дополнительную семантику в приложении системного уровня, окружающего DB2, с некоторыми новыми, определяемыми пользователем типами и функциями и хранимыми процедурами, реализующими эти приложения. Она имеет отдельных менеджеров ресурсов, которые способны обрабатывать конкретные классы типов и стили с такого рода документом, такими типами изображений. Эти менеджеры могли бы храниться физически или в DB2 как на библиотечном сервере, или в каком­то отдельном месте, или вне файловой системы с помощью набора иных механизмов.

Такая архитектура обеспечивает гибкую конфигурацию. Вы можете эксплуатировать столько функций DB2 — XML, например, — сколько хотите, или вы можете отдать предпочтение использованию каких­то менеджеров репозитория. Этот менеджер, может быть, не обладает таким большим набором возможностей, но он является экспертом по информации конкретного вида и мог бы храниться локально там, где вам необходимы такие данные — особенно если это массивный объем данных, например результаты масс­спектрометрии. Это огромные файлы, и вам необходимо иметь их рядом с тем местом, где вы проводите анализ.

(Д.Г.:)-Как Вы считаете, обладает ли XML­формат более фундаментальной ролью в системах управления контентом?

(П.С.:)-Я вижу, что заказчики очень заинтересованы в XML, и уже сегодня многие из них используют этот формат для взаимного обмена. Я вижу, что заказчики хотят иметь богатые возможности XML­формата, встроенные непосредственно в механизм баз данных. Вот почему фирма IBM занимается тем, чтобы в полном объеме обеспечить встроенную реализацию XML в СУБД DB2, предназначенную для платформ Linux, UNIX, Windows и z/OS.

Если заказчик обеспечивает подтверждение транзакции или посылает вам форму заказа в XML­виде, удачной может оказаться идея о сохранении этих данных в XML­формате и использовании их в этом же виде внутри базы данных. Мы могли бы также транслировать XML­код в реляционный вид, если, начиная с некоторого момента, большая часть обработки будет носить реляционный характер. Это стратегия «испекли­пирожок­да­сами­и­съели». СУБД DB2 может хранить данные в XML­формате и анализировать их, осуществлять поиск таких данных и обращаться к ним, или она может преобразовать эти данные в реляционное представление и организовывать все транзакции, которые уже написаны для реляционных систем.

(Д.Г.:)-В мире управления реляционными данными мы видим заметное сокращение числа поставщиков коммерческих систем. Вы упомянули ранее, что в мире управления контентом присутствует большое разнообразие доступных в настоящее время хранилищ. Вы считаете, что аналогичная консолидация произойдет в управлении контентом, где со временем останется меньше производителей хранилищ, или Вы думаете, что по­прежнему будет наблюдаться широкое разнообразие специализированных систем?

(П.С.:)-Наблюдается некоторая консолидация индустрии, основанная на стремлении принять общий набор стандартов, что и обеспечит базу. Возьмите стандарт JSR170, например. Если вы можете программировать по этому прикладному интерфейсу, то заказчики будут обладать большими возможностями для перехода от одной системы управления контентом к другой, или приложение не будет требовать, чтобы вы имели определенную систему управления контентом в его подчинении. Это даст индустрии свободу в смысле консолидации, если она экономически оправдана, и позволит людям иметь общий набор приложений, даже если они предпочитают сохранить разнообразие поставщиков.

(Д.Г.:)-Принимая во внимание, что сейчас реляционные хранилища поддерживают XML­формат и полнотекстовый поиск, чего им не хватает? Почему реляционные системы с расширенным набором возможностей не оказывают большего влияния на неструктурированный мир?

(П.С.:)-Семантика управления контентом выходит за рамки только того, что мы предлагаем в части хранения данных, механизмов хранения данных, существующих в мире «родственников» СУБД DB2. Существует важный набор других абстракций и методик управления, которые или должны находиться сверху, или исходить из системы управления контентом, которая использует и применяет реляционный механизм с расширенным набором возможностей, но они не полагаются исключительно на этот механизм.

Например, системы управления контентом обладают способностью разрешить Пэт доступ к главе 1 документа, Джеймсу — доступ к главе 2, а Эду — доступ к главам 1 и 2 на уровне субдокумента. Это нечто такое, чего реляционные системы сегодня не делают.

Аналогично, проблема подборки, идея коллекции документов, которые на самом деле не связаны с точки зрения схожей структуры, но привязаны к некоторому семантическому контенту более высокого уровня, выходит за рамки того, что обещают реляционные системы по этому вопросу.

(Д.Г.:)-Как Вы считаете, есть еще области, исследование которых необходимо менеджерам контента и реляционным хранилищам с целью их усовершенствования и для того, чтобы помочь заказчикам управлять широким разнообразием данных?

(П.С.:)-Если бы сегодня я стояла перед выбором: заниматься исследовательской работой или перспективными разработками, то есть ряд областей исследования, которые мне очень, очень интересны. Существует постоянная потребность в открытиях в области самонастраивающихся систем. Что вы должны делать, чтобы обладать истинно автоматической системой данных, которую можно было бы встроить во что угодно? Что вам следует делать, чтобы добиться истинно массового параллелизма на уровне миллионов систем (например, Интернета)? По мере того как аппаратура широкого потребления становится все меньше и меньше, можем мы устанавливать связь и общаться с системами и вычислительными средствами в масштабе миллионов, если сегодня мы находимся на технологическом уровне в тысячи систем? Как вам поступить с потоками данных, если запросы фиксированы, а данные идут непрерывным потоком, и это могли бы быть неструктурированные данные?

Как вам выявить телефонные переговоры Осамы бен Ладена в поступающих потоках данных с помощью таких методик, как, например, семантический анализ, распознавание голоса и автоматическая транскрипция «речь­в­текст» и перевод с одного языка на другой?

Как вы накапливаете метаданные и поддерживаете их в современном состоянии? Как вы управляете ими, учитесь на них, извлекаете из них информацию?

Поиск все еще находится в своем первом поколении. Есть масса возможностей для совершенствования поиска. Если известно, что вы были недовольны, когда печатали свои три ключевых слова для механизма поиска, поможет ли это понять, что именно вы искали? Если известно, какое сообщение электронной почты вы просмотрели перед тем, как ввести эти три ключевых слова, поможет ли это понять, что вы ищете? Как поисковый механизм может найти то, что вы имели в виду, а не то, что вы ввели с клавиатуры?

Насколько достоверна полученная информация? Существует множество источников недостоверности. Что если у меня есть источник информации, который дает правильные сведения только в половине случаев? Как мне оценить эту информацию в сравнении с другим источником, который всегда дает верные сведения? Как мне объединить эту информацию в одно целое и каков уровень моего доверия к этой полученной в результате объединенной информации?

Все эти вещи, после того как мы приступили к работе с неструктурированными данными, неполными и неточными ответами и так далее, являются важными возможностями для исследования и перспективной разработки.

(Д.Г.:)-Мы начинаем видеть возрастание роли открытого исходного кода в обработке данных на стороне сервера. Особенно в мире баз данных, где мы сейчас имеем двух соперников с открытым исходным кодом. Открытый исходный код — это хорошо для мира баз данных?

(П.С.:)-Мне нравится идея открытого исходного кода. Я была менеджером команды Cloudscape в фирме IBM в то время, когда мы пожертвовали этот проект для сервера Apache, где он стал проектом­инкубатором под именем Derby. Мое представление об этом таково, что открытый исходный код обеспечивает намного большие возможности для использования баз данных в таких местах, где люди обыкновенно не стали бы покупать механизм баз данных.

Таким образом, открытый исходный код может обеспечить выигрыш в надежности, восстанавливаемости, возможности использовать множественно­ориентированные запросы для еще одного класса приложений — малого бизнеса — а также возможность эксплуатировать замечательные характери­стики систем баз данных в значительно более богатом наборе приложений. Я думаю, что для индустрии это полезно.

(Д.Г.:)-Обязанность, к которой, как я знаю, Вы всегда относились очень серьезно, — это обуче­ние — помочь следующему поколению вырасти и преуспеть. Важность этого очевидна, но делать это хорошо очень трудно. В чем Ваш секрет?

(П.С.:)-Некоторые посмеиваются надо мной, говоря, что я съедаю себя своим наставничеством. Я думаю, люди намного свободней общаются тогда, когда сидят за кружкой пива, или обедают, или пьют кофе, поэтому наставничеством я занимаюсь главным образом в кафетерии за едой, в баре или во время обеда. Тем самым люди оказываются в более комфортном окружении для разговора о том, что их действительно занимает. Я консультирую около 30 человек, вероятно, две трети из их числа составляют женщины. Любой свой незанятый ланч я посвящаю консультациям.

По­моему, наставничество обеспечивает людям взгляд со стороны, практическое представление с позиций опыта и дает им ощущение, что это они делают выбор и что они в гораздо большей степени влияют на выбор своей карьеры, чем им казалось.

Д.Г.:-Что Вы думаете о более широком привлечении женщин в компьютерные науки 

(П.С.:)-Несколько лет тому назад Национальная инженерная академия (National Academy of Engineering) провела исследование относительно того, что мы можем сделать, чтобы заинтересовать инженерным искусством большее число женщин. Меня особенно удивило, что другие страны добились в этой области значительно больших успехов, чем мы, и что женщины составляют до половины численности работников в таких профессиях, как биология, медицина и юриспруденция.

Следовательно, женщин отпугивает не наука. Я думаю, в том, как культура Северной Америки рассматривает профессию инженера, есть нечто такое, что отвращает женщин от овладения этими специальностями.

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

Я провела много времени в социально­ориентированном центре. На следующей неделе я собираюсь посетить женский университет в Миссисипи и буду говорить там о выбранной мной профессии и о том, что можно иметь детей и сохранить работоспособность — фактически, преуспеть — будучи инженером. Просто успокоить людей, сказав им, что такое возможно, и уже это может способствовать тому, что они будут рассматривать инженерию как профессиональную возможность для себя.

(Д.Г.:)-Вне всякого сомнения, Вы сами очень успешны. Есть ли такие люди, которых Вы можете назвать как оказавших вам реальную помощь в личной жизни и профессионально?

(П.С.:)-На ранней стадии моей карьеры у меня были чудесные наставники. Первый менеджер проекта System R Фрэнк Кинг (Frank King) был просто грандиозен в том, как он меня поддерживал и тратил время на беседы со мной о проблемах бизнеса, что позволило мне обрести почву под ногами на самой ранней стадии моей карьеры. Джанет Перна (Janet Perna) и Дон Хадерле (Don Haderle), которые являются старейшинами в области управления данными в фирме IBM и как управленцы, и как специалисты, просто замечательны.

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

Я с удовольствием работаю в такой организации, которая занимается разработкой и в которой от 30 до 40 процентов команды составляют женщины. Для индустрии в целом такая ситуация не является типичной. Я считаю, что пребывание в фирме IBM очень, очень ценно для меня и ко мне отнеслись там очень хорошо.

Раскрывая суть API серверных курсоров

В этой статье я попытаюсь объяснить сущность API серверных курсоров, предоставив краткий обзор того, что это такое, как определить, использует ли его распределенный запрос, и приведу пример простого распределенного запроса, снимающего необходимость в использовании курсора.

Недавно мне сообщили, что процесс, который выполняет распределенный запрос, выполняется дольше, чем ожидалось изначально. Сначала я определил, что распределенный запрос нагружал процессор, но загрузка памяти и интенсивность операций с диском увеличивались гораздо медленнее. Так медленно, что значения памяти и дискового ввода/вывода казались застывшими. Моей первой мыслью было, что это результат несуществующего/неверного индекса и/или сканирования таблицы. С помощью SQL Server Profiler я смог обнаружить загвоздку, но это был не индекс. В общем, распределенный запрос, который не отвечал, использовал тип курсора для возврата результатов на локальный сервер.

Что такое API Server Cursor

OLE DB провайдер для SQL Server (SQLOLEDB) использует один из двух методов для получения результатов распределенного запроса от удаленного сервера. Результирующий набор, создаваемый по умолчанию, будет получать результаты распределенного запроса от удаленного сервера в одном блоке. Другой метод для получения результатов распределенного запроса с удаленного сервера использует курсор, называемый API Server Cursor.

Безопасность SQL Server:
фиксированные роли базы данных

Фиксированные роли базы данных — это роли уровня базы данных. Некоторые из них разработаны для помощи в распределении административных полномочий, другие служат для предоставления общих разрешений конечному пользователю.

В статье «Безопасность SQL Server: серверные роли»1, я разобрал фиксированные серверные роли, присущие SQL Server 2000. Еще один набор ролей, доступный нам, — это фиксированные роли базы данных. Как подсказывает их название, это роли только уровня базы данных. Как и фиксированные серверные роли, некоторые из фиксированных ролей базы данных, такие как db_accessadmin и db_securityadmin, разработаны для помощи в распределении административных полномочий. Другие, такие как db_datareader и db_datawriter, служат для предоставления общих разрешений конечному пользователю. Вот список фиксированных ролей базы данных, доступных в SQL Server 2000:

•    db_accessadmin;

•    db_backupoperator;

•    db_datareader;

•    db_datawriter;

•    db_ddladmin;

•    db_denydatareader;

•    db_denydatawriter;

•    db_owner;

•    db_securityadmin;

•    public.

Так же как существует системная хранимая процедура для вывода списка фиксированных серверных ролей, есть подобная же процедура и для фиксированных ролей базы данных. Системная хранимая процедура sp_helpdbfixedrole вернет список всех фиксированных ролей базы данных, за исключением роли public. В то время как роль public является фиксированной ролью базы данных и показывается в Enterprise Manager, она все же не появляется в списке, возвращаемом хранимой процедурой (и в списке, приведенном в Books Online). Просто не забывайте добавлять ее мысленно. Другая системная хранимая процедура, sp_helprole, может быть использо­вана для вывода всех ролей базы данных для указанной базы и включает поле, показывающее, является ли роль ролью приложения или нет. Чтобы вывести разрешения для конкретной фиксированной роли базы данных, в нашем распоряжении есть системная хранимая процедура sp_dbfixedrolepermission. Эта системная хранимая процедура не обязательно точна на 100%, так же как и sp_srvrolepermission. Она возвращает большую часть, но когда сомневаетесь, обратитесь к Books Online.

Тонкая настройка дизайна базы данных в SQL Server 2005. Часть 1

Обзор инструментов для настройки индексов

В этой статье показано, как с помощью нового инструмента Database Engine Tuning Advisor определить оптимальный набор индексов в соот­ветствии с характером нагрузки на сервер, а также облегчить настройку и мониторинг индексов.

В настоящее время я работаю в Microsoft, и в мои должностные обязанности входит взаимодействие с покупателями SQL Server по всему миру, начиная с крупнейших финансовых институтов из списка Fortune 500 и заканчивая онлайн­магазинами и небольшими фирмами, основанными несколькими партнерами. В основном я занимаюсь настройкой производительности систем на базе SQL Server.

Когда в системе происходит спад производительности, а сроки поджимают (как это всегда и бывает), возникает искушение решить проблему на уровне «железа» — добавить памяти, заменить процессор на более мощный, увеличить объем и скорость работы дисковой подсистемы и так далее. Но проблема в том, что при наличии фундаментального просчета при проектировании вашей системы есть вероятность того, что ваше приложение будет непригодно для масштабирования: удвоение мощности процессора не приведет к удвоению производительности. Кончится все тем, что вы потратите кучу денег на оборудование, чтобы добиться приемлемого уровня производительности.

Вместо этого вам следует первым делом пересмотреть дизайн приложения, в частности стратегию индексирования, изменение которой дает максимальный результат в сочетании с минимальным воздей­ствием на систему и процессы в ней.

Когда вы отправляете запрос к SQL Server, оптимизатор запросов должен рассчитать для него наилучший план выполнения (с помощью внутренних алгоритмов подсчета стоимости), чтобы время реакции на запрос было минимальным. Если индексы, необходимые в процессе выполнения этого оптимального плана, отсутствуют, оптимизатор запроса вынужден выбрать менее оптимальный план, для которого есть подходящие индексы. Это приводит к возрастанию числа операций ввода­вывода и в результате к падению производительности. Поэтому пользу «правильных» индексов сложно переоценить.

Однако задача определения оптимального набора индексов не всегда решается просто. Для этого требуется хорошо знать, какие именно запросы будут выполняться в системе, распределение и объем данных, а также иметь представление, какой тип индекса способен удовлетворить ваши требования наилучшим образом. SQL Server 2005 здесь протягивает нам руку помощи (хотя это и не означает, что понимание больше не требуется): новый инструмент Database Engine Tuning Advisor поможет определить, какие индексы вам необходимы, а также облегчит настройку и мониторинг индексов.

В этой статье я продемонстрирую, как пользоваться этим инструментом, чтобы получить ответы на следующие вопросы:

•    Какие индексы необходимы для оптимизации моих запросов?

•    Как провести мониторинг использования индексов и их эффективности?

•    Как выявить избыточные индексы, которые могут негативно повлиять на производительность DML­запросов (операций insert, update и delete)?

•    Как по мере изменения характера нагрузки на систему выявить недостающие индексы, которые могли бы улучшить производительность новых запросов?

(Возврат на основную страницу)