Брюс Линдсей размышляет о прошлом и будущем СУБД (и не только об этом)

Добро пожаловать в серию интервью c выдающимися членами сообщества баз данных, организованных изданием ACM SIGMOD Record. В прошлом номере «СР» мы публиковали интервью с Пат Селлинджер из IBM, а сегодня вы познакомитесь с ее коллегой Брюсом Линдсеем, членом исследовательского коллектива IBM Almaden Research Center. Брюс хорошо известен своими работами в области реляционных баз данных, оказавшими очень большое влияние как внутри, так и вне IBM, и начавшимися в проекте System R. Брюс является почетным сотрудником IBM. Он получил степень PhD в университете Беркли.

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

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

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

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

Например?

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

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

В области утилит имеется чрезвычайно большое число проблем, особенно в современном мире "7x24", где недопустим простой во время резервного копирования. Обеспечение возможности выполнять эти операции в режиме on-line без нарушения идущей производственной работы действительно является инженерной и конструкторской проблемой.

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

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

Мне попадались статьи про массовую загрузку.

Я тоже встречал их, но, насколько я помню, в них говорилось не про загрузку в режиме on-line. Идея добавления, скажем, 10 Гб записей к таблице без нарушения процесса запросов к этой таблице - это нечто, чего я никогда не встречал в академической литературе.
Итак, аспиранты, ищущие темы, вы слышали это!

Не хотите ли вы сказать что-нибудь про TPC-C?

Не занимайтесь этим дома.

Что-нибудь еще, или это краткое заключение исчерпывает тему?

Ладно, оценочные испытания - это грязное занятие. Его смысл состоит в том, чтобы получать цифры путем подтасовки. И хорошо еще, что 40-70% того, что мы делаем при настройке производительности, доходит до конечных пользователей. Но большая часть того, что мы делаем в области TPC-C в данное время, находится в диапазоне производительности за пределами потребностей любого пользователя. Потребители хотят, чтобы выполнялось много транзакций, но их бизнес не настолько велик. Так что эта ситуация противоречива.

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

Не могли бы вы упомянуть какой-нибудь коварный, но вместе с тем легальный аспект настройки для TPC-C?

Ну, что я могу сказать? Именно это мы и делаем. Мы доходим до того, что следим за физическим порядком столбцов в таблице, чтобы выбираемые столбцы располагались поблизости один от другого; это минимизирует вероятность отсутствия данных в кэше при выборке. Для оценочных испытаний на тестовом наборе TPC-C это возможно, потому что имеются всего пять таблиц и от десяти до пятнадцати столбцов в каждой таблице. В более реалистичных приложениях, в которых нужно принимать во внимание намного больше запросов, таблицы являются гораздо более широкими, по 80-100 столбцов; и имеются десятки, если не тысячи таблиц. В таком случае подобный анализ не очень реален.

Расскажите нам про Гейзенбаги.

О, Гейзенбаги. Одной пьяной ночью в Беркли мы с Джимом Греем продолжали усердно трудиться над проектом операционной системы, системы CAL-TSS (поддержанный NSF исследовательский проект, выполнявшийся в 1960-е, в рамках которого разрабатывалась мандатная операционная система для CDC 6400). Естественно, у нас имелась ошибка из числа тех, которые, чем больше на них смотришь, тем труднее находятся. Каждый раз, когда ты пытаешься ее поймать, она убегает, и ее не видно. В то время я немного занимался физикой и был поражен, когда мне в курсе атомной физики сказали, что имеется связь между измерением и измеряемым предметом. И еще меня поразило, что мы играем в чем-то похожую игру: когда вы смотрите, ошибка убегает, потому что измерение или наблюдение воздействует на явление, которое вы пытаетесь разглядеть. Отсюда появился термин "гейзенбаг" (heisenbug) /* Вы правильно догадались - это игра слов, и в основе этого неологизма - фамилия знаминитого физика Гейзенберга - прим. ред */.

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

