Джим Грей высказывается

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

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

Джим Грей старше меня всего на пять лет. Однако сложилось так, что всю свою сознательную жизнь я у него учился. Все началось со статей, посвященных проекту System R. С 1975 г. Джим являлся соавтором всех статей, так или иначе связанных с управлением транзакциями и восстановлением баз данных после сбоев. Эти статьи научили нас двухфазному протоколу синхронизационных блокировок, гранулированным и предикатным блокировкам, принципам журнализации и восстановления. В 1977 г. Джим написал большую обобщающую статью «Notes on Data Base Operating Systems». Эта статья позволила мне и моим коллегам упорядочить свои представления о структуре и функциях ядра СУБД и во многом способствовала выполнению нашего собственного проекта GNU SQL Server. Более того, когда некоторое время тому назад один из моих студентов сделал по этой статье доклад на семинаре, мы обнаружили, что в несколько устаревшей терминологии в статье содержатся все основные идеи, на которые опирается современная теория транзакций. Позднее, в 1993 г. Джим Грей совместно с Андреасом Рейтером написал книгу «Transaction Processing: Concepts and Techniques», которая является одной из наиболее авторитетных книг в области обработки транзакций и остается бестселлером на протяжении 14 лет. В 1998 г. за свои работы в области управления транзакциями Джим Грей получил Тьюринговскую премию.

Научные достижения Джима далеко не исчерпываются его работами в области транзакций. В частности, он внес существенный вклад в становление и развитие технологии ROLAP, предложил, в частности, операции GROUP BY ROLLUP и GROUP BY CUBE.

Джим Грей является очень разносторонним и увлекающимся человеком. Одно из его увлечений связано с яхтами. В течение многих лет он является заядлым яхтсменом. В воскресенье, 28 января 2007 г. он в одиночку отправился на традиционную воскресную прогулку на своей яхте Tenacious. С тех пор никто не видел ни его яхту, ни его самого. Множество людей занималось и продолжает заниматься поисками Джима. Поддерживаются специальные Web-сайты http://www.helpfindjim.com/ и http://openphi.net/tenacious, на которых публикуются последние новости и инструкции для добровольцев, желающих помочь найти Джима Грея. Все мы продолжаем надеяться на благополучное завершение поисков.

В 2002 г. Джим Грей дал интервью Мэрианн Винслетт для журнала ACM SIGMOD Record. Конечно, его нужно было давно перевести на русский язык и опубликовать в Internet, но сам я прочитал это интервью сразу после публикации и на этом успокоился. Теперь я исправляю свою ошибку. Интервью позволяет достаточно близко познакомиться с Джимом Греем, оценить его человеческую неординарность и роль в сообществе баз данных и компьютерной науки в целом. Научные работы Джима не раскрывают его так ярко, как это интервью, в котором он предстает научным новатором, пренебрегающим спокойной работой и безопасными играми. Приятного вам знакомства с Джимом Греем, и дай ему Господь всего лучшего!

Сергей Кузнецов

Добро пожаловать в этот выпуск серии интервью ACM SIGMOD Record с выдающими членами сообщества баз данных. Для этого интервью мы собрались в Мэдисоне, шт. Висконсин, месте проведения конференций PODS и SIGMOD в 2002 г. Рядом со мной Джим Грей, получивший в 1998 г. Тьюринговскую премию за вклад в компьютерную науку, в особенности, в области обработки транзакций. Джим является членом Президентского консультативного комитета по информационным технологиям, который консультирует Президента США по техническим вопросам, и членом консультативного комитета Библиотеки конгресса США. Джим получил степень PhD в Беркли в 1969 г. и работал в IBM, Tandem, DEC, а теперь работает в Microsoft Research. Итак, добро пожаловать, Джим.

Рад встретиться с Вами. Спасибо.

Все мы рады тому, что Вы согласились дать интервью.

