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

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

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

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

Майк Блазген: Вот брошюра отдела Computer Science [IBM San Jose Research], которую мы издали в конце 1978 или начале 1979 г. В ней имеется фотография всего отдела - все люди, находящиеся в этой комнате, присутствуют на фотографии. Она была сделан в нескольких шагах отсюда, за строением 28. Эрик Карлсон (Eric Carlston), Т.К. Чен (T.C. Chen). Здесь имеется еще и список публикаций, интересно посмотреть, у кого он самый длинный. Ответ на этот вопрос, вероятно, не изменился. Вероятно, в этом году он такой же, каким был в том году. Это публикации отдела Computer Science за 1977-1978 г.г. Как вы думаете, как зовут человека, у которого больше всего публикаций?

Все: Aстрахан [смеются]

К моему удовольствию, у Блазгена две, так что я не пустомеля. У Чемберлина имеется "Data Base System Authorization" в Foundations of Secure Computing42. Вероятно, ее даже нет в его CV(vi). Здесь имеются Чемберлин, Грей, Гриффитс, Мресс, Трейджер и Вейд. Но, конечно, правильный ответ - Рон Фейджин (Ron Fagin), у которого около десяти публикаций. Эти ребята-теоретики всегда побивают нас, ребят-системщиков. А Фрэнк Кинг написал "The phonetic encoding of word-components for the computer input of Chinese characters". Это его единственная публикация в списке. Я пущу его по кругу, и люди смогут посмотреть. В нем много хороших вещей.

Вернемся к основной теме. Несмотря на наличие некоторой оппозиции, мы планируем посвятить по крайней мере часть этой дневной сессии материалу до 1982 г. Есть ли замечания или предложения? Потому что мы не все сделали; мы не поговорили про совместные исследования; мы не упомянули взаимодействия с Санта-Тереза. И поскольку ланч начнется в полдень, у нас имеется всего 40 минут. У нас есть видеоленты, которые мы собираемся вам показать. Мы покажем вам небольшой набор слайдов до того, как идти на ланч. OK? Некоторые из вас могли видеть слайды прошлым вечером. У нас имеются видеоленты той эпохи, начиная с 1979 г., и вы можете увидеть, как выглядели тогда, если окажетесь на ленте.

Это [начинает показывать слайды про System R] была беседа, на которую мы собрались во времена System R. Простота использования. Смотрите, мы охватываем все основы; здесь важно все, не так ли? Упустили ли мы что-нибудь? Мы взяли PL/1, мы взяли VM и MVS; других значительных операционных систем не было...

Марио Школьник: И все это под девизом простоты использования.

Майк Блазген: Конечно, имеются люди, которые делают больше, чем их менеджер. У нас была всего одна база данных. Вот наш анонс SEQUEL. Как раз здесь под номером четыре и вроде этого имеется запрос "Найти имена и размер заработной платы служащих, работающих больше своего менеджера". "Прибавить к заработной плате всех программистов отдела 50 по тысяче долларов" - обычно это было K55, так ли это сейчас?

К. Мохан: И сейчас K55.

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

Вот прикладная программа. Вот на что был похож SEQUEL, если кто-нибудь не помнит. Требовался знак доллара, потому что у нас имелся сканер для PL/1, поэтому мы искали недопустимые разделители. Так что мы всего лишь просматривали программу и искали в ней недопустимые символы. Знак доллара был недопустимым в PL/1: нельзя было сказать $DECL. Вот "Let a cursor be", OPEN, FETCH; коды System R; конечно, это те коды, которые хотел Эллисон. Вот та же самая фотография, которую вы видели наверху. MVS еще в скобках. Это позволяет датировать фотография, потому что MVS стали упоминать без скобок в 1979 г. Выполнение. О да, мы загружаем ... Эффективность ... Больше гаек. О, транзакции. Почему этот проект превратился в исследовательский проект по поводу транзакций, блокировок и журнализации? В действительности, основным вкладом этой работы оказались вещи, которые упорно публиковались в статьях, вся работа, выполненная Джимом и его коллегами.

О, это история INGRES, PRTV, QBE и всей System R ... вот R* ... это позволяет установить дату. На самом деле, это презентация, которую я делал в SHARE(vii) в Атланте сразу после объявления SQL/DS. Здесь начало System R; статья в TODS 1976 г.; первая инсталляция в Pratt & Whitney(viii) в 1977 г. Первая инсталляция System R была произведена в 1977 г. Вот содержание всех статей, которые мы писали. Мы считали этот набор полным, но едва ли он настолько полон, что и 1600 страниц, требуемых сегодня.

