Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
1998 г

Воссоединение SQL в 1995 г.: люди, проекты, политика

Под редакцией Пола МакДжонса
Перевод: Сергей Кузнецов

Страницы: назад 1 2 3 4 5 6 7 8 9 10 вперед

VS/QUERY (QMF)

Пат Селинджер: Итак, мы переходим к следующему пятнадцатилетию. Сейчас мы находимся где-то в середине 80-х. Мы собираемся завершить обсуждение VS/QUERY, а затем Джон Науман приступит к эпохе DB2. Боб? VS/QUERY.

Боб Джойллс: Спасибо, Пат. После Плана B наступило время Плана A, меня попросили заняться новой работой по управлению проектами VS/QUERY и языков в Санта-Тереза. Может быть, ты не можешь быть отверженным - человеком, ответственным за внеплановую работу, и когда они решают, что ты прав, то не могут оставить тебя ответственным, это слишком затруднительно. Поэтому меня попросили заняться управлением VS/QUERY, проектом, находящимся в глубоко аварийном состоянии. VS/QUERY был продуктом, про который люди из отделения маркетинга в последние четыре или пять лет говорили: "Вы знаете, на самом деле, мы не понимаем все то, что вы делаете в Санта-Тереза, но мы хотим одну эту вещь. Дайте нам ее". И год за годом группа VS/QUERY как-то управлялась, но не была в состоянии поставить продукт. Они были в некотором роде в ловушке: встречались в Йорктауне с Мойше и другими людьми и решили, что QBE - это замечательно и что им необходимо иметь все функции QBE работающими в первом выпуске. И поскольку они знали, что язык SQL важен, им нужно было иметь SQL в своем продукте, и они хотели иметь еще и некоторые другие вещи. У них было около сорока человек и гора работы, которую нужно было сделать, а также убеждение, что все это должно быть сделано для первого выпуска. И у них всегда был повод - я думаю, опирающийся на одно и то же, о чем Пат говорила мне во время перерыва - у них имелся список проблем System R. Вы знаете, вот причина того, что мы не можем взять это готовым; в System R имеются эти проблемы и т.д. и т.п. И когда эта группа стала отчитываться передо мной, я задал вопрос типа: "Хорошо, и что же произошло, когда вы встречались с людьми из System R?" "О, мы не делали этого." Так что у них были проблемы, но они не пытались их разрешать.

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

Джим Грей: У нас было тысяча семьсот обращений к SYSTERR. Это была большая помеха.

Пат Селинджер: Мы сообщили Брюсу Линдсею об этой проблеме, он пришел, все пересчитал и поменял их на какой-то другой код ошибки. [смеется]

Боб Джойллс: И они не сказали Ларри Эллисону.

Джим Грей: Все они вызывали одну подпрограмму, называемую PANIC, и когда эта подпрограмма вызывалась ...

Боб Джойллс: Я бы сказал, что имелось нечто вроде синдрома, который одинаково проявлялся у людей с разными моделями данных. И я надеюсь, что это не прозвучит цинично, но должен сказать, что многим людям был свойственен тот синдром, что они считали допустимым не добиваться прогресса, пока для этого имеется причина. И конечно, всегда имелась масса причин, поэтому значительный прогресс не достигался. Я бы сказал, что ребята из VS/QUERY ощущали себя пойманными в ловушку, потому что они думали, что приняли на себя обязательства за все эти вещи перед отделением маркетинга, и люди из маркетинга сказали им, что они должны иметь все эти функции QBE и т.д., а иначе они "не будут иметь продукт". В конце концов, после многочисленных обсуждений этого и собраний по поводу того, что в QBE не может транслироваться через SQL и, следовательно, какие функции из числа требуемых маркетингом будут отсутствовать, я впал в замешательство и перестал что-либо понимать. Я попросил дать мне список из десяти вещей, которые были бы недоступны в первом выпуске, поскольку их нельзя было транслировать через SQL. Потом я встретился с людьми из маркетинга и выяснил, что они не понимают, что это за вещи, а потому определенно не могут требовать их присутствия в продукте. И мы стали снижать масштабность системы до того уровня, на котором можно было получить пригодный к использованию продукт. Поскольку я ушел из IBM, то не знаю точно, как этот продукт был сделан, но, по крайней мере, когда он был выпущен, то являлся вполне успешным продуктом.