Недавно, в феврале 2002 г. в интервью FTP Вы сказали: «мы гонимся за объектно-реляционной радугой и находимся неподалеку от золотой жилы». Другие люди говорили мне, что объектно-реляционные продукты оказались не столь успешными на рынке, как ожидалось. В чем здесь дело? Не выполнена какая-то часть исследований, объектно-реляционной технологии не хватает приложений-«приманок», или же мы неправильно поняли рынок?

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

В середине 1980-х гг. целая группа начинающих компаний начала делать объектно-реляционные системы. Свою работу они мотивировали потребностью в устранении «потери соответствия» (impedance mismatch) и необходимостью инкапсуляции. Они приводили очень правильные аргументы в пользу того, что в базе данных нужно хранить объекты, а не просто числа, символьные строки и BLOB’ы. Все эти аргументы были существенными. Они были корректными. Но, честно говоря, имелась потеря соответствия между продуктами, которые делали эти люди, и реальными проблемами пользователей. Ребята из области объектно-ориентированных баз данных (ООБД) нормально поработали над объектами – на самом деле, здорово поработали, но не добились настолько же хороших результатов при управлении данными на дисках, обработке транзакций, обеспечении безопасности и т.д. Тем временем, IBM, Oracle, Microsoft в некоторой степени перехватили инициативу, говоря, что и в их базах данных можно хранить объекты, и что они обеспечат эту возможность. Хотя это может показаться странным, но то, что происходит в настоящее время, началось с унификации языков и баз данных с вещами, подобными SQL-J и ADO. Это позволило обеспечить для баз данных неплохую объектную модель. Под этим я понимаю то, что теперь мы можем дать хорошие ответы на вопросы: «Что за объект представляет собой база данных?»; «Какого рода объекты производятся в базе данных?». И наоборот, имеется неплохая объектная модель для представления того, как встраиваются объекты в реляционные системы. Прямо сейчас эти вещи не очень-то стандартизованы, но я думаю, что в стандарте SQL следующего десятилетия или в каком-то предшественнике этого стандарта объекты будут полностью специфицированы.

С объектно-реляционным миром меня больше всего сближает деятельность ребят из Microsoft. Они интегрируют с системой баз данных систему поддержки времени выполнения универсального языка, так что можно написать программу на каком угодно языке, и ее можно будет запускать как хранимую процедуру внутри базы данных, где она сможет обрабатывать записи и поля записей с использованием объектной модели, основанной на множествах записей. Я считаю, что люди в Oracle и IBM делают похожие вещи для СУБД Oracle и DB2 соответственно.

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

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

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

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

Я занимался диссертацией во время становления компьютинга. Это было в конце 1960-х гг., и тогда происходило бурное развитие области операционных систем. На самом деле, в то время я работал над объектно-ориентированной операционной системой и свое свободное время проводил с людьми типа Батлера Лэмпсона (Butler Lampson), Дейва Редела(Dave Redell), Пола МакДжонса (Paul McJones), Чарльза Симони (Charles Symoni), Ховварда Старджиса (Howard Sturgis) и Брюса Линдсея (Bruce Lindsay). Я также работал над имитационной системой для моделирования городских систем с целью совершенствования планирования развития городов. Я делал массу различных вещей, но при выборе темы диссертации решил, что проще сделать ее теоретической.

После завершения работы над диссертацией я счел удовлетворенным свой интерес к теории и продолжил работу над системами. В течение двух лет я был постдоком в Беркли, а затем перешел на работу в IBM Research в Йорктауне.