Есть несколько мелочей, в которых, как я думаю, мы наделали ошибок. Мне кажется, что наибольшей ошибкой в языке SQL было понятие "select *". Конструкция "select *" разрабатывалась для облегчения использования языка, но в действительности явила собой реализационный кошмар. "Select *" означает выборку всех столбцов, но в каком порядке? Реляционная модель ничего не говорит о том, что может или должен существовать порядок столбцов, так что в этом месте вы опускаетесь до вопросов физического хранения. Еще более непонятна ситуация, в которой вы создаете представление вида "select * from table where predicate". Что происходит, когда таблица изменяется, и к ней добавляется столбец? Что теперь означает представление? Имеется ли в нем столбцов больше, чем ранее? Мы должны угадывать, что происходит с этими представлениями при изменении соответствующих базовых таблиц. На самом деле, мы должны сделать представления неизменяемыми при таких изменениях базовых таблиц, поскольку в противном случае были бы повреждены существующие приложения. Так что я думаю, что это один из примеров непродуманных решений.

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

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

Я люблю рассказывать, что значило быть DBA (Database Administrator) в то время, поскольку приложения были ужасно незавершенными. Быть DBA было хорошо, поскольку вы контролировали, что делать на следующем шаге. Каждый, кто хотел, чтобы что-нибудь было сделано, должен был приносить вам подарки, ну, знаете, хорошие такие бутылки ;). И именно поэтому хорошо было быть DBA - по причине этой незавершенности приложений.

По моему мнению, возможность просто указывать, как или что вы хотите выбрать из базы данных, вместо того, чтобы говорить, как это сделать, была огромным преимуществом и весьма окупалась. Но действительные причины победы реляционных систем не имеют ничего общего с реляционной моделью; они связаны с тем, что в начальных прототипах, System R, например, поддерживались непредвиденные запросы и оперативное определение данных. Появилась возможность попытаться запросить данные немедленно, без кодирования запроса в приложении, без компиляции приложения, без его запуска, без сбойных ситуаций, обычно связанных синтаксическими ошибками. Теперь, если в запросе не было синтаксических ошибок, вы могли тут же взглянуть на ответы на запрос и проверить, правильные ли в нем содержатся кортежи. Оперативное выполнение непредвиденных запросов - это было нечто неслыханное в мире баз данных в то время, это было громадное благо для разработчиков приложений и для людей, нуждающихся в просмотре данных. Оперативное определение данных тоже явилось огромным благом для разработки приложений систем баз данных. Раньше, если вы хотели добавить новую таблицу, индекс или столбец к некоторой таблице (или набору данных, как это называлось тогда), вам нужно было прекратить работу системы баз данных, вызвать некоторый инструмент, напоминающий компилятор, для определения новых элементов данных, снова запустить систему баз данных и попытаться начать с ней работать. Это могло занимать часы. При использовании средств оперативного определения данных вам достаточно ввести правильное заклинание, и система скажет: "Сделано, работайте дальше".

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

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

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

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

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

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

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

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

Вы говорили, что остаются важные спорные вопросы и конфликты между объектно-ориентированными и Java. Можете ли вы развить это замечание?
Затруднением с объектно-ориентированными приложениями является то, что эти программные системы имеют дело только с объектами целиком. У долговременно хранимых полных объектов могут иметься одна или две сотни атрибутов. При использовании этого объекта в приложении может потребоваться только несколько его атрибутов. Интерфейсы, которые мы используем в настоящее время, частично, из-за недостатков в средах программирования объектно-ориентированных приложений не обеспечивают возможности сфокусировать доступ к долговременному хранилищу на атрибутах, представляющих интерес. На самом деле, у нас имеются клиенты, использующие крупные прикладные программы и сталкивающиеся со следующей проблемой: всякий раз, когда изменяется один атрибут объекта (Java bean), какой бы он не был, эти программы немедленно изменяют все атрибуты - конечно, на те же значения, которые были у них раньше. Хорошо, по крайней мере, это работает - мы имеем правильные данные в долговременном хранилище! Но это дается ценой производительности, производительности и производительности.

