Мэрианн Винслетт
Перевод Сергея Кузнецова

Добро пожаловать в эту часть серии интервью, публикуемых в ACM SIGMOD Record, с влиятельными членами сообщества баз данных. Меня зовут Мэрианн Винслетт, и сегодня мы находимся в Сан-Диего на конференциях SIGMOD и PODS 2005. Мы здесь с Пат Селинджер, которая в настоящее время является вице-президентом подразделения архитектуры и технологии баз данных компании IBM. Пат является основным автором одной из наиболее влиятельных статей, когда бы то ни было написанных в области баз данных: в ее статье, представленной на конференции SIGMOD в 1979 г., были сформулированы руководящие принципы, лежащие в основе оптимизаторов запросов всех современных систем баз данных. Пат также способствует тому, чтобы исследовательские инновации в IBM находили свое место в продуктах компании. Пат – почетный сотрудник IBM, она получила ACM SIGMOD Innovations Award и является членом National Academy of Engineering. Свою степень PhD она получила в Гарвардском университете. Итак, Пат, милости просим!

Большое спасибо.

Пат, System R и INGREC показали ретроградам, что можно построить реляционную систему управления базами данных с разумной производительностью. Будучи в первом составе команды System R, Вы присутствовали при рождении этой индустрии. Что больше всего поразило Вас при создании System R? Это те вещи, которые были впечатляюще правильными, или же те, которые были впечатляюще ложными?

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

Глядя в прошлое, что вы представляете ключевыми элементами, принесшими успех System R?

Я думаю, что тот факт, что в нескольких компаниях заметили язык SQL и начали его реализовывать, явился ключевым в становлении SQL повсеместным языком баз данных. И это стало важным компонентом при достижении успеха SQL. Второй очень важной вещью было то, что уже на ранней стадии проекта мы привлекли ряд компаний к использованию системы, и они использовали то, что мы создавали. В число этих первых пользователей входила компания Boeing, и они говорили: «System R – это потрясающий инструмент, но проблема в том, что еще только февраль, а мы уже исчерпали годовой бюджет компьютерного времени, выполнив так много запросов к базе данных! И я говорила: «О, мы так сожалеем, мы действительно сожалеем об этом». А они отвечали: «Нет, не стоит извиняться, System R замечательна. Мы можем задавать запросы, на которые никогда раньше не могли получить ответы. Мы теперь можем делать больше, чем могли когда-либо раньше». Так что я думаю, что повышение производительности разработки приложений благодаря использованию System R явилось огромным преимуществом для пользователей. И то, что у нас имелись клиенты, говорящие IBM о важности нашей работы, сильно отличалось от поддержки, которую мы получали внутри IBM.

Читателям может быть интересно, что в интервью с Брюсом Линдсеем я задала ему тот же вопрос, так что, когда его интервью будет опубликовано, они смогут увидеть другую интерпретацию причин успешности и влиятельности System R. Но я не буду раскрывать секрет и не скажу читателям, о чем говорил Брюс! Читатели должны подождать, пока не появится публикация интервью Брюса.

В то время, когда строилась System R, было невозможно понять, какое влияние этот проект окажет на мир, улучшит его или ухудшит. Глядя в прошлое, что бы Вы хотели сделать по-другому в System R?

Глядя в прошлое, я понимаю, что на самом деле у меня не было достаточной квалификации системного проектировщика и разработчика для осознания того, что люди внутри IBM ожидают от проекта появления законченного продукта, который можно было бы продавать. Поэтому, проектируя управляющие блоки, интерфейсы и API для языков программирования, мы всего лишь собирали вместе нечто, что, по нашему мнению, должно работать. Обработка ошибок, способы передачи в систему переменных и параметров – все это было спроектировано недостаточно продуманным образом, недостаточно внимательно и изящно. Все это работало, но мы не учитывали потребности расширения системы, ее роста со временем. Мы не думали о тысячах дополнительных типов данных, которые может потребоваться определять и представлять. Так что, глядя в прошлое, я хотела бы выполнить работу гораздо лучше, сделать ее гораздо более вдумчивым образом, чтобы интерфейс прикладного программирования System R более естественно соответствовал языкам программирования, в которых он используется.

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

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

Если бы Вы могли вернуться в то время, какого Вы бы пожелали организационного управления? Я задаю этот вопрос, потому что сегодня и в будущем исследователи будут находиться в похожих ситуациях, и Ваши комментарии могут быть им полезны. (К сведению читателей: имеется более подробное описание этих событий; в Web опубликован изумительный документ, произведенный в честь 20-летнего юбилея SQL (20-year System R Reunion). В документе приводятся многие факты из пленительной истории System R и даже QBE, и описываются взаимоотношения групп System R и INGRES.)

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