Вы спросили меня: «Как ты попал из области систем в область систем баз данных?», и этот вопрос является очень интересным. Менеджер моего менеджера Леонард Лу (Leonard Lu), который был очень хорошим парнем и очень хорошим менеджером, однажды зашел ко мне в рабочую комнату. В то время я работал над операционными системами. Он сказал: «Знаешь, Джим, у нас есть куча операционных систем, но нет ни одной хорошей сетевой системы, и нет ни одной хорошей системы баз данных. Так что, если ты действительно хочешь принести пользу IBM, было бы здорово, если бы ты работал над улучшением систем баз данных или сетевых систем». Я выслушал это и обдумал. И на самом деле я работал над вещами, которыми занималась масса других людей, и у меня не было действительно хорошей идеи по совершенствованию операционных систем. Я работал в области объектно-ориентированных операционных систем (по-другому мы называли их мандатными операционными системами, capability based operating systems), и у меня было ощущение, что это направление оказалось не по силам для крупнейших специалистов, системы не слишком хорошо работают. Так что я поступил естественным образом: начал заниматься операционными системами баз данных.

Значит ли это, что в System R имелся Ваш код?

Да, я действительно работал в группе System R. В число моих задач входили структуризация процессов, работа с виртуальной памятью, авторизация и т.д. Потом я сконцентрировался на проблемах управления параллелизмом и восстановления, решение которых позволяло сделать системы постоянно доступными и обеспечить прозрачность параллелизма с точки зрения пользователей. По-существу, Реймонд Лори (Raymond Lori) занимался всем вводом-выводом и обеспечивал низкоуровневый блочный интерфейс, а я – всей конфигурацией, запуском, структурой процессов, блокировками, журнализацией и межпроцессными взаимодействиями. Все это делалось в среде VM/370 с использованием простого языка PLS.

А что это за история о надписи, сделанной Вашим менеджером на Вашей двери?

Одна из вещей, которым меня научил мой научный руководитель Майк Харрисон (Mike Harrison), состоит в том, что все нужно записывать. Поэтому после каждой командировки я пишу о ней отчет, и после каждого разговора с людьми, если в нем возникает какая-то идея, я пишу памятку о нашей дискуссии, чтобы ее задокументировать. В результате я исписывал кучу бумаги и ездил на массу конференций. Вследствие всего этого я стал очень знаменит благодаря работе других людей. Это несправедливо, но такова жизнь. Вы знаете, я всегда говорю людям, что эта идея принадлежит Франко Пуцолу (Franco Putzolu), а вот эта – Ирву Трэйджеру (Irv Traiger), я об этом не забываю и т.д. Но, поскольку я все записывал и выступал, я получил в мире известность вне своей группы.

В конечном результате я являлся в большей степени исследователем, чем разработчиком, и когда мы выполняли проект System R, Франко писал в год 20000 строк работающего кода, а я только 10000. В проекте предусматривалась сдача промежуточных этапов, менеджеры желали демонстрировать прототипы, и для их обеспечения на разработчиков оказывалось существенное давление. Однажды мой босс вошел ко мне в комнату и прицепил к двери табличку с надписью «Делай быстрее код». Его слегка пугала продолжительность времени, которое я тратил на написание статей, разъезды и слоняние без дела. А на самом деле, я кодировал слишком быстро. Я плодил массу ошибок. [Смеется] Но в ходе проекта System R я написал от 50 до 70 тысяч строк кода. Управление параллелизмом, восстановление, запуск системы, безопасность и администрирование – это те части системы, над которыми я работал, большей частью, те части, которые относятся к уровню RSS.

Являются ли эти основные темы ядра СУБД исчерпанными, или они заслуживают дополнительных исследований?

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

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

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

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

