Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

29.06.2016

Новости:


Все новости

Точка зрения

Беседа Марго Зельцер с Майклом Стоунбрейкером

Майкл Стоунбрейкер – один из самых известных и самых активных представителей мирового сообщества баз данных. Помимо того, что он руководил всемирно известными исследовательскими проектами СУБД Ingres и Postgres, которые во многом способствовали развитию технологии баз данных, в течение своей жизни он основал ряд стартапов, ориентированных на коммерческую реализацию передовых идей в области управления данными. Первой компанией Стоунбрейкера была основанная в 1982 г. Ingres Corporation, которая смогла довести университетскую систему Ingres до уровня передового коммерческого продукта. Через 10 лет Стоунбрейкер основал компанию Illustra, предназначенную для коммерциализации Postgres. Позже продукт этой компании стал основой передового объектно-реляционного продукта компании Informix Universal Server, принадлежащего теперь IBM. В конце 1990-х Стоунбрейкером была основана компания Cohera Software, специализировавшаяся на производстве средств интеграции данных. В 2003 г. Майкл основал компанию StreamBase (http://www.streambase.com/), выпустившую успешный продукт для обработки потоковых данных. Наконец, в 2005 г. Майкл Стоунбрейкер основал компанию Vertica (http://www.vertica.com/), целью которой является создание производственной СУБД, ориентированной на хранение табличных данных по столбцам.

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

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

За последние 30 лет Майкл Стоунбрейкер (Michael Stonebraker) оставил в мире баз данных множество неизгладимых следов. Формирование наследия Стоунбрейкера началось с Ingres, ранней реляционной СУБД, изначально разработанной в Калифорнийском университете в Беркли, где он преподавал в течение 25 лет. Технология Ingres жива и сегодня как в коммерческих продуктах Ingres Corporation (http://www.ingres.com/), так и в свободно распространяемом программном обеспечении PostgreSQL (http://www.postgresql.org/). Будучи плодовитым предпринимателем, Стоунбрейкер также основал успешные компании, ориентированные на рынки федеративных баз данных и потоковой обработки данных. В 1998 г. он был избран в Национальную инженерную академию (National Academy of Engineering, http://www.nae.edu/), и в настоящее время является приглашенным профессором компьютерных наук в MIT (http://www.mit.edu/). Интервьюером Стоунбрейкера является Марго Зельцер (Margo Seltzer), одна из основателей компании Sleepycat Software и разработчиков популярного встраиваемого процессора баз данных Berkeley DB (http://www.oracle.com/database/berkeley-db/index.html), который теперь принадлежит компании Oracle (http://www.oracle.com). Теперь Зельцер проводит большую часть своего времени, занимаясь преподаванием и исследовательской работой в Гарвардском университете (http://www.harvard.edu/), профессором компьютерных наук которого она является. Марго любезно согласилась уделить свое время на то, чтобы совершить небольшое путешествие вниз по реке Чарльз для беседы со своим бывшим научным руководителем Стоунбрейкером в замечательном Stata Center в MIT.

МАРГО ЗЕЛЬЦЕР: Мне кажется, что в последние несколько лет возросла скорость, с которой Вы основываете компании. Это объясняется тем, что у Вас стало больше свободного времени, или же тем, что происходит в индустрии?

МАЙКЛ СТОУНБРЕЙКЕР: Думаю, что верным, конечно, является второе объяснение. В индустрии происходит то, что поставщики крупных продуктов управления базами данных, которых я буду называть «слонами», продают «безразмерную» (one-size-fits-all) архитектуру 30-летней давности, датируемую концом 1970-х.

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

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

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

ЗЕЛЬЦЕР: Какие новые рынки более склонны к поставщикам, которых мы будем называть «мелкими мышками», чтобы отличать их от громадных «слонов»?

СТОУНБРЕЙКЕР: Есть целая куча таких рынков. Начнем с хранилищ данных. Они не существовали до начала 1990-х. Никому не хотелось выполнять крупные непредвиденные запросы над транзакционными базами данных, поскольку никому не хотелось загубить такие системы, которые просто не могли справляться с такими запросами.

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

Другим заслуживающим внимания рынком является рынок систем потоковой обработки данных. На Уолл-стрит все занимаются электронной торговлей ценными бумагами. По стене бежит поток исходных данных, который нужно пропускать через поток работ для нормализации символов, очистки данных, отбрасывания аномальных значений и, наконец, вычисления «скрытой изюминки» (secret sauce).

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

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

Верьте или не верьте, но я полагаю, что аналогичное утверждение можно сделать и по поводу систем OLTP (online transaction processing, оперативная обработка транзакций). Я работаю над специализированным механизмом обработки бизнес-данных и думаю, что на эталонном тестовом наборе TPC-C он будет работать в 30 раз быстрее, чем продукты «слонов».

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

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

ЗЕЛЬЦЕР: Если бы можно было перемотать историю на 20 лет назад, в этой комнате мог бы находиться кто-то еще, говорящий примерно следующее: «Сегодня люди создают объектно-ориентированные приложения, и реляционные базы данных в действительности не подходят для работы с объектами. Мы сможем добиться повышения производительности на пару порядков величин, если построим модель данных, основанную на объектах, а не на отношениях».

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

СТОУНБРЕЙКЕР: Отличный вопрос. Почему ОО (объектно-ориентрованные) базы данных потерпели неудачу? По моему мнению, проблемой ребят из ОО-мира является то, что они, по существу, разрабатывали систему, ориентированную на удовлетворение потребностей механических и электронных САПР. Беда в том, что рынок САПР не приветствовал их системы. Они очень неудачно продавались на рынке САПР.

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

Ребята из мира ООБД не смогли обеспечить большую скорость, чем проприетарные доморощенные системы, присутствовавшие на рынке САПР. В области САПР уже имелись горы проприетарного кода, поддерживающего все требуемое редактирование. Ребята из мира ООБД просто не предоставляли решения достаточно большой части проблемы, не обеспечивали большей скорости, и поэтому они не имели успеха на рынке САПР.

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

ЗЕЛЬЦЕР: Позвольте мне немного развить эту тему. У людей с Уолл-стрит имеется масса самодельного программного обеспечения, делающего ровно то, о чем Вы говорили. В чем состоит неотразимый довод для их перехода на другую технологию, чем отличается эта ситуация от неприятия миром САПР технологии ООБД?

СТОУНБРЕЙКЕР: Есть два очень простых ответа. Первый ответ состоит в том, что объемы данных превосходят все пределы, и с ними вот-вот перестанут справляться существующие унаследованные инфраструктуры. Это является мощным доводом для того, чтобы попробовать пользоваться чем-то новым.

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

Один из пилотных проектов компании StreamBase [основанной Стоунбрейкером в 2003 г.] выполнялся для крупного международного инвестиционного банка с отделениями биржевых операций с облигациями в Токио, Нью-Йорке, Лондоне, Париже и нескольких других местах. В каждом из этих отделений использовалось доморощенное программное обеспечение, созданное на месте. Все отделения устанавливали новые цены на облигации на лету. Например, типичным алгоритмом является следующий: «Если двухлетние казначейские облигации изменяются в цене на пять базисных пунктов, изменить цену на пятилетние облигации компании General Motors на три базисных пункта». Эти правила встроены в системы. Поэтому все отделения корректируют свои цены и публикуют их в электронной форме. Внутренние трейдеры внутри этой конкретной организации видят те же данные, что и персонал отделения биржевых операций с облигациями. Если трейдеры сумеют отследить ситуацию и купить или продать облигации, для которых персонал отделения биржевых операций еще не успел скорректировать цену, то они, безусловно, выиграют.

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

ЗЕЛЬЦЕР: Многие люди сказали бы, что проблема производительности уже решена; процессоры являются достаточно быстрыми. Вы же говорите, нет, на самом деле, проблемы производительности и времени задержки все еще существуют. Производители аппаратуры дают нам процессоры с несколькими ядрами, повышая уровень параллелизма, но в действительности они снижают скорость выполнения команд в одном потоке управления. Как это соотносится с тем, что Вы наблюдаете в мире потоковой обработки данных?

СТОУНБРЕЙКЕР: Я могу пояснить то, что происходит, на очень простом примере. До последнего времени все использовали составные потоки данных от таких компаний, как Reuters и Bloomberg. Однако у этих потоков время задержки составляет сотни миллисекунд от реально наступившего момента времени до того момента, когда соответствующие данные будут получены от поставщиков составных потоков.

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

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

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

ЗЕЛЬЦЕР: Значит, это не задержка выполнения команд, а задержка архитектуры?

СТОУНБРЕЙКЕР: Именно так.

ЗЕЛЬЦЕР: Из этого следует, что создаваемые в настоящее время архитектуры программного обеспечения являются неправильными.

СТОУНБРЕЙКЕР: Ну, как основатель компании Sleepycat, Вы можете легко уловить аналогию со следующей ситуацией. Если Вам требуется возможность читать и писать элемент данных из прикладной программы за время, меньшее миллисекунды, то Вам не удастся добиться этого с использованием какой-либо «слоновой» базы данных, поскольку потребуется переключать процессы и доставлять сообщения в эти системы. Придется либо использовать встроенную базу данных, либо отказаться от этой затеи.

На рынке систем обработки потоков данных имеет смысл только одна разновидность баз данных – встраиваемые базы данных. При использовании любых других баз данных задержка будет слишком велика.

ЗЕЛЬЦЕР: Это Вы проповедуете церковному хору. Но давайте поговорим о той части мира, в которой «слоны» остаются слонами, но не стоят на одном месте. Можете ли Вы реально конкурировать со «слонами» в долговременной перспективе? Что если «слоны» разберутся в ситуации и скажут «ОК, наш большой сервер не справляется с этим; построим-ка мы сервер поменьше, который справится». Правильно? У них имеется масса программистов.

СТОУНБРЕЙКЕР: У меня сложилась намного более целостная картина происходящего. Крупные поставщики продвигаются довольно медленно, по крайней мере, в мире баз данных. Поэтому мне кажется, что переход к новой технологии состоит в том, что «слоны» просто не работают с новыми идеями. Они ожидают, пока начинающие компании не убедятся в работоспособности этих идей. Идеи сначала приходят в начинающие компании. А потом уж с ними разбираются «слоны».

ЗЕЛЬЦЕР: Значит, стартапы необходимы для инноваций, поскольку «слоны» не могут вводить новшества – именно в этом ответ?

СТОУНБРЕЙКЕР: Я так полагаю.

ЗЕЛЬЦЕР: Давайте проведем различие между развивающейся и прорывной технологиями. Развивающаяся технология – это что-то новое и, возможно, отличающееся от старого. Прорывная технология – это развивающаяся технология, которая, в конце концов, заменяет старую технологию. Как Вы думаете, эти новые вертикали баз данных, которые Вы выявили, являются развивающимися или прорывными?

СТОУНБРЕЙКЕР: Ну, у «слонов» никогда не было рынка систем обработки текстов, так что это просто совсем другие продукты.

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

Обработка потоковых данных – это, в значительной степени, новая область. Это просто непаханное поле, которого не было 20 лет тому назад, а теперь оно существует.

И я думаю, что если мне повезет с созданием OLTP-процессора, который будет в 30 раз быстрее существующих систем, это будет прорывная технология.

ЗЕЛЬЦЕР: Давайте поговорим о том, как может произойти прорыв, в то время как некоторые люди думают, что уже никто не покупает базы данных; все покупают только приложения. Чтобы совершить настоящий прорыв, необходимо завоевать приложения. Может ли это сделать крошечная начинающая компания?

СТОУНБРЕЙКЕР: Это наиболее очевидно в области хранилищ данных, где оказалось, что очень хорошо работает Teradata (http://www.teradata.com/). В Фрэмингхэме есть начинающая компания Netezza (http://www.netezza.com/), которая тоже очень хорошо с этим справляется. Она продает проприетарную аппаратуру, на которую поначалу никто в мире не хочет смотреть, но она очень успешна. Почему кто-то покупает проприетарную аппаратуру? Потому что они испытывают большие трудности.

На рынке хранилищ данных людям приходится преодолевать серьезные проблемы. Имеется несколько источников этих проблем. Один из них – это непредвиденные запросы к хранилищам данных. Сложность запросов возрастает почти в квадратичной зависимости от размеров базы данных. Поэтому, если приходится иметь дело с небольшим хранилищем данным, вполне достаточны платформа Wintel и SQL Server.

Но затем, если вы потеряете интерес к SQL Server, который больше не масштабируется, вы столкнетесь с потребностью в скачкообразной массивной модернизации (forklift upgrade) до чего-либо вроде Sun Solaris и Oracle. Это означает переход к другой аппаратуре, другой базе данных и другой операционной системе. Коротко говоря, массивная модернизация – это изменение, с которым ужасно трудно справиться.

Если вы уперлись в эту стену, и решением является массивная модернизация, то у вас возникли серьезные проблемы.

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

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

ЗЕЛЬЦЕР: По-моему, Вы фактически согласились с мыслью, содержащейся в моем вопросе, о том, что люди не покупают базы данных, а покупают приложения. Приложением, которое Вы только что описали, является хранилище данных. Каждый пользователь может выполнять над хранилищем данных различные запросы, но хранилище данных – это всего лишь приложение.

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

СТОУНБРЕЙКЕР: На этот вопрос можно ответить, взглянув на историю Tandem. Эта компания заработала кучу денег, являясь серьезным игроком на рынке OLTP; продукты Tandem используются на Нью-йоркской фондовой бирже (New York Stock Exchange, NYSE). Но Tandem начинала не с OLTP; она начинала свою деятельность на рынке аппаратных средств. Вряд ли бы NYSE доверила свои данные начинающей компании с 20 работниками.

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

Если вы основываете компанию, вам следует заручиться поддержкой двух-трех огромных «слонов»-потребителей приложений, готовых принять на себя тяготы, чтобы придать вашей компании легитимность. Например, у компании Vitria (http://www.vitria.com) Дейла Скина (Dale Skeen) вначале основным заказчиком была компания FedEx. Требуется приложение, прокладывающее путь.

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

ЗЕЛЬЦЕР: Классический подход прорывной технологии.

СТОУНБРЕЙКЕР: У всех стартапов с прорывной технологией имеется эта проблема. Как получить легитимность в мире корпоративного программного обеспечения, в котором продукты должны действительно работать?

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

ЗЕЛЬЦЕР: Значит ли это, что Вы собираетесь заняться языками или инструментальными средствами?

СТОУНБРЕЙКЕР: К сожалению, я слишком мало об этом знаю.

ЗЕЛЬЦЕР: Но других это раньше не останавливало.

СТОУНБРЕЙКЕР: Сейчас мы общаемся с базами данных, используя ODBC и JDBC, встроенные в языки программирования. Это наихудшие интерфейсы на нашей планете. Я имею в виду, что они настолько ужасны, что их не пожелаешь даже злейшему врагу.

C++ и C# – это очень большие и трудные языки, содержащие массу разных языковых средств. Я большой поклонник небольших языков, таких как PHP и Python.

Взгляните на такой язык, как Ruby on Rails (http://www.rubyonrails.org/). Этот язык расширен встроенными средствами доступа к базам данных. Не нужно обращаться к SQL; достаточно сказать: «for E in employee do», и для доступа к базе данных используются языковые конструкции и переменные. Это существенно облегчает работу программиста.

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

ЗЕЛЬЦЕР: Теперь я хочу немного поджарить Вам пятки. Вы не только присутствовали при рождении реляционных баз данных, но были одним из инициаторов и застрельщиков этой технологии. Собираетесь ли Вы входить в число влиятельных лиц, способствующих ее гибели?

СТОУНБРЕЙКЕР: Давайте снова взглянем на Ruby on Rails. Этот язык не похож на SQL. Если должным образом расширить интересные языки, то они не превратятся в SQL и не будут иметь с ним ничего общего. Так что я думаю, что от SQL можно было бы отказаться.

В общих чертах, в Ruby on Rails реализуется модель «сущность-связь», а затем, по существу, происходит ее компиляция в ODBC. Недостатки ODBC сглаживаются за счет встраивания в язык модели «сущность-связь».

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

Если заняться построением множества различных механизмов для множества различных вертикальных рынков, все эти разговоры про интерфейсы языков программирования и модели данных могут повиснуть в воздухе. Мы живем не в 1970-м году. Прошло 37 лет, и нам следует переосмыслить то, что мы пытаемся достичь, и какие для этого требуются правильные парадигмы.

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

СТОУНБРЕЙКЕР: Если посмотреть на реляционную модель Теда Кодда и сравнить ее с SQL, то в контексте SQL почти ничего невозможно доказать. Имеется замечательная статья Криса Дейта (A Critique of the SQL Database Language, ACM SIGMOD Record, 1984), в которой страница за страницей объясняется, почему семантика языка SQL ужасна. Я думаю, мы слишком далеко отошли от исходных ясных идей Теда Кодда.

ЗЕЛЬЦЕР: Неужели мы настолько оторвались от своих корней, что они больше для нас ничего не значат?

СТОУНБРЕЙКЕР: Я думаю, что так и есть, и я думаю, что для этого имеется вполне уважительная причина, поскольку исходная идея Теда Кодда состояла в том, чтобы привести в порядок систему компании IBM IMS (Information Management System) и обработку бизнес-информации. Теперь нам нужны полуструктурированные данные и хранилища данных, и проблема гораздо обширнее, чем то, о чем он говорил 37 лет тому назад. Мы взяли то, что представляло собой вначале один стандарт, и превратили его в огромный ком из многочисленных слоев макулатуры.

ЗЕЛЬЦЕР: Который никому не понятен.

СТОУНБРЕЙКЕР: И поэтому наше сообщество стандартизаторов работает в режиме «только добавления», из-за чего у нас образуется все больше и больше барахла. Нельзя построить небоскреб, воздвигая его год за годом по одному этажу в год.

ЗЕЛЬЦЕР: Мне всегда нравилась точка зрения, что нужно начать нанимать программистов, чтобы они удаляли строки кода, а не только производили новые строки.

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

СТОУНБРЕЙКЕР: Повидав программистов, студентов и технологов на обоих побережьях, я нахожу, что их больше на Западном побережье, но умные люди имеются, конечно, повсюду.

Сообщество венчурных капиталистов на Восточном побережье более консервативно. Знаете ли, среди них больше тех, кто носит галстук-бабочку.

Я не чувствую разницы в интеллектуальном климате. Я думаю, что в MIT имеются умнейшие люди, и в Стэнфорде, и в Беркли.

ЗЕЛЬЦЕР: Майк, Вы забыли еще один университет вверх по реке.

СТОУНБРЕЙКЕР: Я приветствую Вашу работу в области компьютерных наук в Гарварде, и я желаю, чтобы в Гарварде предельно серьезно относились к компьютерной науке, потому что в ней имеется колоссальный потенциал, который со временем может быть реализован.

ЗЕЛЬЦЕР: Хорошо, пойдем к своим студентам!



ACM Queue

Комментарии

Сергей Кузнецов, Sun Aug 3 14:51:55 2008:
Анониму987654321 Интересно, какую идею здоровой и доказанной полагает этот аноним относительно обработки потоков данных? Вообще, конечно, стиль замечательный. Так, между прочим, полить уважаемого человека, даже не подписавшись, это, господа, по-советски.
Аноним987654321, Sat Aug 2 18:37:58 2008:
Человек решил срубить немного бабок, на противостоянии здоровой и доказанной идее. Деньги не пахнут, в штатах близок кризис. Это написано для тех кто: "устанавливает компьютеры поближе к бирже". Умные люди на этой бирже выигрывают, значит должны быть и проигравшие дураки. Именно на них он о планирует сделать бизнес. Тщетно. Желающих это сделать очень много.
Сергей Кузнецов, Tue Sep 11 23:49:56 2007:
Наберите в строке поиска на сайте citforum "схема снежинка" и Вы найдете ответы на свой вопрос.
Александр, Tue Sep 11 17:20:56 2007:
Что это за структура данных такая - снежинка ?
Андрей, Wed Jul 25 13:24:11 2007:
Отличная статья. Спасибо.

Комментарии заморожены.

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

Самое интересное:


© 2004–2009 Проект CITCITY.ru