Джим Грей: ?, мне нравится этот слайд.

Майк Блазген: ... О, это "Заработная плата индейца больше заработной платы его начальника". Неопределенные значения. Поддержка неопределенных значений. Помню, что собирался поговорить с Тедом Коддом о поддержке неопределенных значений. [смеется] Мы не могли договориться - RSS и RDS не могли договориться об этом, так что в конце концов группа RSS сказала: "Ребята, решайте как хотите; мы будем делать что угодно". Мы поддерживали общие неопределенные значения.

Франко Путцолу: В то время мне не нравились неопределенные значения.

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

Джим Мехл: Я помню записку Франко, адресованную "теологам неопределенных значений". [смеется]

Майк Блазген: Непросвященные не знают даже, о чем мы говорим. Если вы не знаете возраст кого-либо ...

Брюс Линдсей: Я только что нашел "Revisions to the NULL Memo".

Майк Блазген: Относительно неопределенных значений велись большие споры. Например, если вы не знаете чей-то возраст, но имеете массу другой информации о нем, то можно захотеть поместить эту информацию в базу данных, не желая сообщить возраст. Поэтому вы оставляете это поле пустым. Но потом требуется выполнить сортировку по значениям поля "возраст". Где лучше разместить запись о человеке с неизвестным возрастом, в начале, конце или середине списка? Это и есть NULL-теология. Имеются люди, разбивающие яйцо с острого края, а другие предпочитают тупой край. А некоторые разбивают его посередине.

О, вот здорово, представления и авторизация. Это хорошо, я и не знал, что у нас это есть. Не могу прочитать. Видимо, мне был нужен большой экран для этой презентации. О, подсчеты. Я подошел к подсчетам. Мы подошли к ET1 - Eagle Transaction 1, тому, что теперь называют Debit-Credit, или TPC/A, но в то время называлось Eagle Transaction 1.

К. Мохан: Откуда взялось это название?

Майк Блазген: Система Eagle последовала за IMS; ожидалось, что она будет делать все, что угодно. И они очень беспокоились о длинах путей. В IMS было нечто под названием TP1. TP1 являлось, скорее, общим описанием; ET1 - это конкретная программа. Джим описал все это в статье, опубликованной в Datamation. В качестве автора был указан Anonymous et al. или что-то в этом роде43.

Джин Грей: Где-то в 1972 г. компания General Automation победила IMS в Bank of America при выборе продукта для реализации автоматической кассовой системы, и мы увидели атаку убийц-миникомпьютеров, которые намеривались уничтожить наши мейнфреймы. Прошло три или четыре года до того, как компания собралась выйти из бизнеса. Часть людей занималась FS41, часть занималась ...; мы думали, что компьютерная индустрия весьма существенно изменится по причине распространения мини-компьютеров. И тестовый набор, который использовался в Bank of America, был канонизирован в виде TP 1, 2, 3, 4, 5, 6, 7. TP7 был ориентирован на пакетную обработку на мини-компьютерах; TP1 моделировал очень, очень легкую транзакцию "дебит-кредит"; и мы завершили, используя только TP7 и TP1. IMS Fast Path был реализован для того, чтобы хорошо пропускать TP1, это было главной причиной создания IMS Fast Path. TP1 переписали - он представлял собой набор вызовов IMS - в расчете на интерфейс VSS, что было первым названием - придуманным Энди Хеллером (Andy Heller) - того, что в конце концов превратилось в DB2. В одной из своих многочисленных инкарнаций система называлась Eagle ...

Майк Блазген: Говорить, что Eagle - это то же самое, что DB2, значит слегка искажать историю. В основе Eagle не находился реляционный подход, система была в некотором роде последователем IMS.

Франко Путцолу: Ну, мы все происходим от амеб и ...

Майк Блазген: О, я понимаю, все это DNA (ДНК); дерево - это то же самое, что человек, так? С несколькими изменениями в генах. Хорошо, Eagle была деревом.

К. Мохан: Был ли тем же самым менеджер данных?

Жозефина Ченг: Да.

Джим Грей: Это был тот же самый проект.

Майк Блазген: OK, Eagle Transaction переписали ...

Джим Грей: Они переписали в терминах VSS и ...

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