Проблема, с которой сталкивались люди в ту эпоху, заключалась в том, что они создавали специализированную аппаратуру, и к тому времени, когда она становилась работоспособной, аппаратура общего назначения уходила далеко вперед, и эти люди в действительности не получали над ней серьезного преимущества. А позднее, во-первых, диски стали очень емкими и очень дешевыми. Во-вторых, если посмотреть на дисковое устройство, то в нем, конечно, имеется диск, головка и некоторые механические вещи; но, кроме того, в нем обычно имеется печатная плата с процессором, памятью и интерфейсом к сети (в настоящее время это IDE или SCSI). Эти сети являются проприетарными, или специализированными сетями, такими как оптоволоконные SCSI, ATA, и этот сетевой интерфейс можно заменить на что-нибудь вроде Ethernet. Так что внутри каждого дискового устройства имеется процессор с рабочей частотой в несколько мегагерц, вероятнее, в несколько сотен мегагерц с несколькими сотнями мегабайт основной памяти (я думаю, так будет через несколько лет) и сетевым интерфейсом.

Конечно, можно захотеть, чтобы это дисковое устройство сообщало об ошибках, можно захотеть иметь возможность конфигурировать его и общаться с ним, поэтому потребуется наличие в этом устройстве небольшого HTTP-сервера и Web-интерфейса к нему, чтобы было можно задавать вопросы через Web-сервисы, или через SOAP, или через что-то подобное. Поэтому внутри этого дискового устройства находится операционная система с сетевым стеком и стеком Web-сервера. И оказывается, что этот процессор в дисковом устройстве является намного более мощным, чем процессоры, на которых разрабатывались Sybase, Oracle и DB2 в конце 1980-х. Поэтому внутри этого дискового устройства вы реально можете запустить любую систему баз данных. И конечно, там можно раскрутить любую операционную систему. Так что внутри этих дисковых устройств можно разместить программное обеспечение общего назначения, и, на самом деле, я думаю, что в этом имеется большой смысл, поскольку нам нужно оптимизировать дисковые рычаги. В нашем мире дисковые рычаги являются наиболее ценным ресурсом. Стоимость электроники стремится к нулю. Реальную стоимость имеют только физические компоненты. Я думаю, что, если сделать дисковые рычаги более интеллектуальными, мы сможем заставить диски работать лучше.

Несколько лет тому назад несколько человек подготовило диссертации (Эрик Рейдел (Eric Reidell) в CMU, Ким Китон (Kim Keaton) в Беркли), в которых показывалось, что 200 мегагерц вполне достаточно для того, чтобы поддерживать занятость диска при выполнении любого из имеющихся эталонных тестовых наборов для систем баз данных. Нет сомнений, что еще через несколько лет дисковые устройства будут обладать более чем достаточными процессорной мощностью и емкостью, чтобы на них можно было выполнять все программное обеспечение баз данных, имеющееся сегодня. И поэтому я думаю, что постепенно стек программного обеспечения будет перемещаться в дисковые устройства.

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

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

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

Да, самоорганизующиеся системы. IBM использует для этого термин самонастраивающийся компьютинг (autonomic computing). Ребята из мира PC предпочитают говорить plug and play.

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

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

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

Конечно, следует думать о версионности. Почти 20 лет тому назад Дейвом Ридом (Dave Reed) была выполнена совершенно блестящая работа по созданию системы под названием Swallow. В это время на CD можно было производить только однократную запись. В Swallow никогда ничего не перезаписывалось. Это была объектно-ориентированная база данных, и она всего лишь перебрасывала объекты в буферный пул. Время от времени в пул попадала запись о фиксации, и тогда транзакция фиксировалась. В Swallow при объектах поддерживались временые промежутки, в течение которых они были действительными. При выполнении операции модификации объекта завершался период действительности текущего значения изменяемого объекта, и создавался новый объект с новым стартовым значением периода действительности. Так что в этой области имеются интересные работы, которые немного напоминают интеллектуальные диски, немного – объектно-ориентированные базы данных. Есть такие идеи, которые были плохими в прежнее время и стали хорошими сейчас из-за изменений в технологии.

Но ведь Майк Стоунбрейкер в своем основном докладе на конференции SIGMOD 2002 только что сказал, что мультиверсионный подход не работает, поскольку он слишком медленный.