И что же можно сделать для устранения этой проблемы?

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

Правильно ли я понимаю следующее? Вы являетесь почетным сотрудником IBM (IBM Fellow); следовательно, ваши пути в IBM вымощены золотом. Вы можете работать над тем, чем хотите, у вас есть куча денег, которые вы можете тратить, как хотите, и люди склоняются перед вами. Это так?

Все не настолько грандиозно! То, что мы действительно имеем бюджет, является широко распространенным заблуждением. У нас его нет. В прошлом году первый раз они дали каждому из нас по $5000 для траты по собственному желанию. Грандиозное предприятие!
Хотя возможность выбора собственной области исследований действительно является привилегией. Я получил удовольствие от возможности
самостоятельно решать, над чем стоит работать и тратить на это свое время.
Идея преклонения - это полный идиотизм. Я уверен, что в IBM и вообще повсюду нужно общаться с людьми, исходя из того, что они собой представляют, и что происходит вокруг. Я не обращаю внимания на позицию человека, но меня сильно интересует, что он знает и насколько хорошо он может мне это рассказать.

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

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

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

Ну, я думаю, что их всего двое: Пат Селинджер перешла в менеджеры, потому что она очень хорошо работает с людьми. Она может добиться, чтобы люди делали все, что только она захочет. Я не знаю, как она это делает. Она делает это со мной в течение многих лет, и это полная мистика. И Хамид Пирахеш начинает заниматься менеджментом исследовательской работы в San Jose Almaden Lab, потому что кто-то должен этим заниматься. Но я уверен, что идея выталкивания технической публики в менеджмент - это действительно очень плохая идея.

Когда я готовилась к интервью в этом году, Джим Грей предложил, чтобы я спросила Пат Селинджер, как она управляет такими трудными людьми, как вы с Джимом. В более общем смысле, какова роль менеджера при управлении такими людьми, как вы с Джимом?

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

Это правда, что вы процветаете благодаря адреналину, вырабатываемому при написании программ?

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

Но не ограничивает ли написание кода вашу сферу влияния?

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

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

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

Почему я не менял компании? Думаю, что в основном потому, что я трус. Из-за моих манер завоевание доверия занимает у меня годы. И после того, как я преодолел это и завоевал доверие, зачем мне начинать все сначала? Я думаю, что если вы собираетесь работать в коллективе и достигать таким образом результатов, у вас должно быть взаимное доверие. Вы не можете просто войти в комнату и сказать: "Меня зовут Брюс Линдсей, я почетный сотрудник IBM, вы должны мне доверять". Вы должны завоевать это доверие, работая с людьми в течение долгого времени. Иногда этому помогает сложившееся о вас мнение: "Да он нормальный парень, он вас не съест".

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

О, я бы постарался найти работу.

В промышленности?

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

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

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

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

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

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

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

Над какими аспектами индексации?

О, я считаю, что имеется много аспектов индексации, нуждающихся в совершенствовании. Я думаю, что мы могли бы улучшить работу поиска. Мне кажется, что захватывающие вещи можно сделать в многомерной индексации. По моему мнению, имеется много более развитых способов использования индексов баз данных для индексации на столбцах, содержащих XML-данные, и для частичной индексации. При использовании частичной индексации мы индексировали бы только некоторые строки на основе некоторого предиката. Например, мы могли бы не индексировать NULL-значения или могли бы индексировать только те значения зарплаты, которые превосходят $100K.

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

Стать повыше?

Но что бы это вам дало?

Я мог бы выглядеть как Май Стоунбрейкер.

А что-нибудь еще?

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

К каким темам относились бы доказываемые вами теоремы?

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



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