Пат Селинджер: Это было очень прибыльное дело.

Боб Джойллс: У них были все правильные составляющие для хорошего продукта: System R, некоторые идеи из QBE и, возможно, из других вещей ...

Роджер Миллер: Боб, QMF - потрясающе успешный продукт. У нас была огромные затраты, поэтому мы были должны иметь высокую цену. Заказчики покупали продукт, и он стал очень выгодным.

Боб Джойллс: Кто говорит, что ценообразование с учетом затрат не является правильным способом? Я полагаю, что с точки зрения System R мы годами испытывали с группой VS/QUERY массу переживаний и неприятностей. Я думаю, что это завершилось достаточно быстро, и они закончили проект, получив успешный продукт.

К. Мохан: Так он отличается от QMF?

Боб Джойллс: Нет, VS/QUERY было кодовым названием; прошу прощения: QMF.

Пат Селинжер: И затем мы перешли к DB2.

Боб Йост: Вы действительно запускали это на незаконнорожденной версии System R? В течение долгого времени не было DB2. Вы взяли некоторый код, заставили его работать в своей среде, получив возможность реально тестировать средства запросов.

Боб Джойллс: Правильно. Я не помню, поставляли ли они QMF вместе с черным ящиком, содержащим старую версию System R.

Боб Йост: Это было только для целей тестирования, поскольку в это время опорная система не существовала.

Боб Джойллс: Итак, мы собираемся послушать, что скажет Джон про DB2? Хорошо.

DB2

Джон Науман: Я собираюсь нанести небольшой удар по Eagle. Когда я познакомился с Джимом, мы только что перебрались [в Пало-Альто] и работали над проектом, у которого тогда не было названия. Я не думаю, что он назывался Eagle, когда ты оказался там.

Джим Грей: Нет, он назывался VSS.

Джон Науман: Но один парень из маркетинга посмотрел на слайд - не на слайд, на постер; в IBM было много постеров - и этот был посвящен лаборатории Санта-Тереза с этим парящим орлом. И он посмотрел и сказал: "Вот так мы и назовем проект; мы назовем его Eagle". Мы называли его несколько по-другому - VSS, и нам пришлось снова пройти по всему документу (к этому времени спецификация занимала, вероятно, сорок, или пятьдесят, или восемьдесят страниц) и все заменить ... я не думаю, что в редакторе, который мы тогда использовали, имелась опция глобальной замены, поэтому при применяли SCRIPT, так что в &PROJVAR содержалось название проекта, и достаточно было поменять содержимое &PROJVAR, чтобы получить везде Eagle. Когда прошло около шести месяцев после нашего перемещения в Санта-Тереза, нам стало понятно, что там нет никаких орлов, и мы решили снова изменить название, и на этот раз мы изменили его на Ampersand, поскольку, казалось, что лучше использовать такое название, чем пытаться все время менять название проекта; мы не нашли ни одного человека, который понял бы, что это означает.

Роджер Миллер: Я думал, что явились юристы и сказали: "Это хищная птица, и вы не должны использовать такое название". Одна из этих замечательных историй, которые здорово звучат, но, вероятно, не являются правдивыми.

Джон Науман: Это неправда. Мы просто устали пытаться придумывать имена, а этот парень из маркетинга уволился, поэтому мы решили назвать проект Ampersand. Вероятно, в том, что проект близится к смерти, меня убедило то, мы работали над ним в Санта-Тереза около года, и имели регулярные собрания для обсуждения документа. Мы делали этот документ еще когда были в Пало-Альто, значит мы работали над ним уже больше года. Среднее собрание выглядило следующим образом: вы приходили в комнату для обсуждения документа - спецификации, и люди начинали говорить о том, какие там были вдовы и сироты. Все ли знают, что такое вдовы и сироты? Это была тема разговора: "На этой странице имеется вдова; поправил бы ты это". И тогда я сказал: "Нет, так делать неправильно. Вероятно, нам не следует делать это. Этот проект обречен". И он был обречен. Мы старались понять, как двигаться вперед, и что делать со средствами баз данных. Насколько я помню, мы решили, что нам следует перейти к использованию реляционного подхода, но не были уверены в том, как это сделать. И я помню много собраний с участием Фрэнка Кинга.