На самом деле, он сказал, что реализация «пылесоса» (vacuum cleaner) в POSTGRES в 1996 г. не была успешной. (В POSTGRES никакие данные никогда не перезаписывались, и «пылесос» отвечал за очистку памяти, занятой предыдущими версиями объектами.) Мы же говорим о периоде с 2006 по 2016 гг. Я достаточно тщательно слежу за ценами на диски, и эти цены сократились в сто раз с тех пор, как провалилась идея «пылесоса». За это время стоимость дисковых рычагов сократилась в десять раз. Эти соотношения действительно меняют ситуацию. Так что, во-первых, следует ли нам сохранять несколько версий данных? Безусловно! Нужно ли организовывать их в духе POSTGRES? Возможно, нет. А как нужно их организовывать? Хороший вопрос. Мне это кажется хорошей исследовательской темой.

Вы активны в области баз данных почти 30 лет. Просуществует ли эта область еще 30 лет?

Думаю, что нет. У нас, людей из области компьютерной науки, имеется патент на байт и алгоритм. У нас есть патент на информацию. И мы, люди из области компьютерной науки, занимаемся информацией и алгоритмами. В области баз данных мы занимаемся достаточно ограниченными вещами по отношению к своему патенту; в настоящее время мы занимаемся SQL. Мы не занимаемся, например, отображением или визуализацией данных. Но «MOD» в аббревиатуре «SIGMOD» означает управление данными (management of data). С моей точки зрения управление данными должно включать получение, хранение, организацию, анализ, представление данных – в особенности, представление. Мы много сделали в части запросов, но мы устанавливаем эпсилон-окрестность вокруг темы запросов и не слишком рискуем выходить за пределы этой окрестности. Если мы продолжим это делать – и это снова возвращает нас к комментарию Майка Стоунбрейкера, если мы продолжим ограничивать свою деятельность, наша область умрет, поскольку то, чем мы занимаемся, является все менее и менее существенным для остального мира. Если мы пойдем по пути экуменизма и будем считать, что мы управляем информацией, то эта область не будет умирающей. Мы пресыщены информацией. Очень многие люди говорят, что им нужно всего лишь больше времени. Нужно научиться собирать, анализировать, упрощать данные и предоставлять людям в точности ту информацию, которую они хотят получить, а не всю информацию, которая им доступна. Я не думаю, что эта проблема близка к разрешению. Мне кажется, что она становится все более и более острой. Поэтому, если посмотреть на SIGMOD с расширенной точки зрения, то я думаю, что базы данных являются растущей исследовательской областью. Если взглянуть на это с узкой точки зрения, то мне кажется, что многие вещи, которые делаются в настоящее время, не окажут большого влияния на людей в течение следующих 30 лет, в особенности, те вещи, которые связаны с производительностью. Опять же, если вернуться к трансцендентным функциям, я больше не подсчитываю число команд. Я считаю число обменов с дисками, но, возможно, наступит день, когда я перестану считать и это.

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

Позвольте мне усомниться в Вашей постановке вопроса. Исследования в направлении применения естественных языков для формулировки запросов к базам данных оказались гораздо более связанными с естественными языками, чем с базами данных. Но Query by Example дал людям зрительный образ запросов, и Query by Example привел к появлению VisiCalc, первой программы для работы с электронными таблицами. Ни один человек, который видел QBE (предшествовавший VisiCalc), а затем видел VisiCalc, не смог бы сказать, что они основаны на разных идеях. Идеи QBE привели к появлению многих продуктов и новых идей. Слияние технологий VisiCalc и баз данных пока еще не произошло, но работа ведется. Это отличная область исследований.