Том Прайс: Вероятно, некоторую бесцеремонность допускает каждый, кто пишет такие вещи.

Майк Блазген: По-моему, мне помогал Боб Селинджер. Он работал на трассировкой. Ты доделал трассировку ET1?

Боб Селинджер: Мы называли это SR1; это был реляционный эквивалент ET1.

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

Итак, чего мы достигли? OK, вы представляете. Имелась эта презентация, которую мы показывали повсюду. Она представлялась на шести конференциях GUIDEix и тринадцати конференциях SHARE и конференциях по базам данных по всему миру. У меня имеются труды одной из последних, которая проходила в 1983 г. в Wang Institute и называлась Eastern Computer Science Colloquium или что-то подобное. Джим, я, Майк Стоубрейкер, Тед Кодд - о, какой длинный список хороших имен ... Непроцедурность, куча оптимизации ... Это одно из моих любимых выступлений. В нем говорилось о том, что существует много способов делать такие вещи и что требуется оптимизатор, производящий выбор ... Вот это мне нравится: избегает экспоненциального роста времени оптимизации и N-путевых соединений. Разве мы не хороши? И здесь ...

Брюс Линдсей: Восьмимегабайтная база данных; вау!

Майк Блазген: У нас была база данных в восемь мегабайт! [смеется] ...OK, итак, вы представляете.

Я позволю себе на минуту погрузиться в одно из своих воспоминаний. Однажды Ирв и Фрэнк решили изменить структуру управления, и, чего никогда до этого не случалось, Ирв работал на меня, и я стал его менеджером. Мы поменялись местами. Итак, я стал менеджером RSS, а Ирв стал показывать немыслимую продуктивность. [смеется] А я стал поразительно непродуктивным. Я потратил массу времени на подготовку этих слайдов. А потом Леонарду предложили вернуться в Нью-Йорк, чтобы работать на Боба Иванса (Bob Evans) и это было продвижением наверх. Он стал директором. Фрэнк был назначен менеджером отдела Computer Science. Это привело к освобождению должности менеджера систем баз данных, которым был Фрэнк, и я взялся за эту работу. Похоже, что это произошло в конце 1977 г. И я оставался на этом месте до июля 1979 г., когда моей жене предложили работу в Вашингтоне, и я подумал, что мне следует поехать с ней, а не оставаться одному без семьи. Поэтому мы перебрались в Вашингтон, и Робин Вилльямс (Robin Williams) стал моим преемником на посту менеджера систем баз данных. А немного позже ушел Фрэнк Кинг, также вернувшись для работы для Боба Иванса, и пришел Абе Пелед (Abe Peled). А потом отдел немного изменился; он вырос и стал существенно другим. Минуту назад мы говорили, что System R стала более успешной, проект разростался. Например, я помню, что в 1974 г. над System R не работал Дон Слац (Don Slutz). Но ты присоединился к группе RDS в ...?

Дон Слац: В 1975 г.

Майк Блазген: ... в 1975 г., правильно. Вы слышали историю про Франко в 1974 г. Я думаю, что его увлекла некоторая другая работа, а затем и Дона Слаца. Ближе к концу, если вы помните, к нам примкнул Жуан Родригес-Россел (Juan Rodriguez-Rossel), парень, который специализировался в области исследований производительности операционных систем, и мы превратили его в ответственного за производительность System R. Итак, постепенно на нас работала половина отдела, не обязательно над System R, но над относящимися к проекту вопросами. Марио и Пауло Тиберио (Mario and Paulo Tiberio) работали над средством проектирования баз данных, и это средство проектирования открыло возможность использования System R. Несколько проектов, предшествовавших System R, типа EXPRESS45, стали менее крупными; некоторые люди ушли.

Скажу вам, что мой артифакт [брошюра CS] побеждает. Поскольку, пока я говорил, до него добрался один человек и шептал: "Посмотрите сюда!".