Франко Путцолу: Когда это было?

Джон Науман: В 1978-1979 гг. К тому времени Франко работал над заменой RSS - менеджером данных - и мы бились над тем, что делать с верхним уровнем - частью системы, обеспечивающей реляционное хранилище данных. Имелись два лагеря. В один лагерь входили мы с Доном Хадерли (Don Haderly), а другой составляли Фрэнк Кинг и все из исследовательского отделения. Мы считали, что поскольку MVS была не тем же самым, что VM, то было трудно эффективно использовать имеющиеся средства в среде MVS, и нам нужно было основательно реструктуризовать их. Ребята из System R полагали, что такая масштабная оптимизация не требуется; и без этого все будет OK.

Джим Грей: Люби мою собаку.

Джон Науман: Любишь меня; полюби мою собаку. Я отчетливо помню тот день - на самом деле, я в то время работал для Боба [Джойллса] - Боб пришел и сказал: "Нет, ответ таков, что ты должен взять эти вещи из System R". И я сказал: "OK. Если это то, что ты хочешь делать, то это деловое решение. Давай делать это". Итак, мы начали над этим работать. Мы потратили много времени и собрали группу - некоторые люди присутствуют в этой комнате, включавшую Джея Йотерса, отсутствующего здесь сегодня, Жозефин, Роджера, которого я переманил с другой работы - я думаю, что IBM была его четвертым местом работы, и когда я нанимал его, он говорил мне, что не собирается долго здесь оставаться, но он хотел получить некоторый опыт работы в большой компании, [смеется] а тогда, я думаю, она была больше, чем сейчас.

Роджер Миллер: Обычно я непредсказуем.

Джон Науман: Давайте посмотрим; мы наняли Морта - Джона Мортенсона (John Mortenson) - Джон уже работал в компании, мы взяли его в группу. Мы наняли Джерри Бейкера (Jerry Baker), который, вероятно, сделал больше всех денег - следующий за Ларри Эллисоном; он работает на Ларри; он твой босс?

Франко Путцолу: Нет, он не мой босс.

Джон Науман: Он в одной из организаций разработчиков.

Франко Путцолу: Портирование.

Джон Науман: OK, это то, что он делал, когда ушел; он перешел в Oracle, чтобы выполнять портирование на платформах UNIX, поскольку у него была подготовка в области ОС UNIX из Техасского университета и ему не так уж нравилась MVS. И он заработал кучу денег; я думаю, что остальные работали большей частью на пользу человечества.

Джим Грей: Спасибо; мы ценим это.

Джон Науман: Но на самом деле, мы получали массу удовольствия. Происходило множество интересных вещей. В некоторой степени нам помогал Джим. Много помогал Франко. Франко бился над тем, как реализовать DL/1 и SQL с использованием одних и тех же базовых структур, и позже он снова пытался это сделать, как я упоминал раньше. Но была масса удовольствия. Причина, по которой я ушел - я покинул IBM в середине 1981 г. - только что ушел Джим, и он позвонил мне и сказал: "Слушай, почему бы тебе не поговорить с Tandem; они ищут человека для управления одной из своих групп". И я пошел и поговорил с ними. Джим написал трактат под названием "MIPS Envy" - уверен, что некоторые из вас помнят его - появление которого было аргументом к тому, что он ушел; я думаю, что в этом есть доля истины. Когда мы работали над DB2, у нас был терминальный зал в конце коридора с шестью терминалами 3270. Это все, что мы имели, весь компьютерный ресурс, который был доступен для работы над DB2. Постепенно мы получали больше и больше терминалов 3270 и ставили их в офисы, что было чем-то вроде революции. Ни у кого не было терминалов в офисах; были терминальные залы, в чем имелся смысл.

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

