Из беседы Пат Селинждер из IBM и Джеймса Гамильтона из Microsoft можно почерпнуть все, что вам хотелось бы знать про технологию баз данных, но о чем вы не удосужились осведомиться.

Селинджер, почетный сотрудник IBM и вице-президент по стратегии в области баз данных, информации и взаимодействиям с IBM Research, приводит в действие стратегию исследовательских работ, от исследований в области классических систем баз данных до работ в области мультимодальных взаимодействий. После получения степени PhD в Гарвардском университете она почти 30 лет работает в IBM, разделяя свое время между исследованиями и разработкой продуктов управления базами данных IBM.

Поступив на работу в IBM в 1975 г., Селинджер стала ведущим членом группы, которая разрабатывала System R, первое доказательство практической значимости технологии реляционных баз данных. Ее новаторская работа в области оценочной оптимизации запросов была признана почти всеми поставщиками реляционных баз данных. В 1986 г. она основала Институт технологии баз данных (Database Technology Institute) для выполнения совместной программы между IBM Research и группами по разработке программного обеспечения для ускорения процесса передачи в продукты технологии, разработанной в ходе исследований. В 1997 г. она перешла из IBM Research в ту часть компании, которая занимается разработками, и заняла пост вице-президента по архитектуре управления информацией и технологии в IBM Silicon Valley Lab в Сан-Хосе, Калифорния. Кроме того, она возглавляла разработку технологии для следующего поколения систем управления данными. Свою текущую позицию она занимает с 2004 г.

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

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

Джеймс Гамильтон: Давайте начнем разговор с роли оптимизаторов запросов в системах управления базами данных и Вашего изобретения оценочных оптимизаторов.

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

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

Ориентированность на множества языка запросов позволяет запрашивать данные обо всех программистах, работающих в отделе 50, или данные обо всех заказах, стоимость которых превышает $5,000, или данные о всех заказчиках из Сан-Хосе, у которых имеются заказы со стоимостью более $5,000, и т.д. Информация в реляционных таблицах может по-разному комбинироваться на основе только значений.

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

Оптимизаторы запросов представляют собой технологию, позволяющую добиться работоспособности этого высокоуровневого языка программирования – языка доступа к базам данных. Без этого приходилось бы пользоваться грубой силой: выбирать каждую строку каждой таблицы и проверять, соответствует ли она описанию искомых данных. Действительно ли у данного отдела номер 50? Действительно ли стоимость данного заказа превышает $5,000? Было бы очень неэффективно просматривать каждый раз все данные.

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

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

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

ПС: Качество оценочной оптимизации позволяет людям производить разработку приложений с относительно небольшими затратами ручного труда. Другими словами, разработчику приложения не требуется знать массу информации о размещении данных на диске, о точных местах расположения записей и о точных путях доступа к этим записям. С точки зрения обеспечения эффективности приложений возможность наличия действительно качественного оценочного оптимизатора запросов является огромным плюсом. Так что у рынка имеется существенная потребность в наличии хорошей оптимизации запросов. Я участвовала в создании оптимизатора System R, который был целиком перенесен в реляционный продукт IBM DB2, где он постоянно совершенствуется. От многих упрощающих предположений, которые были приняты для облегчения решения проблемы в конце 1970-х гг., удалось отказаться, модель теперь является более глубокой и развитой и включает большее число методов доступа к данным.

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

У технологии оценочной оптимизации запросов все еще имеется простор для роста, например, для лучшего учета тех ситуаций, когда поведение данных отличается от того, которое предполагается в модели. Во многих оптимизаторах недостаточно правильно моделируются данные, обладающие высоким уровнем корреляции. Например, во всей Калифорнии используется почтовый индекс 90210. Значения почтового индекса не распределены по штатам равномерно, и ни в каком другом штате США код 90210 не используется. Указание в пользовательском запросе значения почтового индекса, равного 90210, является достаточным, и применение дополнительного предиката, такого как «название штата – это Калифорния», не изменяет результат. Это не приведет к сокращению числа строк, потому что единственным штатом с почтовым индексом 90210 является Калифорния.

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

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

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

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

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

ПС: Безусловно. Для нас это новая обширная область. У компаний имеется много данных, которые достаточно хорошо структурированы – записи о заказах, потребителях, служащих, но эти данные составляют, может быть, 15% всех данных компании. Оставшуюся часть составляют файлы документов, XML, фотографии, Web-страницы – всей этой информацией тоже нужно управлять.

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

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

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

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

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

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