Внутри IBM QBE и System R часто считались конкурентами. Можно ли было лучшим образом уладить эту ситуацию?

Я не знаю, в чем состояла ошибка в управлении. Имелись две группы, работающие на разными аспектами схожих проблем, а некоторые люди думали, что имеет место конкуренция. Глядя в прошлое, я думаю, что работа группы QBE фокусировалась на пользовательских интерфейсах, на том, как люди могут формулировать запросы; они все это упрощали и выполняли простую работу. Работа над SQL и System R была более ориентирована на создание «тяжелых» вещей, и именно на них мы сосредотачивали усилия: на глубинной технологии, масштабируемости, производительности и т.д. В проекте QBE никогда не ставились такие задачи. Я думаю, что если бы эти обстоятельства были осознаны вовремя, то не было бы никакого ощущения конфликта.

Значит, люди почему-то не понимали, что проводились две работы: одна на пользовательском уровне, а другая---

Никогда не было состязаний или столкновений---

А как же перестрелка в OK Corral? (Читатели, интересующиеся перестрелкой в OK Corral, могут прочитать об этом в Web в документах, посвященных 20-летию SQL.)

Вы правы. Старею я. Это было состязание в производительности.

Которое не было справедливым---

В тех обстоятельствах производительность не являлась характеристикой, на которую следовало обращать внимание при сравнении этих двух систем. Мы пытались всего лишь «приклеить» интерфейс QBE к серверной части System R.

Да, и, конечно, System R должна была победить QBE в этом состязании. Так что я полагаю, что «склеивание» так никогда и не произошло, хотя---

Ну, нет, именно эту склейку мы проделали в продукте QMF, потому что интерфейс QBE и QMF поверх DB2 в действительности являлся набором продуктов, открывшим дверь для QMF. Так что склеивание было проделано, только в производственной, а не исследовательской лаборатории.

Понятно.

IBM исключительно удачлива в переносе результатов исследований в продукты. Много лет Вы надзираете за этим. В чем секреты успешного переноса технологий?

Когда я основывала Институт технологии баз данных, Database Technology Institute- исследовательская организация компании IBM, предназначенная для переноса технологии баз данных, я сделала две вещи. Я посетила всех менеджеров из сообщества разработчиков IBM и провела с каждым из них, как минимум, часовую беседу с глазу на глаз. Мы говорили с ними об их целях и проблемах, и я объясняла им, что собирается делать эта будущая группа, и как я собираюсь взаимодействовать с их группами. Это позволило сразу устранить фактор конкуренции. Вторая вещь заключалась в том, мы совместно разрабатывали идеи на собраниях, на которых мы говорили о том, над чем нам следует работать, какие проблемы важны для разработчиков и каковы должны быть наши планы в грядущем году. И у нас в исследовательской группе были люди, которые обитали в лабораториях разработчиков и проводили свое время в беспокойствах, содействии, соучастии и генерации идей совместно с разработчиками, так что исследователи, по существу, доказывали свое достоинство. Со временем все это уладилось, возникло взаимное доверие. Так что подобная групповая работа – это результат взаимного приспособления.

Ежегодная встреча: что говорили люди из производства исследователям о своих проблемах?

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

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

Да.

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

Целую неделю весь Институт технологии баз данных выслушивал презентации, и люди общались во время перерывов, обедов и т.д., чтобы лучше узнать друг друга. У нас происходили обсуждения типа «А что если применить этот подход для решения вашей проблемы?», «Я знаю, как подойти к вашей проблеме», «А что если подойти к вашей проблеме с этой стороны». И в конце недели люди лучше понимали в том, что могут предложить.

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

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

И еще одно: Вы упоминали устранение аспекта соперничества. Не могли бы Вы подробнее разъяснить чувства соперничества, которые могли бы развиться?

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

Что побудило Вас пойти на работу в индустрию и остаться в IBM, а не провести некоторое время на академической работе, основать свою компанию или работать на несколько компаний?

Я проходила интервью как в академических, так и в промышленных организациях. Я решила работать в Калифорнии, потому что прожила восемь лет в Бостоне, и там было так холодно, слякотно и снежно, а в Калифорнии – гораздо приятнее. Поэтому я решила, что хочу найти работу в Калифорнии. У меня были предложения от UC San Diego и т.д., и от IBM в San Jose. И я искала людей, с которыми могла бы работать, и работу, которую могла бы делать. Будучи научным сотрудником университета, я участвовала в проекте по созданию компилятора. Мне нравится быть частью коллектива. А в университете, по крайней мере, в то время, каждый профессор был сам по себе. Конечно, у профессора имеются аспиранты, они ему помогают, и профессор со своими аспирантами образуют группу, но это не то же самое, что иметь пятнадцать человек, всегда работающих вместе. Но все равно это время сильно воздействовало на меня и остается со мной до сих пор.