Джон Науман: Терминалы были дорогими. Да, можно было работать в уикенды, а также до восьми и после шести. Поэтому я, Хадерли, Бейкер и еще несколько других людей приходили в четыре часа утра, иногда включали радио в четыре часа утра и слушали эти китовьи звуки. И мы удивлялись тому, что происходило; почему мы здесь? чего мы реально хотим добиться? Меня расстраивали те же самые вещи, что и Джима, но я ощущал себя бесполезным, потому что к 1981 г. я работал над проектом около четырех лет - если учитывать время работы над Eagle и не считать время работы над FS - и я мог видеть, что система была почти сделана. Это было в середине 1981 г., за шесть месяцев до начала поставки, и я понял, для меня настало время уйти, поскольку к этому все сходилось. Так что я сказал Дону: "Я ухожу отсюда. Ты можешь принять все на себя; все происходит нормально". В третий раз я поступил так по отношению к Дону - ушел из проекта, над которым мы работали. Но для завершения этого проекта понадобилось немного больше времени.

Итак, я ушел в Tandem, а потом мы завербовали в Tandem Франко, завербовали Майка [Понга] (Mike [Pong]), завербовали ряд других людей. Мы украли Дона у Эсвела (Esvel).

Дон Слац: Не украли. Я ушел.

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

Франко Путцолу: Да, я испытывал такие же ощущения.

Джон Науман: И я думаю, что в этом была одна причин того, что пришел Франко и другие люди. И в Tandem мы добивались результатов гораздо быстрее, и я думаю, что по этой причине нам было гораздо веселей. Я проработал в Tandem четыре года и в 1985 г. после перехода в 3Com я прочитал о полном выпуске DB2. Потребовалось еще четыре года, чтобы получить полный продукт. И насколько я знаю из рассказов Дона, Жозефин и других людей, много усилий потребовалось для того, чтобы заставить работать систему в среде MVS, которая ни в коей мере не являлась простой системой, и я думаю, что мы все недооценивали сложность того, что собирались сделать с удовлетворением имевшихся требований к производительности.

Роджер Миллер: Как только мы начали поставлять систему первым заказчикам в 1982 г., они стали использовать в своих дискуссиях массу ругательств. Первые голоса звучали весело: "О мой Бог, это увлекательно". Но сразу появились все эти вещи, которые мы делали, а Джон говорил, что мы никогда не должны были этого желать. Вещи, подобные Cold Star: "О, нет; базам данных никогда не понадобится Cold Star". Для ввода в действие Cold Star нам фактически понадобилось десять или пятнадцать человеко-лет. Понадобилось неприятное, трудное программирование. Мы почесали в затылках и сказали: "Почему заказчик может захотеть иметь эти средства?" И ответ был следующим: "Вопрос не в том, почему это им не нужно, а в том, почему у тебя этого нет". Так что мы двигались от проблемы к проблеме и продолжали находить ошибки. О, Джерри Бейкер был вынужден шевелить мозгами, потому что Джерри был любителем языков высокого уровня, и он работал в RDS, но у него были эти фрагменты, у него был этот склеенный код, и Джерри даже не хотел знать, что там делается, просто склеивал вместе фрагменты; мы не могли наладить много фрагментов и были вынуждены латать и клеить. Итак, в ноябре 1982 г. мы поставили систему шестерым заказчикам; к марту 1983 г. - восемнадцати. Большое событие - Blow-up Announce - и, как мы объявили, мы производили поставки сорока - пятидесяти - шестидесяти заказчикам: 7-го июня 1983 г. Дела неожиданно пошли на подъем, мы производили первые поставки и двигались от проблемы к проблеме. Шестнадцать мегабайт памяти - это немного; на каждой PC стоит по крайней мере столько, правильно? Но у вас только восемь из шестнадцати, восемь мегов, когда вы начинаете пропускать много пользователей ниже нормы. Система не работала, и здесь появилась XA и MVS XA с 31-битовой адресацией, и целый стек новых проблем, и несовместимости; поэтому нам не было слишком комфортно работать в MVS. Какие из этих сервисов выходят за пределы нормы? "Мы не скажем" - вид ответа; не было списка таких изменений.

Том Прайс: Получите дамп.