Большим шагом вперед явилась общая идея непроцедурного языка программирования. Целью разработки SQL, подобно COBOL, было облегчение программирования. Можно придираться к разработчикам SQL по поводу их недостаточной активности или недостаточного воображения. Но SQL явился реальным шагом вперед по сравнению с языками программирования, подобными PL/1, или моделями доступа к данным, подобными модели CODASYL, которая вышла из DBTG. Я думаю, что мы явно готовы к следующему шагу. По сравнению с FORTRAN, ALGOL, COBOL и PL/1 XQuery находится ближе к траектории SQL. XQuery является непроцедурным, так что находится на уровне, выше FORTRAN и ALGOL, но при этом он на два-три порядка лучше SQL. Я думаю, что в силу закона Мура при имеющейся относительной стоимости людей и компьютеров мы готовы достаточно радикально отойти от используемых в настоящее время способов формулировки запросов к базам данных, но я не знаю, что придет им на смену.

Это был мой следующий вопрос.

У меня нет плана интервью. Но действительно очень многие люди считают Query by Example, VisiCalc и их преемников очень полезными. Очень успешным продуктом является Microsoft Access, а он во многом основан на идеях QBE и их обобщении. Поэтому я думаю, что некоторый визуальный интерфейс, с помощью которого можно оперировать объектами, осмысленными для пользователей, сделал бы базы данных доступными для гораздо большего числа людей.

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

Я немного стесняюсь.

Вы можете ничего и не рассказывать.

Но это забавно. Это забавно.

Я романтик. Я полагаю, что человек должен жить полной жизнью; в жизни должны сочетаться работа и игра. У меня была эта фантазия по поводу яхты, что мне нужно купить яхту и плавать на ней. И я купил яхту и прожил на ее борту десять лет. Сразу после покупки яхты я пошел в библиотеку и взял книгу о плавании на яхте. До этого я никогда не плавал на яхтах. Одной из неожиданностей явилось то, что нужно иметь место для парковки яхты. Когда вы покупаете автомобиль, вы не беспокоитесь о месте для парковки; но в случае яхты вам нужно арендовать слип.

И я начал искать слип. Я приплыл в очень симпатичную бухту для яхт и сказал, что мне нужен слип. Парень сказал «All right» и дал мне бланк для заявления. Я заполнил его и спросил, сколько времени нужно ждать? Он ответил: «Ну, от 15 до 25 лет». Я понял, что это не сработает. Я снял слип в довольно неопрятном месте поблизости от сахарной фабрики, что было совсем не тем соседством, какого мне хотелось. Я практиковался в плавании на яхте в дельте реки Аламеда – хорошее место для того, чтобы учиться плавать на яхте.

Однажды я сказал себе: «Забудь об этом – я собираюсь перебраться в Сан-Франциско». И я отдал швартовы и отплыл в Сан-Франциско. Я пришел к капитану порта и сказал: «Смотрите, я швартуюсь здесь у крайнего причала. Вот мой номер телефона. Сдайте мне это место в аренду посуточно. Если Вы захотите, чтобы я убрал яхту, просто позвоните мне, и я отплыву в течение трех часов.» Они обязаны предоставить вам аренду на краткий срок. И моя яхта оставалась там в течение трех месяцев.

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

Теперь у меня было две яхты, что было не слишком удобно, и поэтому мне нужно было избавиться от SouSea. Она действительно тонула, и я не хотел, чтобы она затонула у причала. Проблема состояла в том, что нужно было от нее избавиться. Вообще-то нужно было позвонить в Береговую охрану, и они бы ее забрали, но тогда я этого не знал. Поэтому поздно ночью мы с Брюсом Нельсоном (Bruce Nelson), известным благодаря работам по RPC, и еще несколькими людьми стали буксировать яхту моторной лодкой в направлении Алкатрас. Я перебрался на SouSea с небольшим топориком и стал прорубать отверстие в днище. Ночь была черная как смоль. Когда я снова поднялся на палубу, оказалось, что Брюс вместе с выпившими друзьями уплыли на своей моторной лодке, а я остался на тонущей яхте посередине залива Сан-Франциско в абсолютной темноте! Я не думаю, что мои друзья полностью осознавали тот факт, что невозможно найти что бы то ни было, если его совсем не видно. Я сделал это. Итак, я сидел на тонущей яхте, и, к счастью, яхта слегка раздумала тонуть. Мои друзья плавали в поисках меня, поскольку шутки кончились. Я сидел, крича и медленно погружаясь в воду. Это была интересная сцена. Но они вернулись, и мы приплыли на опустевший слип после того, как SouSea окончательно затонула.