ДГ: Вы все время концентрируетесь на снижении стоимости администрирования. А что насчет стоимости разработки?

ПС: Имеются два аспекта самоуправляющихся вычислительных систем: один – это разработка приложений, а второй – администрирование. На арене разработки приложений пользователи хотят иметь общий набор инструментальных средств. Поэтому IBM активно способствует сообществу open-source в разработке платформы Eclipse и поощряет участие людей в развитии этой платформы – чтобы можно было иметь один набор инструментальных средств и навыков, позволяющий людям вести разработки для разнообразных платформ. Средства высокоуровневого программирования – такие как XQuery, стандарты SQL, Enterprise JavaBeans и объекты COM – способствуют быстрой разработке приложений на основе сборки строительных блоков взамен простого кодирования для обеспечения навигационного доступа к данным.

ДГ: Мне кажется странным, что индустрии, в которой мы работаем, уже почти 30 лет, а наша беседа показывает наличие в ней огромного числа нерешенных проблем.

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

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

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

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

ДГ: Можете ли Вы описать какие-нибудь проекты, в которые вовлечены в настоящее время?

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

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

ДГ: Настало время перестать уделять внимание только структурированным хранилищам, поскольку, как Вы заметили, реляционные системы в настоящее время управляют менее чем 15% корпоративных данных. Я мог бы утверждать, что за пределами мира корпоративных данных мы обнаружили бы, что в реляционных базах данных хранится менее 5% всех данных. Забавно, что при этом в реляционном мире мы успешно управляем почти всеми структурированными данными, в то время как управление менее структурированными данными остается почти невспаханным полем.

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

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

ДГ: Каковы проблемы внешнего мира, над которыми Вы работаете в настоящее время, – в особенности, те, которые имеют отношение к нетрадиционным типам данных, таким как фотографии, видео и голосовые данные? Где Вы видите крупные исследовательские проблемы для следующего десятилетия?

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

ДГ: Имеются ли какие-нибудь еще области, которые, по Вашему мнению, недостаточно исследованы, и к которым нам следовало бы проявлять больший интерес?

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

ДГ: Имеются ли, по Вашему мнению, области, которые уже чрезмерно исследованы?

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

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

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

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

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

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

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

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

ДГ: Ожидаете ли Вы, что XML будет играть более фундаментальную роль в системах управления контентом?

ПС: Я вижу, что заказчики очень интересуются XML, и многие из них уже сегодня используют формат XML для обмена. Я вижу, что заказчики желают иметь поддержку XML внутри самого сервера баз данных. Поэтому IBM выполняет специальную, «естественную» реализацию XML внутри DB2 для платформ Linux, Unix, Windows и z/OS.

Если заказчик посылает форму заказа в представлении XML, может оказаться разумным сохранить ее в этом формате в базе данных и пользоваться ею без преобразований в другие форматы. Мы можем также перевести XML в реляционный формат, если дальнейшая обработка этих данных будет в основном реляционной. Это стратегия «за двумя зайцами погонишься, ни одного не поймаешь» (have-your-cake-and-eat-it-too). DB2 может сохранять данные в формате XML, поддерживает их анализ, поиск и доступ к ним, а может перевести их в реляционную форму и выполнять над этими данными все транзакции, которые были ранее созданы для реляционных систем.

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

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

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

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

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

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

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

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

Как обнаружить звонок Осамы бин Ладена в потоке данных с использованием таких методов, как семантический анализ, распознавание голоса, автоматическое преобразование речи в текст и языковой перевод?

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

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

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

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

ДГ: Мы начали более серьезно относиться к роли open source в серверных вычислениях. В области баз данных у нас теперь имеется несколько конкурентов из мира open source. Насколько подход открытых кодов подходит для мира баз данных?

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

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

ДГ: Я знаю, что Вы всегда очень серьезно относитесь к своим обязанностям наставника – способствуя росту и преуспеванию следующего поколения. Понятно, насколько это важно, но ведь очень трудно хорошо выполнять эту работу. В чем Ваш секрет?

ПС: Некоторые люди смеются надо мной и говорят, что я наставничество меня кормит. Я думаю, что люди гораздо более свободно говорят, попивая пиво или кофе, или во время ленча, и поэтому я выполняю все свои менторские обязанности во время еды в кафетерии, в баре или за обедом. Это создает более комфортную обстановку для разговора о том, что на самом деле они думают. Под моим присмотром находится около 30 мужчин и женщин, из которых примерно две трети женщин. Каждый ленч, если у меня нет в это время других дел, я трачу на наставничество.

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

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

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

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

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

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

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

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

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