Совместные исследования имели выдающееся значение для того, чтобы заставить IBM продвигаться вперед; я не уверен, что это было так уж важно для того, что мы изучали. У Фрэнка была идея проведения совместных исследований; на самом деле, я думаю, что это была идея Ральфа Гомори (Ralph Gomory) или Леонарда, или кого-то еще; я думаю, что она в равной степени принадлежала Ральфу. Итак, прежде всего мы установили связи с Pratt & Whitney Aircraft, затем с Upjohn Pharmaceuticals (Pharmacia & Upjohn) в Каламазу (Kalamazoo), Мичиган. Pratt & Whitney Aircraft находится в Восточном Хартфорде (East Hartford), шт. Коннектикут. И наконец, после годичной задержки, основные связи были установлены с компанией Boeing Aircraft, Сиетл (Seattle), шт. Вашингтон. У нас имеются отчеты; копии отчетов есть у меня, а также лежат вон там [на столе артифактов]. Я думаю, что все это принес Боб Йост. Это, конечно, не стандарт SQL - я имею в виду объем - но была произведена куча бумаг. Я думал, что Дон смог бы рассказать про Pratt & Whiney и Upjohn. Являешься ли ты лучшей кандидатурой для такого рассказа?

Дон Чемберлин: Я один из подходящих для этого людей, но уверен, что есть и другие.

Пат Селинджер: Насколько я помню, главным по контактам с Боингом был Джим Мехл.

Дон Чемберлин: Джим, хочешь ли ты рассказать нам про Боинг?

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

Дон Чемберлин: Хорошо. Как говорит Майк, первое совместное исследование проводилось с Pratt & Whitney в Хартфорде. Я не уверен, что какое-либо из этих совместных исследований действительно смогло проверить все предлагаемые нами умные штуки, такие как параллелизм и транзакции, блокировки и разные уровни согласованности и прочее - в действительности, их не заботили эти возможности. Начальные приложения в Pratt & Whitney: они производили реактивные двигатели и использовали System R для инвентарного учета деталей и поставок, используемых ими при построении ракетных двигателей. В Upjohn в Каламазу System R использовалась для хранения результатов клинических экспериментов, которые применялись компанией для поддержки приложений для FDA (U.S. Food and Drug Administration). По поводу этих совместных исследований мне больше всего запомнилась масса поездок в прекрасные Хартфорд и Каламазу, и это было неплохо. Мы посещали заводы; у нас был визит на завод ракетных двигателей в Хартфорде; мы прошли по всем цехам и увидели, как производятся двигатели; и это было неплохо. Они рассказывали нам, что на каждой стадии производства двигателя должны очень тщательно его взвешивать, чтобы убедиться в отсутствии недостающих или лишних деталей.

Том Прайс: Помню, что когда мы приехали к Pratt & Whitney первый раз, то показали им все системные режимы, которые могли бы понадобиться на их системах VM, а у них уже были системные режимы на тех же линейках - локальные режимы. Была настоящая путаница.

Дон Чемберлин: В особенности мне запомнилась замечательная поезда в Каламазу для встречи с людьми из Upjohn. У них было место, которое они называли усадьбой, замечательный особняк в викторианском стиле на громадном участке за пределами Каламазу. Там были пруд, оранжерея и все виды прекрасных удобств, предназначенных для гостей. Имелись велосипеды-тандемы для поездок по окрестностям и хорошего времяпрепровождения. Они отвели нас в комнату, одна стена которой была полностью заставлена разными видами ликера. Мы спросили, можем ли взять с собой то, что не выпьем. Это было приятное путешествие. [смеется]

В то время происходило множество событий, которые, я думаю, мы должны хотя бы походя упомянуть. Одно из событий состояло в том, что мы были вынуждены изменить название нашего языка с SEQUEL на SQL. Причиной этого была юридическая проблема, с которой к нам обратился юрист. Майк, не мог ли бы ты помочь мне с этим? По-моему, претензия исходила от английской компании Hawker Siddeley Aircraft, которая заявила, что SEQUEL - это их торговая марка. Мы никогда не узнали, что за самолет назывался SEQUEL, но они сказали, что мы не можем больше использовать принадлежащее им название, так что нам пришлось думать, как с этим поступить. Думаю, что именно я выбросил гласные из слова SEQUEL, превратив его в SQL наподобие APL и других языков с трехбуквенными названиями, заканчивающимися на L. Так что, вот как это случилось.