Роджер Миллер: Да, да, только попробуй; тебе это понравится. И так мы крутились и вертелись, и это было мучительно. Каждый раз приходилось подниматься и говорить с людьми из исследовательского отделения, и они говорили: "Вот так так, я не понимаю; это работало, когда я ушел". Действительно доставляло удовольствие, когда иногда приходил Мохан и говорил: "О, вы знаете, это на самом деле трудно". Это правда не было просто. Поскольку тогда мы начали наращивать число пользователей, в сентябре 1984 г. мы занялись проблемами контролируемой доступности; общей доступности, а потом, в апреле 1985 г. выполнили окончательную очистку кода - к этому времени мы закодировали второй выпуск. Второй выпуск вышел примерно через год после этого. Во втором выпуске мы выбросили фрагменты и построили Structure Gen подобно тому, как вы, ребята, делали HOP65, и начали говорить "Ах ты, Боже мой". По-существу, второй выпуск делался следующим образом: поговорить с этими первыми 250 пользователями, получить их пожелания, встроить соответствующие возможности в продукт, сделать его успешным. Мы должны были что-то делать, потому что они приставали и приставали, но после этого становилось немного менее интересно.

Франко Путцолу: Можешь ли ты что-нибудь сказать о дуальной стратегии баз данных?

Роджер Миллер: Ты имеешь в виду дуэльную стратегию баз данных?

Франко Путцолу: Велась ли внутри IBM большая полемика по поводу дуальной стратегии?

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

К. Мохан: Кто-нибудь должен что-нибудь сказать об этом заявлении, которое Фрэнк Кинг собирался сделать в Австралии, и которое стоило большой головной боли. Это был конгресс IFIPS или что-то в этом роде, правильно? Когда он рассказывал о состоянии реляционных баз данных и собирался сказать, что это ...

Роджер Миллер: О да, и что это, по существу, убьет IMS. И вся наша команда ожидала неприятностей ...

К. Мохан: Это было в 1981 г.? Я забыл год. Это был какой-то конгресс IFIPS, где он ...

Пат Селинджер: Должно быть, это был 1980 г., потому что конгрессы IFIPS проводились раз в два года.

Роджер Миллер: И последствия для нас были минимальными. Мы не были объявлены. SQL/DS была близка к выходу, но SQL/DS была недостаточно развита для обработки транзакций. SQL/DS - это VM, возможность выполнения запросов и не очень большие базы данных. Сегодняшние большие базы данных содержат терабайты, и реальные живые заказчики во многих ситуациях создают базы данных размером шесть-восемь-десять терабайт. У SQL/DS кончается горючее за пределами диапазона с границей в десять сотен мегабайт - один-два гигабайт - это база данных не категории high-end. Мы всегда хотели масштабировать ее - о, до шестидесяти четырех гигабайт, потому что по глупости считали, что шестидесяти четырех гигабайт [на таблицу] будет достаточно в течение долгого времени.

Франко Путцолу: Тогда я думал, что это все равно, что бесконечность.

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

???: Когда вышла DB2 для MVS, она тоже не объявлялась как транзакционная система, правильно? Это была система поддержки принятия решений.

Роджер Миллер: Мы должны были быть очень осторожными, потому что то, о чем спрашивал Франко, действительно верно: сражающиеся базы данных. Мы действительно должны были быть осторожными. Мы не были солидными. Мы не были готовы открыть огонь по IMS. В лучшем случае, когда кто-нибудь говорил: "Какова длина пути? Меня беспокоят издержки", ответом было, грубо говоря, 2X.

Франко Путцолу: И когда же ситуация изменилась? Когда DB2 начали воспринимать как нечто подходящее для OLTP66?

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

Майк Блазген: На пять лет раньше я, бывало, рассказывал об этом.

Роджер Миллер: Забавно, что я только что просматривал свои материалы про DB2 и руководство Version 1 General Information. Я просматривал папки и говорил: "Это выглядит как достаточно точный перевод; нет только Дона и его бороды". Но многое в этом материале не менялось в течение двух десятилетий.

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

Роджер Миллер: Здесь всего понемногу. Это называется "Не стоит ли мне достать это из своего левого кармана и переложить в правый, чтобы ...".

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

Жозефин Ченг: Брюс, это, может быть, было так в прошлом, но я думаю, что ситуация меняется. Если посмотреть на инвестиции, сделанные IBM в новые продукты, такие как DB2 Client/Server, то видно, что они весьма существенны.