Вы не меняли компании, как другие люди из System R. Что побудило Вас остаться в IBM?

Мне нравятся люди. Прекрасные люди. Это основная причина. И мне нравится влияние, которое мы имеем в индустрии, и я вижу возможности для его расширения.

Я понимаю, что в IBM Вы сильно вовлечены в воспитательную работу. Что можно сделать, чтобы помочь свежеиспеченному PhD превратиться в исследователя, работа которого оказывает существенное влияние?

Я думаю, что молодому PhD трудно изменить склад ума индивидуального исследователя, который должен сам все придумывать и доказывать, что все сделано им лично, на образ мыслей члена коллектива в среде индустриальных исследований. Для некоторых людей этот переход затруднителен, потому что их не учили работать в коллективе. Они не понимают необходимости дисциплины методов разработки программного обеспечения в стиле «я добавлю свой код, только если это не испортит ваш код». В проектах, проводимых в исследовательских подразделениях, участвует от пяти до десяти человек. Однако, если вы начинаете работать с коллективом разработчиков в составе, скажем, Института технологий баз данных, вам, возможно, придется работать с 600-800 людьми и производить программное обеспечения для глобальных объектов, гораздо более крупных, чем можно поначалу охватить умом.

И как же Вы помогаете им произвести этот переход?

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

Вы были менеджером Джима Грея и Брюса Линдсея. Джим посоветовал мне спросить у Вас про секреты управления такими трудными людьми, как Брюс и он сам. Как Вы это делаете?

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

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

Ну, это--- Мне они просто нравились.

[Смущенно.] «Нравились» означает---

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

Но теперь Вы вице-президент, у Вас сотни подчиненных, и вряд ли Вам может лично нравиться каждый из них. И как же Вы справляетесь теперь?

По существу, я стала теперь коллективной мамой для 3000 человек в подразделениях разработки баз данных IBM, и они знают, что могут мне звонить. У них есть номера моих домашнего и сотового телефонов, они могут придти ко мне и поговорить частным образом о любых своих проблемах, и я помогу. Так что в моей ответственности забота о людях и содействие им, их карьере, их интересу к работе, расширению их кругозора и пониманию, что они являются частью коллектива. Я трачу огромную часть своего времени на сплочение людей и формирование у них взаимопонимания. При наличии взаимопонимания легко добиться всего остального. Итак, ни один из этих 3000 человек не работает лично на меня – хотя, возможно, человек 20 работает – и я не могу обеспечить это взаимопонимание для всех, включая начинающих программистов, которые приступили к работе на прошлой неделе. Я ограничиваюсь работой со старшими техническими руководителями – двумя высшими звеньями руководителей – а они продолжают делать это в своих коллективах.

Если у 3000 человек имеется номер Вашего домашнего телефона, то как часто Вам звонят на этот номер?

Одно-два email-сообщения в неделю. Когда я не командировке, почти за каждым ланчем я провожу воспитательную беседу то с одним, то с другим человеком. Я интенсивно наставляю примерно 30 человек. Кроме того, время от времени я провожу обсуждения текущих проблем с группами сотрудников.

А люди, которых Вы наставляете, отличаются служебным положением или принадлежностью к какой-то группе?

Я их не выбираю, это они выбирают меня.

О, они Вас выбирают. Понятно.

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

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

Я приняла это решение в начале своей карьеры и, возможно, слишком рано. Я стала менеджером и подверглась испытанию огнем, как Вы отмечали раньше, с Брюсом, Джимом и Франко, проработав в IBM всего три года и приняв участие всего в одном проекте – System R. Причина состояла в том, что я заметила, что могу сделать с группой гораздо больше, чем своими двумя руками. Так что мотивацией было именно это. Три года я была менеджером первой линии, работая над проектом распределенной базы данных R*, а затем взлетела на должность менеджера четвертой линии и четыре года возглавляла отдел компьютерных наук. Я думаю, что это восхождение произошло слишком быстро, хотя мне нравилась эта работа. Это было похоже на то, что ты ведешь в университете сразу 22 курса, потому что в отделе компьютерных наук велись 22 разных проекта в самых разнообразных областях – от теории до дисководов, принтеров и баз данных. Это было интересно, но не удовлетворяло меня настолько, насколько мне бы хотелось. Ты не можешь глубоко проникнуть в конкретную технологию и обнаруживаешь, что что-то упустила. Будучи менеджером отдела компьютерных наук, я создала Институт технологий баз данных. Чем больше времени я тратила на организацию института, тем чаще я думала «Я хочу эту работу»! И тогда я пошла к своему боссу и сказала: «Вы видите вон ту работу? Я ее хочу, я хочу сменить на нее свою текущую работу, потому что представляю, как все должно происходить, и знаю, что смогу заставить это работать». И таким образом я объединила свою способность к менеджменту с глубинной технологией, которую я люблю.