В это время произошли и другие интересные вещи. Наша знаменитая статья, которая была опубликована в TODS: во втором выпуске TODS появилась статья о System R. И вот история об этом. Я хочу доказать вам кое-что, продемонстрировав здесь картинку. Если вы когда-нибудь видели ссылку на эту статью, то из ее заголовка видно, что это замечательная статья с четырнадцатью авторами; каждый, кто принимал какого-либо рода участие в обсуждениях System R, был включен в состав авторов. Это первая страница рукописи этой статьи, которую мы послали в TODS за подписью четырнадцати авторов. Если вам приходилось видеть ссылки на статью, вы должны были заметить, что ее название в опубликованном виде "System R: Relational Approach to Database Management" не включает артикля "A". Когда мы писали статью, она называлась "System R: A Relational Approach to Database Management"; в опубликованном виде "A" в названии исчезло. Причина этого в том, что когда в TODS были готовы гранки, и мы получили их для проверки, то список авторов был упорядочен по алфавиту, и конечно, первым был Астрахан (поэтому многие наши статьи упоминаются как Astrahan et al.). За это Мортон должен был платить вычитыванием гранок. Итак, я отдал гранки Мортону, а статья была довольно длинной, вычитка требовала большого времени, и он был довольно сильно занят. Он довольно хорошо вычитал статью, но не вычитал название. Вот что произошло с артиклем "A".

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

Пат Селинджер: Это произошло, я полагаю, в 1976 г.?

Дон Чемберлин: В 1976 или в 1977 г.

Пат Селинджер: Мне немного затруднительно вспомнить это, но мы беспрестанно отлаживались с запросом "найти людей, которые зарабатывают больше своих менеджеров" и в конце концов дошли до ситуации, когда при выборе оптимизатором индексов, пригодных для реализации этого запроса, оптимизатор решил, что индекс на столбце Salary является достаточно подходящим. И когда при нашем тестировании оптимизатора мы первый раз столкнулись на выбор индекса Salary, мы окончательно убедились, что этот запрос не останавливается. Поскольку мы использовали индекс Salary для поиска в таблице Enployee, и мы также и обновляли ее, и Дон Чемберлин получал все больше и больше прибавок к жалованию. Это делало его очень счастливым, но мы, оптимизаторские ребята, ощущали некоторый дискомфорт. Поэтому мы с Мортоном уселись расследовать это и анализировать, что происходит, а потом пришли на одно из ваших собраний RDS, которое происходило в день Halloween. Мы рассказали группе об этом и изложили свои соображения о том, что мы должны с этим делать. После этого рассказа это стали называть проблемой Halloween. И я думаю, что это название сохранилось до сих пор.

Дон Чемберлин: Она известна в нашей области - каждый знает проблему Halloween. Так случилось, что ее открыли в день Halloween. Имелся такой запрос ... они ввели оператор, действие которого должно было состоять в том, чтобы увеличить на десять процентов заработную плату каждому служащему, получающему меньше $25000. Этот запрос выполнялся успешно, без ошибок, и если бы вы проверили результаты, то убедились бы в том, что все служащие в базе данных получают $25000, поскольку их жалование увеличивалось до тех пор, пока не достигнет этого уровня. Вот как проблема Halloween получила свое название.

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

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

Дон Чемберлин: Имеется еще несколько артифактов времени совместных исследований. Я написал большинство из этих руководств для пользователей во время наших совместных исследований, и мы спроектировали приятный логотип. И Джин Чен помогла мне сделать эти симпатичные папки, многие из которых все еще находятся у вас. У нас была поездка на завод Boenig; мы видели, как они собирают 747-е, а в Upjohn мы наблюдали, как они создают витаминные пилюли. Они бесплатно раздавали витаминные пилюли в кафетерии, и все мы получили этот симпатичный значок. На значке написано: "Повышайте качество. W.E. Upjohn". А вот картинка с парнем, раздавливающим пилюлю большим пальцем. На ней написано: "Upjohn: родоначальник рыхлых пилюль". "Рыхлость" означает возможность раздавить. Итак, W.E. Upjohn был родоначальником рыхлых пилюль, и это является наследием компании Upjohn, и вот все это он сказал. Как вы знаете, у Томаса Ватсона (Thomas Watson)x было много знаменитых изречений, вы помните "полагайтесь на личность" и прочее. В Upjohn они сказали: "Повышайте качество". Это был их девиз.

При разговорах об этих пользователях мы всегда помним Uojohn, Boeing и Pratt ? & Whitney, но я хочу заметить, что было и много других пользователей, главным образом, внутри IBM. Как я помню, в IBM Owego System R использовалась для построения атакующих вертолетов. Было несколько групп в STL46, которые использовали System R для различных назначений; был такой парень Джерри Хаас.Джерри и Фрэнк Нарги??? - вы помните этих ребят?

Брюс Линдсей: SREDIT.