Брюс Линдсей: Ситуация изменилась.

Пат Селинджер: Здесь мы находимся вдалеке.

Майк Блазген: Фрэнк Кинг, например, жестко настаивал на том, чтобы System R принималась такой, как она есть. Это не обсуждалось. Потом он ушел. Так что он перестал быть движущей силой проекта. Но он продолжал играть определенную политическую роль, вроде выступления в 1980 г., о котором говорилось раньше и которое, я думаю, состоялось после его ухода. Один из вопросов, на которым я работал, хотя находился в Вашингтоне и имел работу, никак не связанную с базами данных, заключался в том, что все считали, что нам нужно было бы всегда поддерживать DL/1; мы должны были бы поддерживать старые программы. Если вы загляните в отчет Pratt & Whitney, то увидите, что там говорится: "Задача номер один состоит в том, что мы должны иметь полную поддержку данных и программ IMS". Когда этого не стало? Только потому, что никто не делал этого?

Роджер Миллер: Достаточно точно. Правильно, потому что мы начали кодировать, чтобы попытаться это сделать. И, по существу, все свелось к нескольким вещам. Производительность: чем ближе вы подходите к производительности, тем хуже это выглядит. И убийственно то, что никогда невозможно до конца года сказать, что имеются некоторые вещи, которые вы не в состоянии поддерживать, потому что поддерживать стопроцентное воспроизведение DL/1 было невозможно. Мы были достаточно близки к этому, но достаточно близкое воспроизведение никогда не бывает достаточным.

Майк Блазген: Даже Фрэнк Кинг, когда он работал на Боба Эванса, считал, что мы должны сделать это.

Франко Путцолу: О да. Это оговаривалось.

Майк Блазген: И все же мы отбивались тем, что не можем этого сделать. Если бы могли, то сделали бы.

Роджер Миллер: Точно. У нас были спецификации, у нас был работающий код, мы поддерживали работоспособность, и мы сказали: "Можем ли мы поставлять продукт в таком состоянии?" Мы сказали от имени IBM: "Вот продукт; мы можем его поставлять, но примут ли его заказчики?" Мы опробовали его на нескольких заказчиках, и самым ласковым, что они сказали, было "Нет, черта с два". Хорошо было иметь честных заказчиков.

Франко Путцолу: Это было связано с эффективностью, блокировкой на уровне страниц, с функциональностью?

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

Франко Путцолу: Когда это умерло?

Роджер Миллер: По существу, во втором выпуске. Потому что у нас был второй выпуск DB2, который имел 1986 г. статус GA (General Availability). В 1984 или 1985 г. мы решили ориентироваться на то, что не можем делать DL/1 и будем двигаться по своим рельсам. Будем поддерживать реляционные возможности и делать то, что должно быть в реляционных СУБД для удовлетворения потребностей заказчиков.

Дон Слац: Я не уверен в точности даты, может быть, Дон [Чемберлин] сможет помочь, но Фрэнк Кинг распорядился, чтобы мы с Бобом Тейлором (Bob Taylor) отключились от проекта на пару месяцев и рассмотрели возможность поддержки вызовов DL/1 - я думаю, что это было в 1978 или 1979 г.; ты помнишь? Я работал на тебя; ты знал?

Роджер Миллер: В группе, которая, по существу, сделала это для нас, был Сид Корнелис (Sid Kornelis), который пришел из IMS. Сид знал IMS вдоль и поперек.

Джим Грей: Имелось пятьдесят тысяч тестовых вариантов ...

Роджер Миллер: Да, у нас имелось большое количество тестов IMS.

Джим Грей: ... пятьдесят тысяч, число, пугающее воображение.

Роджер Миллер: У нас был Ллойд Харпер (Lloyd Harper), имевший длинную историю многих и многих продуктов, которые никогда не поставлялись. У нас был Боб Инглс, частично работавший на Хомера [Леонарда] (Homer Leonard), и Хонер был в одной шеренге с Бобом Эвансом, говоря: "Этот продукт останется игрушкой до тех пор, пока в нем не появится поддержка DL/1". Они собирались начать поставки не раньше того, как мы осознаем, что не имеет значения, устраивает нас это или нет; мы не смогли бы продавать систему, если бы согласились.