Я догадалась, что они вернулись, потому что сегодня Вы здесь с нами. И Вы здорово их отругали?

Да нет. Я только посмеялся надо всем этим, и они тоже.

Какая из Ваших прошлых исследовательских работ Вам более всего дорога?

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

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

Имеется ли у Президентского консультативного комитета по информационным технологиям (PITAC) устойчивое влияние?

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

Одним из комитетов, в которых я состою, является Президентский консультативный комитет по информационным технологиям, чаще называемый PITAC, и этот комитет, по существу, сказал: «Тратьте деньги на исследования в области информационной технологии». И он объяснил, почему следует тратить на это деньги. Комитет обязан своему существованию некоторым людям из правительства, и поэтому у нас имеется восприимчивая аудитория. И эта восприимчивая аудитория, на самом деле, раскошеливается, грубо говоря, на лишнюю пару сотен миллионов долларов каждый год. Я думаю, что гранты NFS на исследования в области информационной технологии (US National Science Foundation Information Technology Research, ITR) являются прямым следствием деятельности PITAC. У организаций, предоставляющих гранты, имеется отчет PITAC, которым они могут размахивать в Конгрессе и исполнительных ветвях власти, и вследствие этого финансируется программа ITR. Я знаю довольно многих ученых, которые финансируются PITAC, и они делают действительно огромную работу, так что я думаю, что у PITAC будет иметься чрезвычайно устойчивое влияние.

Кстати, сейчас мы наблюдаем очень важную ситуацию в финансировании науки; эта ситуация заключается в том, что деньги на программу высокопроизводительных вычислений и коммуникаций (High Performance Computing and Communication, HPCC) вошли в состав базового финансирования NSF, а ITR основывается на деньгах вне базового финансирования. Мы надеемся, что в течение двух-трех лет деньги ITR также войдут в состав базового финансирования NSF. На горизонте не заметно какой-либо новой инициативы, которая могла бы обеспечить NFS новое видение пространства IT. Я состою в консультативном совете NSF CISE (Computer & Information Science & Engineering), и все мы озадачены тем, как предложить такое видение. Если наше предложение окажется неверным, то кто-то из исследователей, заслуживающих финансирования, может его не получить, и это было бы просто ужасно. Так что действительно важно найти правильное видение. Большинство людей не может сильно повлиять на это, но имеется несколько заслуженных исследователей в сообществе баз данных, которые могут повлиять. Если действительно хорошая идея появится у молодого человека, ему следует обратиться к старшему коллеге. Исследователи же старшего поколения должны действовать совместно и предлагать правильное видение.

Найдутся ли у Вас какие-либо напутственные слова для начинающих исследователей и практиков баз данных?

Мы с Вами только что слушали Майка Стоунбрейкера, и напутствием Майка было «стремитесь попасть в яблочко».

Это прямо противоречит напутствию Дэвида Паттерсона (David Patterson).

Да! Не стремитесь к синглам и даблам, не стремитесь даже к аутфилду, стремитесь к хоумрану^*. И для этого нужна отвага. Но вы должны спросить себя, почему вы делаете то, что делаете.

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

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

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

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

Так что, нет, система отбора докладов на конференцию не разрушена. На самом деле, для людей, которые двигают науку и постоянно прогрессируют в своей работе, система работает совершенно. Она не работает в случаях неожиданных открытий. Имеется ряд известных примеров: была отвергнута оригинальная статья про B-деревья, была отвергнута статья про упомянутый мной куб данных. Отвергнута была и посланная нами оригинальная статья про транзакции. Любая «нелинейная» статья может быть отвергнута.