Дон Чемберлин: Да, они построили что-то типа раннего GUI поверх System R, и назвали это SREDIT47. В Пафкипси [IBM] было несколько ребят, которые использовали System R в разновидности системы автоматизации проектирования. В Йорктауне был человек по имени Фред Дамер (Fred Damerau), который работал над запросами на естественном языке. У него был проект с названием REQUEST, основанный на System R. System R была инсталлирована в большинстве научных центров IBM. Алекс Хурвиц (Alex Hurvitz) инсталлировал ее в Лос-Анджелес; Йойчи Такао (Yoichi Takao)- в Токио; Жан-Жак Дюран (Jean-Jacques Dauderande) - в Париже.

Жан-Жак Дюран: У нас еще была совместная работа с компанией, которая разрабатывала некий проект вертолета на основе двухстолбцовых отношений System R; исключительно двухстолбцовых отношений.

Дон Чемберлин: Систему инсталлировали в Мадриде, Гейдельберге, Кембридже; в научных центрах по всему миру.

Боб Йост: Есть ли у кого-нибудь соображения о том, когда перестал существовать последний сайт System R? Мне кажется, что компания Upjohn продолжала использовать System R даже после появления SQL/DS, поскольку они не хотели платить за эту систему. При использовании System R можно было не платить долгое время. Поэтому, я думаю, они долго использовали ее.

Дон Чемберлин: Я не знаю, как долго использовалась система.

Боб Йост: Они запускали ее на Model 145 с одним мегабайтом памяти. Я это видел и сказал: "Боже, я пытался запустить DB2 на своей машине с восемью мегабайтами, и она едва там поместилась."

Дон Чемберлин: Итак, глядя назад, я удивляюсь тому, что по сегодняшним стандартам эта работа была выполнена очень небольшими силами. Я взял с собой несколько бумаг, содержащих цифры. Вот сводка, которую я как-то составил для Фрэнка Кинга, показывающая число людей, вовлеченных в System R на разных стадиях ее существования. Эта сводка относится к периоду с 1973 по 1978 гг. Мы начали работать в составе десяти или одиннадцати человек. И это тогда, когда были инсталлированы прототипы Фазы Ноль и имелись различные инсталляции System R в центрах совместных исследований. Как вы видите, в проекте никогда не работали двадцать человек; вероятно, среднее число участников было около пятнадцати. И после 1977 г. число участников уменьшилось на половину. Так что эта кривая демонстрирует гораздо меньшие трудозатраты, чем это свойственно стандартам Microsoft. Но мы получили очень большое воздействие от этой работы.

Брюс Линдсей: По стандартам Санта-Тереза.

Дон Чемберлин: Что касается размера текста System R, то, поверите вы или нет, он не был очень большим. RDS была главным образом написана на PL/1 и содержала 38000 строк PL/1 и около 9000 строк на языке ассемблера. Сейчас 38000 кода - это немного; я думаю, что довольно трудно найти продукт такого небольшого размера. RSS была написана на PL/S и включала еще 35000 строк. Так что, если сложить эти цифры, System R состояла из приблизительно 80000 строк кода. Это совсем немного по отношению к тому, что мы могли обеспечить.

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

Я храню два списка, называемых списком ошибок и списком пожеланий, которые велись во время совместных исследований. По поводу каждого совместного исследования мы должны были составлять ежеквартальные отчеты и пользователи могли иметь свои пожелания, а я должен был заносить из в список пожеланий; мы не реализовали практически ни одно из этих пожеланий. Я думаю, что ко времени завершения проекта имелось около 160 неудовлетворенных пожеланий. Однако ошибки мы старались исправлять, и у меня имеется некоторая статистика. Вот откуда поступала информация об ошибках. За время проекта у нас было 251 отчетов об ошибках. Большинство из них мы нашли сами, но многие ошибки были обнаружены и в Боинге. Ряд ошибок был найден в разных центрах совместных исследований. Из числа этих ошибок мы исправили 71%, небольшое число ошибочных ситуаций мы не смогли воспроизвести, некоторые заявки на ошибки были отвергнуты и т.д. Так что мы очень старались ...

Джим Грей: Я слышал про десять процентов звезд.

Дон Чемберлин: Да, мы объявляли некоторых звезд. И вот список героев. Это люди, исправившие наибольшее число ошибок в System R. В начале списка - Вейд, и Дон Слац (Don Slutz), Джим Мехл, Ирв Трейджер исправили самое большое число ошибок.