Майк Блазген: И никто из этих хороших ребят не выиграл, правда? [смеется]

Джим Грей: Я думаю, Oracle. [смеется]

???: Нет, он имел в виду Tandem. [смеется]

Майк Блазген: О, SQL, ведь наша встреча посвящена SQL. SQL выиграл.

Жозефин Ченг: Я везучая. Сразу после окончания школы я поступила в IBM и работала в проекте Eagle. В то время были стены и двери, в которые никого не впускали. Вы знаете, что у нас в Санта-Тереза все башни соединены. Они специально поставили двери, чтобы ограничить все связи с другими зданиями - для прохода требовался специальный значок. Итак, я вошла в состав участников проекта, и Франко усердно работал; прикомандированный к STL Ирв также работал очень усердно. Временами я видела Джима [Грея] и также временами слышала громкие крики, и я знала, что это Энди [Хеллер].

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

Майк Блазген: Было бы очень мило с твоей стороны.

Жозефин Ченг: Да. Может быть, в следующий раз меня не пригласят. [смеется] На моем столе всегда лежало много статей про System R, помогающих мне понимать код. Например, имелся раздел, в котором говорилось про узлы PTREE. Узел дерева грамматического разбора содержал поля с именами P1, P2, P3, P4, P5. И чтобы понять смысл, требовалось заглянуть в справочник: содержимое поля P1 имело разный смысл для разных типов узлов. Если это узел, соответствующий столбцу, то P1 должно означать "указатель на узел таблицы", а P2 означает "указатель на дескриптор". К концу работы все стены моего офиса были завешены клочками бумаги.

Один из модулей - я не знаю, кто это писал - содержал семантическую подпрограмму, которая проверяла совместимость типов. Это писал Франко? Был реализован интересный алгоритм проверки совместимости типов. Брался остаток от деления на четыре и сравнивался с родовым типом для проверки того, не совпадают ли они. Ты удивлялся: "Почему на четыре?" Оказывается, потому что это дает возможность использовать четыре разряда(xi). Должно быть, проектировщик думал, что четырех разрядов достаточно, чтобы охватить любой поддающийся предвидению тип. Если говорить про арифметические типы, то это дает возможность иметь шестнадцать различных арифметических типов (два в четвертой степени); должно быть достаточно, правда? К сожалению, у нас имеются NULL и не-NULL, которые забирают два значения кода. Позже мы добавили поддержку Kanji, для чего резервировалось два байта на NULL и по два байта на не-NULL. Итак, для каждого числового типа трибовалось четыре кода. Потом, мы имели INTEGER и SMALL INTEGER, которые вместе отбирали восемь кодов. Когда мы приводили код к промышленному виду, нам пришлось добавить DECIMAL и FLOATING POINT. Были задействованы все шестнадцать кодов. К сожалению, как только код вышел за пределы лаборатории, заказчики запросили короткие плавающие числа, чтобы экономить дисковую память, а некоторые захотели 16-байтовые плавающие числа и 31-байтовые DECIMAL для обеспечения большей точности. Слишком много для остатка от деления на четыре!

Как я говорила раньше, я всегда восхищалась всеми людьми из System R. Я думаю, что они были большими выдумщиками, и не только по поводу алгоритмов и выполнения всей громадной работы; они были также очень хороши в созидании, в придумывании таких вещей, как, например, образование прилагательного от таких слов как "Search Argument": sargable67. Когда я разговаривала с заказчиком, то всегда говорила: "Этот предикат - sargable". Они смотрели на меня и говорили: "Что?"

Джим Грей: Теперь у всех есть такие предикаты: Sybase и Oracle ...

Жозефин Ченг: Да, и заказчики старательно искали смысл этого слова в словаре. А те люди, которые писали руководства - наши ребята из ID - не любили это слово. Они назвали это предикатом Типа 1; это означало, что он может быть обработан менеджером данных; предикат Типа 2 - RDS - мне это не нравилось; мне хотелось называть такие предикаты sargable.

