Главный архитектор реляционной СУБД Ingres, объектно-реляционной СБД Postgres и федеративной системы обработки данных Mariposa о StreamBase и своих новых проектах
Майк Стоунбрейкер: «Если говорить о будущем, то, как мне кажется, останется не больше шести (а то и меньше) программных гигантов, и в их число, безусловно, войдут Microsoft, SAP и Oracle»

За плечами Майка Стоунбрейкера солидная карьера в сфере ИТ, особенно в области управления данными. Он был главным архитектором реляционной СУБД Ingres, объектно-реляционной СБД Postgres и федеративной системы обработки данных Mariposa. Он был основателем и директором по технологиям компаний Ingres, Illustra и Cohera, а также директором по технологиям Informix и Required Technology. Его последний проект — компания StreamBase Systems, основателем и директором по технологиям которой он является. В интервью редактору еженедельника InfoWorld Полу Крилу Стоунбрейкер рассказал о StreamBase и своих новых проектах, а также о проектах ряда других компаний.

Каковы цели StreamBase?

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

Вы сказали, что это системное программное обеспечение. Если это не аналог баз данных, то на что оно похоже?

Когда я говорю «системное программное обеспечение», я имею в виду такие вещи, как СУБД, серверы приложений, средства поддержки обмена сообщениями. Есть огромная разница между тем, что делает СУБД, и тем, что должна делать наша система. Например, темпы электронных торгов определяют скорость поступления данных на все биржи, поскольку системы электронных торгов очень хороши в качестве своего рода зонда для изучения рынка. Итак, скорость передачи данных на Уолл-стрит растет, торги продолжаются, и система электронных торгов должна обрабатывать данные мгновенно. «Мгновенно» означает время ответа на уровне миллисекунд, при этом на входе — огромные потоки данных. У нас есть механизм, который для этого прекрасно подходит. Сейчас мы предлагаем решения практически только для финансовых служб. Мы новая компания. У нас работает всего 25 человек. Финансовая отрасль готова пойти на риск, обратившись к услугам новых компаний. Они хотят использовать новые технологии. Кроме того, огромные перспективы для StreamBase открываются в военной сфере и в области внутренней безопасности.

Почему именно здесь?

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

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

Верно ли, что StreamBase не использует модель транзакций?

Действительно, ни одно из этих приложений не опирается на транзакционный механизам. Это отнюдь не традиционная модель обработки данных...

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

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

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

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

Как работает ваше программное обеспечение?

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

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

А где хранятся данные?

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

Мы выполняем обработку сообщений такого же рода, как это происходит при передаче данных в виртуальной памяти. Никто не обязывает вас хранить данные... Это не база данных. Мы предлагаем механизм, способный выполнять обработку потоков по мере их поступления. Отсутствие необходимости хранить данные позволяет определенному классу приложений работать, причем работать быстрее... Наша реализация в одном конкретном приложении позволяет обрабатывать 140 тыс. сообщений в секунду на обычном ПК. И на общую реализацию ушло всего несколько дней. Мы опробовали то же приложение в одной из крупных реляционных СУБД, то есть на большой коммерческой реляционной базе данных. В лучшем случае нам удалось добиться обработки 900 сообщений в секунду.

А подходит ли для этого XML?

XML — последнее, чем мы стали бы заниматься.

Почему?

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

Планирует ли компания StreamBase работать над какими-либо свободно распространяемыми программами?

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

Вы не планируете сделать StreamBase свободно распространяемой?

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

Что вы думаете о судьбе Informix, Ingres, Postgres, которыми вы занимались прежде?

Я думаю, что Ingres не идет на пользу отсутствие должного внимания к ней со стороны Computer Associates. Превратить эту систему в свободно распространяемую — весьма разумная маркетинговая стратегия CA, стремящейся придать развитию и распространению Ingres определенный импульс. Меня лишь удивляет, что в этом направлении прилагается недостаточно усилий, да еще и слишком поздно. Это монолитная, серьезная реляционная система управления базами данных... Я считаю, что это прекрасная реляционная СУБД, способная весьма и весьма серьезно конкурировать с продуктами типа MySQL.

А что вы скажете по поводу Postgres?

Postgres (которую также называют PostgreSQL) всегда была свободно распространяемой СУБД. И у нее есть приверженцы, которые занимаются ее поддержкой и модернизацией, стремясь и дальше ее развивать. Было бы прекрасно, если бы кто-то, обладающий определенными маркетинговыми ресурсами, занялся продвижением этой системы, поскольку, с моей точки зрения, она имеет обширную функциональность.

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

Что вы думаете об Informix, учитывая, что вы принимали участие в приобретении Illustra?

Я думаю, что в IBM сейчас такая путаница, что никто на самом деле не знает, что и с чем сейчас происходит. Informix был продан IBM, и, таким образом, IBM стала наследником двух вариантов кода. Они получили код Illustra и унаследовали весь код Informix. Вам следует у них спросить, что они собираются делать с этими двумя вариантами... Мне кажется, что в DB2 появилось множество прекрасных возможностей из Informix 9.0.

Например?

Informix-Universal Server имеет очень неплохой модуль для работы с временными рядами, который прекрасно подходит для хранения накопленных данных о финансовых службах. Насколько я понимаю, они взяли этот модуль и добавили его в DB2. Они взяли все, что можно, из Universal Server и поместили это в DB2. Мне представляется, что их стратегия заключается в том, чтобы перевести всех пользователей Informix на DB2 и все хорошее из Informix перенести в DB2.

Вы не считаете, что Oracle пытается объять необъятное, занимаясь приложениями и покупая PeopleSoft? Удастся ли им справиться с таким приобретением?

Покупка PeopleSoft, с моей точки зрения, согласуется с их целью стать крупным игроком на рынке приложений. Насколько я могу судить, их рыночная стратегия заключается в том, чтобы дать все и всем. Это требует от них очень четких действий, а также постоянного приобретения опыта работы в разных областях. Самое сложное — интегрировать технологию PeopleSoft, не отпугнув пользователей. У них сейчас хлопот полон рот. Поэтому я желаю им удачи. Если же говорить о будущем, то, как мне кажется, останется не больше шести (а то и меньше) программных гигантов, и в их число, безусловно, войдут Microsoft, SAP и Oracle.