Майк Блазген: В RSS не было никаких ошибок. [cмеется] Нет, это правда, и причина в том, что RSS была написана Франко. Нет, это действительно правда; Франко никогда не писал программы с ошибками. Кроме одной, правда, Брюс? Ведь ты нашел одну?

Брюс Линдсей: Одну.

Майк Блазген: Он написал около половины RSS, и я думаю, что мы нашли одну ошибку. И это было спустя девять лет.

Бред Вейд: Хотя, как я помню, были трудности с управлением индексами ... [смеется]

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

Дон Чемберлин: На самом деле, подобный анализ мной не проводился. Я ничего не могу об этом сказать.

Пат Селинджер: У тебя есть копия?

Дон Чемберлин: У меня имеется копия дома; я не принес ее.

Брюс Линдсей: Нам нужно послать ее людям из SQL 3 [смеется]

Роджер Миллер (Roger Miller): Наш список пожеланий больше похож на базу данных.

???: Он занимает восемь мегабайт?

Роджер Миллер: Нет, восьми мегабайт в нем нет.

Дон Чемберлин: Раймонд, не хотел ли бы ты немного больше поговорить на тему компиляции и интерпретации?48 Ты над этим много работал.

Раймонд Лури: Я не помню этого. [смеется] Я должен сказать, что старался найти записки, которые использовал во время небольшого совещания, но моя система баз данных не справилась с этой задачей. Я помню одно совещание; по-моему, там были Дон, Ирв, Мортон и, конечно, Фрэнк Кинг. Я показывал, как откомпилированная SQL-программа могла представлять собой всего несколько команд ассемблера поверх RSS. Программа была поразительно короткой. Конечно, поскольку мы начали с интерпретатора, мы прошли весь путь и перешли к компиляции в машинные команды. Позже, поскольку Франко это не нравилось, мы вернулись к правильной организации таблиц, а не кода; но, конечно, идея компиляции осталась неизменной, поскольку после единовременной оптимизации получается готовый продукт; впоследствии код может стать недостоверным, если меняются обстоятельства, влияющие на стратегию доступа. Так что это было одним из вкладов в систему. Это было хорошим примером того, как можно изменить ориентацию группы и убедить людей следовать новому направлению. Это был хороший опыт. Кроме того, эта работа привела меня в группу RDS, где я провел несколько лет и очень этим доволен.

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

Майк Блазген: В действительности, это часть истории. Вы знаете, что первый компилятор языка Фортран был, вероятно, лучшим компилятором Фортран в смысле генерации наименьшего числа команд для Фортран-оператора. И для этого были приложены большие усилия. Например, причина того, что оператор условного перехода в Фортране является трехнаправленным - IF (ABC) 1,2,3 - состояла в наличии трехнаправленного перехода в системе команд машины, и поэтому можно было сгенерировать для этого оператора одну команду. Это похоже на CAR и CDR; они с самого начала сильно влияли на эффективность.

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

Дон Чемберлин: Да.

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

Том Прайс: Идея состояла в том, чтобы производить оптимизацию только один раз, но потом использовать интерпретацию.

Майк Блазген: Да, нужно было интерпретировать план.

Франко Путцолу: Не были ли предоптимизированные пакеты подобны представлениям специального вида ...

Майк Блазген: О, это так?

Пат Селинджер: Да, я думаю, что это в точности соответствует представлениям.

Майк Блазген: О, по-моему, это было комбинацией двух этих вещей с их предварительной композицией. Но я помню, что после выступления Раймонда, когда мы решили перейти к компиляции, оставался вопрос, что делать с непредвиденными (ad hoc) запросами. Поскольку Раймонд ничего не доказал по поводу непредвиденных запросов; он кое-что доказал относительно сохраненных транзакций, то, что имеет смысл их компилировать. Так что стоял вопрос "Что делать с непредвиденными запросами?", и с этим была связана куча работы Раймонда, Пат и, возможно, других людей, но я знаю, что Пат в этом участвовала - производила оценки интерпретации неожиданных запросов. Потом появился план: "Мы будем использовать и компилятор, и интерпретатор". И кажется, что это приводило к путанице, хотя бы в смысле строго соблюдения семантики, поскольку имелись две реализации одного и того же. Как следовало поступить? И тогда Пат смогла решить, что мы можем обрабатывать и непредвиденные запросы, и сохраняемые транзакции с помощью компилятора.

Пат Селинджер: Я думаю, что свою лепту внес и Дон.