Так Вы можете указать на людей, которые в настоящее время переходят из исследователей в менеджеры?

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

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

Это было сделано умышленно. Случилось так, что в середине 90-х мы очень-очень опаздывали на тусовку баз данных на платформах UNIX и Windows. И я поехала в Торонто к Джанет Перна, которая в то время отвечала за создание продуктов баз данных на Windows и UNIX. Я пришла к ней и сказала: «Джанет, я тут получила исследовательскую группу, которая будет никому не нужна, если наши продукты не проникнут в пространство UNIX и Windows. Поэтому мы готовы взять свою технологию Starburst, отложить свои исследования и помочь вам построить этот продукт баз данных и выпустить его». И мы умышленно заставили исследователей заниматься разработкой продукта, и я думаю, что этим мы в корне изменили специализацию исследовательской группы. Есть некоторые люди, которые до сих пор любят копаться в коде текущего выпуска продукта. Так что у нас имеется эта крайность. С другой стороны, мы стараемся перетянуть назад некоторых людей из числа разработчиков, чтобы они занимались делами, которые под силу только исследователям. И это тоже очень продуманное решение – воспитывать новых исследователей, которые могут работать в разных областях. Но причины того, что нас воспринимают как очень сильно ориентированных на продукты, обусловлены традицией, тем, что мы должны это делать, чтобы оставаться конкурентоспособными, и чтобы исследовательский коллектив в области баз данных представлял ценность для IBM.

Пат, Ваша работа PhD была не из области баз данных. Может ли сегодня человек без базовой подготовки в области баз данных превратиться в исследователи в этой области?

Я думаю, да. Это особенно так в областях, подобных поддержке конфиденциальности, в которых, на самом деле, не требуется пятилетнее изучение упреждающей записи в журнал, 27 режимов параллелизма Мохана или методов семейства Aries.

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

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

Давайте взглянем на это понятие подсказок оптимизатору. Проблема с подсказками состоит в том, что люди не смогут вводить непредусмотренные запросы, если в комнату может вбежать администратор базы данных с криком «Не жмите пока на ‘enter’ и не вводите заключительную точку с запятой, дайте мне расставить подсказки в вашем запросе». Комплексные приложения от PeopleSoft, SAP, Seibel Systems и т.д. все являются заранее откомпилированными. Вы не можете добраться до этих запросов, вы не можете вставить подсказки в связи с устройством своих данных. Все это приводит нас к ситуации, в которой при постоянно растущем наборе запросов невозможно пользоваться подсказками. Поэтому мы вынуждены продолжать инвестировать исследования в области оптимизации запросов.

А нет ли какого-нибудь способа передавать подсказки в эти заранее собранные пакеты, чтобы они могли «на лету» обрабатывать различные ситуации?

Ну, подсказки всегда могли бы вставить сами производители приложений: «Если Oracle, то …; если DB2, то …;» и т.д. Но что-то я не вижу, чтобы они собирались это делать. Независимые поставщики программного обеспечения не хотят знать зависимость эффективности выполнения запросов от данного контекста. Они не знают, какого размера будут таблицы розничных и оптовых продаж, насколько большой будет таблица трудовых ресурсов.

Я подумала, что во время выполнения пакету могли бы передаваться в качестве подсказок статистические данные или информация о физической организации данных, а пакет мог бы компилироваться таким образом, чтобы выполнялся правильный план---

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

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

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

Я натолкнулась на Вашу фотографию времен начала проекта System R. На ней Ваш образ окутан сиянием, и Вы явно не соответствуете стереотипу исследователя в области компьютерных наук 1970-х: нет засаленных волос, нет логарифмической линейки, нет даже очков. Труднее или легче стало с годами жить людям, не соответствующим стереотипам?

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

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

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

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

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

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

Безусловно, именно так.

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

Я думаю, что мне хотелось бы знать побольше про аппаратуру.

[Удивленно.] Про аппаратуру?

Да. Это та область, которую мне хотелось бы изучить более основательно.

Как бы это воздействовало на то, что Вы делаете? Как бы это воздействовало на Ваше мышление?

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

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

Да.

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

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

Большое спасибо, Пат.

Пожалуйста. Я с удовольствием с Вами пообщалась.