Они же все потом были опубликованы.

Все они были опубликованы.

Так в чем же здесь секрет, как перейти из состояния «отвергнуто» в состояние «принято»?

Доклад про куб данных был послан на менее престижную конференцию, International Conference on Data Engineering, на которую в то время принимались почти все доклады. Доклад о правиле пяти, который, по моему мнению, был действительно хорошим, но являлся, по сути дела, приглашенным. Я пишу и такие статьи, про которые знаю, что они никогда не будут опубликованы. Я просто размещаю их на своем Web-сайте. Моя позиция полностью отличается от позиции типичного человека, читающего это интервью, поскольку я не стараюсь к укреплению своих позиций. Я не стремлюсь к продвижению. Я просто пытаюсь делать хорошую работу. И, откровенно говоря, людей, которые стремятся к продвижению, обычно критикуют их коллеги по университету. Я подозреваю, что если бы они выполняли большую работу, то их коллеги нашли бы какой-нибудь способ их поощрения. Я бы рассчитывал на этот процесс. Безусловно, так обстоят дела в индустрии. Так что, нарушен ли процесс? Да, для некоторых вещей процесс нарушен, но мы сами создали эту систему, и есть люди, работающие над устранением некоторых проблем, так что эту работу можно считать более или менее частично выполненной.

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

Я работаю в Microsoft. Я меньше, чем мне хотелось бы, контактирую с группами разработчиков Microsoft, в частности, с группой SQL. Просто не хватает времени, все оно уходит на исследовательскую работу и другие вещи, такие как Слоановский цифровой обзор неба (Sloan Digital Sky Survey), работу в комитетах в Вашингтоне и т.д. Поэтому мои контакты с группами разработчиков Microsoft являются в большей степени случайными, а не постоянными. Сейчас в сообществе баз данных происходят очень захватывающие события; прямо сейчас происходит синтез файловых систем, объектов, баз данных и XML. Я бы хотел быть в центре всего этого, но не получается, и я это, откровенно говоря, упускаю.

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

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

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

Я думал, что к победе приведет горизонтальное масштабирование многих и многих систем, работающих в параллель. Мы с Дэвидом Девиттом написали статью про параллельные системы обработки данных, и я думал, что к 2000 г. произойдет фазовый сдвиг. А в действительности люди обрели возможность создавать все более и более крупные компьютеры, 64-процессорные, 256-процессорные SMP. Так что в действительности не было ожидавшегося мною давления в сторону горизонтального масштабирования. Я не думал, что нам стоит обращать внимание на эти чрезвычайно мощные мейнфреймы. Я думал, что возможности масштабируемости иссякнут, скажем, на 16 процессорах, поскольку, откровенно говоря, к 1990 г. никто не построил работающие машины с числом процессоров, намного большим шестнадцати. Но разнообразные изменения в программном обеспечении, аппаратуре, улучшенные алгоритмы кэширования, улучшенные структуры шин и т.д. позволили разработчикам аппаратуры продолжить вертикальное масштабирование в пределах одного узла. Так что мое допущение, что мы должны делать нечто немедленно и срочно, оказалось неверным. Я все равно думаю, что в конце концов доминирующим станет горизонтальное масштабирование, но я, очевидно, ошибся во временной шкале.

Большое спасибо за то, что Вы были с нами сегодня.

Спасибо, Мэрианн. Здорово, что Вы делаете эти интервью.

---

^* Прошу прощения за бейсбольный сленг. Особо прошу извинить меня реальных любителей бейсбола за возможное искажение прямого смысла предложения: сам я с бейсболом знаком исключительно поверхностно. На всякий случай, вот это предложение на английском языке: «Don’t go for singles and doubles, don’t even go for the outfield, go for the bleachers».