Марио Школьник: Мы с Мортоном проделали множество измерений касательно числа страниц, затрагиваемых при выполнении непредвиденных запросов. Как-то мы обнаружили ситуацию, когда были угаданы 92 страницы при том, что во время выполнения требовались обращения только к двум. И я помню, как Франко принес текст оптимизатора и сказал: "Давайте исследуем на примере простого запроса, как сократить число страниц, обращения к которым предсказываются оптимизатором". Вот как выполнялась эта работа ...

Франко Путцолу: Да, предложение Рея было хорошим. Без него мы не были бы здесь сегодня.

Майк Блазген: Я думаю, произошло много таких событий, без которых мы не были бы здесь сегодня. Но я согласен, что это было абсолютно критичным. Кстати, когда мы делали ET1, написали транзакцию "дебит-кредит", запускали ее и измеряли все длины путей, то если считать обмен эквивалентным одной команде, длина пути для ET1 составляла около пятидесяти тысяч команд, что являлось достижением. Так что благодаря Раймонду System R стала показывать выдающуюся эффективность, т.е. не было ни одной системы баз данных, которая могла бы работать быстрее System R на сохраненных транзакциях, легковесных транзакциях, составляющих слабое звено реляционных баз данных.

Заметьте, что это действительно правда; я не осознавал этого, но проект немного изменился с ориентацией на ET1 по сравнению с исходной идеей SEQUEL , который в значительной степени был ориентирован на расширение состава компьютерной публики, включая людей, ищущих рецепты, и механиков, желающих узнать, как поменять масло в только что подъехавшей машине. Это произошло за пару лет, и мы все думали, что это здорово. И мы тогда беспокоились о FRR и SRB; вы знаете, что мы хотели использовать SRB-планирование, поскольку при этом можно было сократить длину пути на три команды. О, и Ирв Трейджер довел это дело до конца, и делал все возможное, чтобы выкинуть восемь команд из одной части кода и четыре - из другой. Ты помнишь всю работу, которую делал в RSS?

Ирв Трейджер: Это была Fast-Next.

Майк Блазген: Да, он делал Fast-Next! FNEXT[K1]49. Правильно, в YTABLE1 кэшировались разные объекты. И мы придумали разные хитрости для отслеживания законности содержимого кэша. Но при корректном содержимом кэша Fast-Next позволяла выбросить тридцать команд из NEXT, что явилось ключом к выживанию.

Франко Путцолу: Мы действительно увлеклись машинным языком.

Майк Блазген: Ты думаешь, это было ошибкой?

Франко Путцолу: Да; но с другой стороны я встречаю некоторые системы, работающие аналогичным образом.

(41) G. Radin and P.R. Schneider. An Architacture for an Extended Machine with Protected Addressing. IBM Poughkeepsie Laboratory Technical Report TR 00.2757 (May 21, 1976).

(42) R.Demillo, D. Dobkin, A. Jones, and R. Lipton, editors. Foundations of Secure Computing. Academic Press, New York (1978), pages 39-56.

(vi) Curriculum Vitae - "жизнеописание". (Прим. переводчика.)

(vii) SHARE - ассоциация пользователей компьютерных систем, производимых главным образом компанией IBM. SHARE ежегодно проводит конференции, первая из которых состоялась еще в 1955 г. (Прим. переводчика.)

(viii) Pratt & Whitney - крупнейшая газотурбинная американская компания, существующая с 1925 . (Прим. переводчика.)

(43) Anon et al. "A measure of transaction processing power" Datamation, 31, 7 (April 1, 1985), pages 112-118.

(ix) GUIDE - конференция пользователей информационных технологий IBM.

(45) N.C. Shu, B.C. Housel, R.W. Taylor, S.P. Ghosh and V.Y. Lum. "EXPRESS: A Data EXtraction, Processing, and REStructuring System" TODS 2, 2 (June 1977), pages 134-174.

(x) По всей видимости, имеется в виду Томас Ватсон-старший, который основал IBM и был ее президентом на протяжении почти сорока лет. После него президентом компании стал его сын - Томас Ватсон-младший. (Прим. перводчика.)

(46) STL означает Santa Teresa Laboratory.

(47) Произносилось Шред-ит (Shred-it).

(48) R.A. Lorie and B.W. Wade. "The Compilation of a High Level Data Language" IBM Research Report RJ2598. San Jose, California (August 1979).

(49) Произносилось как Fuh-next.

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

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

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

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

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
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
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...