В любом случае, мне очень нравилось просматривать код System R и приводить его к промышленному виду. Когда мы закончили первую версию, мы чувствовали такое облегчение - если бы мы не взяли код System R, то я думаю, что мы не смогли бы сделать свой первый выпуск DB2.

Боб Йост: Каковы были ваши инструкции? Говорили ли вам брать в основном RDS, потому что у вас был другой менеджер данных? Вы не собирались применять соответствующую подсистему из System R, но вы использовали в качестве наметки верхнюю половину технологии System R. Вы использовали ее как источник идей или смотрели на код и пытались транслировать его? Когда они обратились в Эндикотт, то там сказали: "Берите код. Транслируйте его; даже не задумывайтесь". Но у вас, должно быть, были другие инструкции.

Жозефин Ченг: Ну, наши инструкции состояли в том, чтобы сделать его работающим. [смеется] Первое, что мы делали, - старались понять его; я думаю, что контактировала с каждым присутствующим здесь человеком: Марио, Пат, Дон - стараясь разобрать и понять, что делают программы. Для нашего первого выпуска мы должны были преобразовать этот код таким образом, чтобы он работал с нашим кодом системы: менеджером памяти, трассировкой, учетом - вы знаете, со всеми компонентами производственной системы. Мы также старались в первом выпуске добавить некоторые возможности, но реально не так уж и много - только то, что требовалось для коммерческого использования. Так что мы добавили числа с плавающей точкой и десятичные числа. В это время я взялась за оптимизатор, Джерри Бейкер (Jerry Baker) - за ASLGEN и Ник Номм (Nick Nomm) - за ODEGEN. Тогда машинное время стоило больше заработной платы, поэтому мы работали по субботам и воскресеньям. Мы втроем занимали весь этаж в субботу и воскресенье. Вы выполняли всю работу над RDS, и у Джерри была идея, что нам следует заняться поддержкой симметричных представлений. Это означало, что если вы выбираете что-либо через представление, то должны получить код ошибки при попытке вставить что-либо в область действия этого представления. И мы добавили функцию симметричных представлений в первый выпуск. Так что цель первого выпуска заключалась в том, чтобы получить работающую систему с минимальным добавлением функций и как можно скорее ее выпустить.

Джон Науман: Было много аналогичных вещей, которые делались в Эндикотте; например, трансляция PL/1 в PL/S; мы должны были это сделать.

Жозефин Ченг: Это уже было сделано в Эндикотте.

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

Роджер Миллер: Мы были вынуждены переделывать, переделывать и переделывать, потому что постепенно понимали, в чем нуждается код System R. Я много раз перестраивал PTREE.

Жозефин Ченг: В любом случае, это был действительно полезный опыт.

К. Мохан: Смотрели ли вы видеоленты в процессе выполнения этой работы?

Жозефин Ченг: Да. Кроме того, мы снимали на видео каждого из группы RDS, кто приходил в STL и читал нам лекции. Народ в Алмаден был очень склонен к сотрудничеству. Мы всегда получали ответы на все задаваемые вопросы, и мы всегда незамедлительно получали требуемую помощь.

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

(65) Замечание Роджера Миллера: "Насколько я помню, HOP в System R - это High Performance Optimizer".

(66) OLTP означает Online Transaction Processing.

(67) В RSS поддерживалась возможность простого поиска: можно было специфицировать "аргумент поиска" (SARG) в виде простого сравнения в канонической форме (например, зарплата больше константы), и RSS выполняла поиск по указанному пути. Это позволяло увеличить эффективность. Для того, чтобы можно было воспользоваться этой возможностью, программное обеспечение более высокого уровня должно было распознавать ситуации, в которых можно было использовать SARG. Если оператор SQL содержал предикат, соответствующий модели SARG, то этот предикат назывался sargable.

(xi) Здесь какая-то путаница, которую я не стал править. Используемый в оригинале оборот "modulo" four означает остаток от деления на четыре, который при традиционной интерпретации может иметь значения 0, 1, 2 и 3. Т.е. на самом деле при этом используются не четыре, а два разряда. Чтобы их было четыре, нужно использовать modulo sixteen. (Прим. переводчика.)

Страницы: назад 1 2 3 4 5 6 7 8 9 10 вперед

Новости мира IT:

Архив новостей

Последние комментарии:

Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...