На все руки
Архив
Почему и как?
Надо или не ндо читать эту статью, и если надо, то как? Если вы уже слышали о событиях, развернувшихся на рынке СУБД, и хотели бы узнать подробности - попробуйте хотя бы просмотреть ее.
Если вы при этом знаете, чем настоящая реляционная СУБД класса Oracle или Informix отличается от dBase или FoxBase, вам, вероятно, лучше пропустить начало и читать прямо с заголовка "Универсальный сервер". В противном случае попробуйте заглянуть в "Четыре колонки", напечатанные на третьей странице этого выпуска "Компьютерры" и названные "Герои своих времен", а также под заголовки "Сервер данных" и "Культура данных", расположенные ниже в этой статье. Если аргументы показались вам неинтересны, или вызвали желание набить автору морду - не читайте эту статью вообще. Автор не обидится. Он писал не для вас.
А для кого же, и, главное, зачем все это написано? Кому охота разбираться в перипетиях субдостроения, тем более, что автор сам не вполне понимает, что у них там происходит? У меня нет ответа, кроме самого банального. Когда грянула перестройка, все мы стали немного политиками. Во время гайдаровского большого скачка - экономистами. Когда делали операцию Ельцину - кардиохирургами. Если бы земле угрожала опасность столкнуться с кометой, мы бы сделались немного астрономами. А когда один из крупнейших рынков компьютерных технологий с оборотом в десятки миллиардов долларов вступает в пору драматических перемен, и это в самом скором будущем может сильно сказаться на содержимом наших серверных и персональных компьютеров, неужели мы останемся в стороне? Нет? Тогда читайте и не жалуйтесь. Вас предупредили.
Давайте начнем с описания примера, который будет использоваться повсюду далее. На рисунке 1 вы видите таблицу "Публикации". Некоторые поля (например: "номер", "название", "страница") совершенно безобидны. Другие (автор) чреваты проблемами, но вполне разрешимыми в рамках современной технологии. Поле "текст" наиболее интересно, поэтому оно выделено красным кружком. Кроме этого, есть таблица "Люди", которая содержит минимальный набор анкетных данных о тех, с кем редакция имеет какие-либо дела, и таблица "Репортеры", с помощью которой о некоторых "людях", выступающих в роли "репортеров", сообщаются дополнительные сведения. В последней представляют интерес три поля - "координаты", "доступ" и "фото". Подразумевается, что кроме "репортеров" есть еще и другие категории авторов.
Последняя таблица - "Выпуски". Она содержит сведения о выпусках нашего еженедельника. Заметьте, что даже привязка номера выпуска к месяцу не так проста. На месяц может приходиться пять понедельников или четыре, а выпусков иногда бывает и три. При этом номера выпусков - не просто числа. Выпуск может иметь сдвоенный номер, как по совершенно форс-мажорным для редакции причинам случилось вот с этим, который вы держите в руках.
Автор не имеет ни малейшего желания вступать в споры о проектировании систем данных (например, хорошо ли использовать роли), и намерен избегать принятой в это области терминологии, говоря, например, о таблицах вместо отношений, о строках вместо экземпляров. На всем протяжении статьи он постарается не упоминать ни сущностей, ни связей, и ни разу не позволит себе выражений на языке SQL.
Сервер данных
Сервер данных играет в системе роль информационного центра, который выполняет все операции по поиску сам, а от клиентов принимает короткие запросы на специальном языке. Например, такие: "дай мне выборку по этому признаку", "запиши вот это вон туда" или "измени то на это вон там". Сервер данных это очень сложный и наукоемкий комплекс программ. Разработать нечто подобное своими силами не стоит и думать, да и украсть не так просто, а экономию труда и аппаратных ресурсов он дает очень большую.
Само собой разумеется, на низком уровне сервер данных выполняет во многом те же функции, что и привычные российским программистам dBase с его потомками (или, вернее, последние выполняют некоторые из функций нормального сервера данных). Он ведет таблицы, которые можно дополнять или изменять в любом месте, а также индексы, ускоряющие доступ. Однако, в терминологии dBase, например, каждая отдельная таблица называется базой данных, а настоящий сервер данных считает базой данных совокупность многих таблиц, которые развивают и дополняют друг друга. Главное, на что он нацелен - это как можно эффективнее выполнять операции реляционного соединения.
По-настоящему ценные данные находятся в коллективном пользовании, и много операторов, ничего не зная друг о друге, одновременно обстреливают сервер своими запросами. Он должен отвечать как можно быстрее, но не показывать изменения в данных, пока они не завершены. Эта проблема решается на нескольких уровнях ответственности.
Во-первых, у самого сервера есть представление о правильном и неправильном - например, он умеет придерживать запросы на чтение, пока идет запрос на запись, чтобы никто не увидел недописанное поле данных или строку таблицы. Во-вторых, программист может заказать непрерывную последовательность операций (так называемую транзакцию), например, чтобы внести цепь взаимосвязанных изменений в несколько таблиц, запрещая чтение из обновляемых областей до полного завершения. Сервер тоже проделывает такие трюки когда ему надо, например, по ходу запроса скорректировать индексы.
Транзакции являются основой механизмов восстановления после внезапной остановки компьютера (поломка, отключение питания). После перезапуска сервер находит незавершенные операции и либо доводит их до конца, либо наоборот, возвращает данные в исходное состояние. Они пунктуально учитываются при защитном копировании, и вообще во всех случаях обмена с внешним миром. В то же время, если запросы взаимно заклинятся, сойдутся насмерть в "смертельных объятиях", сервер обнаружит это и "разведет" их.
По мнению автора, сервер данных - едва ли не самая удивительная машина, созданная человеком. В большинстве современных продуктов такого рода содержится собственное ядро управления, осуществляющее многозадачную работу и оптимальный доступ к диску. От операционной системы, на которой они сидят, серверы данных получают разве что услуги связи. Ни поддержка файлов, ни планировщик задач им, в сущности, не нужны. И позвольте хотя бы упомянуть автоматическое разделение обязанностей по выполнению запроса между серверами в сети, автоматическую репликацию, защитное копирование, а также то, что существуют системы, непрерывно работающие годами. Под сервером заменяют отказавшие аппаратные модули, а он продолжает молотить, как ни в чем не бывало.
Культура данных
Первые коммерческие продукты доминирующего ныне реляционного типа создавались около 1980 года, а их теоретические основы были заложены в знаменитой статье Эдварда Кодда, представленной в 1969 году (но и тогда уже существовали и предки нынешних СУБД, и ясное представление о ценности и способах организации данных). Внедрение реляционных СУБД с языком запросов связано с массовым переходом на диалоговые методы использования компьютеров, когда на рабочих местах служащих начали устанавливать терминалы.
Эти процессы вяло, с отставанием, но шли и в СССР. Однако в буржуинских странах и компьютеры покупали, и программы разрабатывали на частные деньги, а в СССР средства на АСУ спускали сверху, из министерств. С приходом писюков советские АСУ просто рухнули, а народ забыл даже то немногое, что успел узнать о правильных способах ведения информационного хозяйства. Что ж, теперь придется усваивать эту науку по-настоящему, своим горбом.
В основе культуры данных, иногда перерастающей в их культ - осознание того, что информация, накопленная предприятием, является его важнейшим ресурсом. Наряду с кадрами, традициями, каналами сбыта, клиентами и технологическим наследием, деловая информация позволяет держаться на плаву даже старым, вконец обленившимся фирмам. Нередки случаи, когда информация, собранная между делом, оказывается дороже всей основной продукции и услуг. Иногда приходится принимать государственные меры для предотвращения распространения данных, находящихся в частных руках - например, сведений о жизни и деятельности граждан и фирм, которые накапливают банки, страховые компании, и подобные им институты.
Исходя из того, что информация представляет огромную ценность, как таковая, владельцам и создателям системы надо избежать самого опасного соблазна - пойти по пути удовлетворения сиюминутных нужд какими попало средствами. Если поддаться искушению, то на первый план выходит деятельность сотрудников, функции, процедуры, программы, одним словом, глаголы языка управленцев, в то время, как начинать надо с существительных. Глаголы изменчивы, а информационная модель, основанная на существительных, живет почти не изменяясь до тех пор, пока остается неизменным предметное содержание бизнеса.
За технологиями и программами для разработки информационных моделей стоит серьезная теория. Она учит, как сделать их полными, непротиворечивыми и неизбыточными, чтобы все нужные факты оказались учтены, но при этом каждый из них хранился ровно один раз. Специалисты - а они в России снова появляются - знают, как создать модель данных, рассчитанную на долгосрочную перспективу развития. Правду сказать, до недавнего времени к их советам можно было и не прислушиваться. Да, серьезные компании серьезно относились к своим данным, но случаи, когда из них извлекалась реальная выгода, шли скорее по разряду анекдотов, чем примеров для подражания.
Считалось (и правильно считалось), что если уж данные принадлежат системе, которая "заточена" под скоростное обслуживание операторов (это называется On Line Transaction Processing, или OLTP), то лучше не выполнять над ними запросы, поставляющие информацию для обоснования управленческих решений (Decision Support Sys-tems, или DSS), а уж тем более нельзя позволять копаться в них аналитикам, которые измываются над компьютером в надежде открыть полезную для бизнеса закономерность или доказать ее наличие.
Перелом в настроениях произошел в последние два-три года, в связи с распространением новых технических идей и на общем фоне повышенного интереса общества к информационной экономике. Сказалось, например, заселение Интернет, совершенствование серверов данных, распространение технологии репликации, изобретение так называемых складов данных (Data Warehouses), которые потянули за собой множество новых методов обработки.
Импульсы новаций всегда вызывали в экономике нечто вроде колебательного переходного процесса, но теперь частота и скорость затухания колебаний повысились на порядки. Между первыми экспедициями первопроходцев высоких технологий и массовым освоением новых возможностей теперь проходят не века, а годы. К тому же новшества резонируют, усиливают эффект друг друга, поскольку люди очень быстро научились осознавать взаимосвязи. Вполне обоснованный скептицизм буквально через полгода сменяется бурным энтузиазмом, и далее известная схема: шумиха, неразбериха, поиски виновных, наказание невиновных... наконец, вознаграждение непричастных. Кто окажется в их числе на этот раз?
Бремя проблем
Отдав долг уважения тем невидимым миру труженикам, благодаря которым летают самолеты, не тонут теплоходы и растут новостройки, не будем закрывать глаза на то, что стоящая за ними теория и технология очень стары. Серверы данных превратились в коммерческие продукты приемлемого качества примерно к 1984 году. Первый вызов, брошенный им персональными системами прошел незамеченным. Лишь некомпетентные люди могли поверить тогда в победу dBase и писишных сетей, хотя таких, как водится, набралось много больше, чем компетентных. Серверы данных без труда подмяли под себя PC и отбросили их на роль своих клиентов.
Второй вызов бросила следующая технологическая волна, поднятая объектно-ориентированным программированием. Она шла десятилетием позже и до сих пор определяет обстановку в лабораториях и на рынке, неся с собой совершенной другое, во многом диаметрально противоположное традиционному программированию мировоззрение, с позиций которого становится простым и возможным многое, раньше казавшееся невероятно сложным. Но для того, чтобы практические люди обратились к объектным идеям в поисках ответа, должны были существовать насущные вопросы, не получающие разрешения в рамках старых подходов.
Обратимся снова к нашему примеру и рассмотрим данные, связанные с отношением "Репортер". Для начала, что будем делать с полем "фото"? В "Компьютерре" не так много репортеров, чтобы напрягаться из-за подобных пустяков, но существуют ведь гигантские архивы документов с фотографиями!
Электронную фотографию, представляющую собой файл размером, скажем, от 10 килобайт до 3 мегабайт, ни в коем случае нельзя засовывать прямо в таблицу. Назовем лишь одну из причин. Эффективность традиционной реляционной технологии строится на том, что она имеет дело с короткими данными заранее известного размера. Даже решившись обрезать пустые концы строк (например, в именах людей) мы сильно снижаем скорость обновления, а с фотографиями таблица станет и вовсе неподъемной.
Разработчики СУБД ответили на этот вызов, введя объекты со смешным называнием blob. Это просто большие куски данных неопределенного размера с которыми СУБД не знает, что делать. Она записывает их в обычные файлы, а в таблицу подставляет ссылки на них. При доступе blob извлекается и передается пользователю целиком, как есть.
А что если над фотографией все-таки выполняются какие-то операции? Классический пример: пусть это база данных для розыска, в которой портреты даны без фона и примерно в одном масштабе. Нам надо выбрать из них снимки рыжебородых. Программная реализация проста - "прощупать" область подбородка и определить цвет - но если проверка делается на рабочей станции, то фотографии приходится гонять по сети туда-сюда. Именно это и губит примитивные информационные системы, написанные на dBase и перенесенные в сеть с файловым сервером (тут я вновь отсылаю вас к "Четырем колонкам" на странице 3)!
Если же операцию по проверке цвета бороды выполнять прямо на сервере данных, то как встроить ее в язык запросов и приспособить к ней остальные механизмы стандартной покупной СУБД? Ну, хорошо, мы можем выкрутиться, заранее приложив к каждой фотографии составленный вручную словесный портрет и проводя поиск по нему, но есть случаи похуже.
Возьмем, к примеру, поле "текст" в таблице "Публикация". Это типичный blob, то есть, сложный агрегат данных изменяющегося в широких пределах размера, однако над ним можно производить очень много полезных операций. Например, выбрав публикации штатных репортеров в предыдущем примере, мы могли бы подсчитать и занести в таблицу размер текста для начисления гонорара. Не всегда это делается прямо в лоб - скажем, если тексты хранятся в формате Word Proc-essor'а то к ним надо еще применить соответствующий фильтр.
Получив очередное мнительно-завистливое письмо читателя, редактор мог бы задаться вопросом - а кто из репортеров и сколько раз упоминал фирму "Хвост и чешуя" или ее достопочтенную продукцию (заодно можно и выдержки из текстов поднять), и вообще, кто и как пересекается в своих материалах с фирмами? Или вот вдруг кому придет в голову подыскивать автора по определенным стилевым признакам - длине предложений, словарному запасу и т.п.
Чтобы не "посадить" сеть, все такие операции хотелось бы проводить на сервере, передавая клиенту только "сухой остаток". Кстати, для того, чтобы эффективно выполнять поиск, тексты надо предварительно вывернуть наизнанку, приведя к так называемому полнотекстовому индексу, а это отдельная и довольно сложная кухня. Наконец, сюда же цепляется хорошо известная нам проблематика поддержки национальных языков, которая и разработчику СУБД не безразлична. Если он хочет покорять своим продуктом новые рынки, то должен предусмотреть возможность приспосабливать его к местным колоритам.
Еще один хорошо известный пример. В таблице "Репортер" мы предусмотрели возможность ввести географические координаты места, где он живет. Легко представить себе такие, скажем, запросы: найди на карте все объекты заданного типа в заданном радиусе относительно заданной точки. Карта, естественно, электронная, то есть хранится в той же базе данных, а объектов на ней тьма-тмущая, поскольку в данном случае нас не стесняют условия видимости их на бумаге. Проблема в том, что для быстрого поиска объектов по их координатам совершенно не годятся обычные методы индексирования данных. С точками, отрезками, окружностями и другими картографическими объектами надо обращаться особым образом. Между тем электронная картография распространяется все шире, а в мире автоматизированного проектирования все больше полагаются на открытые решения, во многом аналогичные трехмерной картографии.
В базе данных "Компьютерры", например, совсем неплохо было бы иметь данные о распространении ее по стране и сопоставлять их с данными о населении, промышленности и прочих характеристиках регионов. Впрочем, картография уже признана универсальной прикладной областью, а возможность работы с пространственной информацией начали включать в стандартные поставки СУБД. Да и полезность ее в примере с репортерами, в условиях большого города, сомнительна.
Попробуем набросать практическое решение задачи расчета времени доступа репортеров к тем или иным объектам. Пусть, например, у нас есть общее для всех ядро, вычисляющее время проезда по сети метро, и собственные соображения репортера о том, как и насколько быстро он добирается до ближайшей станции. Затем придется учесть множество исключений и тонкостей - скажем, особенности транспортировки на коротких расстояниях или расписание ближних электричек.
В итоге в поле "доступ" таблицы "Репортеры" нам придется записать ни что иное, как программу расчета на обычном языке программирования. И даже не факт, что нам захочется потом сводить эти программы в одну универсальную функцию, которой можно было бы давать набор параметров.
Вводя в СУБД новые типы данных, надо вводить в язык запросов и новые операции над ними, или способы приведения их к существующим типам. Например, имея преобразование, переводящее почтовые адреса в точки на карте, мы запросто можем применять к ним векторную арифметику - например, вычитать и получать расстояния! А рассмотренный выше пример с публикациями следовало бы закончить тем, что редактор назначает ставку гонорара за каждую из них, СУБД умножает ее на объем и подсчитывает итоги по подсчитывает по репортерам и по всему списку. Подсчет итогов это так называемая агрегатная операция. Набор агрегатных операций для каждого типа данных тоже свой.
Например, если бы мы решали задачу наподобие сбора народного ополчения, то могли бы определить над полем "доступ" отношения "Ополченцы" агрегатную операцию наподобие усреднения, которая возвращала бы функцию, характеризующую матожидание числа ополченцев, прибывших в точку сбора, в зависимости от времени, прошедшего с момента оповещения, и еще в зависимости от времени суток, дня недели и месяца, времени года и других привходящих обстоятельств. Вы как, не запутались еще? А я сам? Кажется, нет.
В таком случае позвольте сделать резюме. В рамках реляционного подхода полагают, что все перечисленные, и другие нетрадиционные задачи на самом деле можно свести к таблицам и к действиям с ними. Более того, правоверные реляционисты ассоциируют Бога с некоей невообразимой таблицей, объединяющей в себе всю информацию о Вселенной. Это верно - по крайней мере, в первой части - но для решения огромного количества практически важных проблем требуется совершенно неподъемная для любой реальной вычислительной системы степень детализации таблиц.
Попытки создать объектно-ориентированную базу данных, в которой роль атомов играли бы не таблицы, а объекты, пока не привели к созданию продукта, который бы сравнялся по эффективности с реляционными системами на удобном для них классе задач - а эти задачи, как ни крути, пока для рынка важнее всего. Новые продукты, так называемые универсальные серверы, первый из которых показала Informix, это гибриды, в той или иной мере объединяющие два подхода.
Мы можем вообще не упоминать объектно-ориентированные корни универсального сервера, тем более, что само это словосочетание действует на многих раздражающе. Достаточно понимания того, что разработчики ищут способ переносить в базы данных и подчинять существующей технологии управления новые, сложные виды информации, со специфическими для них операциями и средствами доступа.
Серверы и сети
Во всех рассмотренных выше трудных случаях выход можно найти в рамках клиент-серверного подхода. Картографические данные, тексты, изображения можно интегрировать в прикладные программы на уровне клиентов, а в сети поставить специализированный сервер, приобретенный отдельно у специализированного поставщика. Есть, однако, один общий и очень мощный фактор, изменивший ситуацию. Это взрывной рост применения Интернет и технологии WWW.
В самом деле, еще года три назад гиганты бизнеса снисходительно взирали на объектно-ориентированную поросль под ногами, а начальники высказывались в том смысле, что им до пенсии реляционной технологии хватит. Вот, однако, две цифры: количество зарегистрированных сайтов Web, как только что сообщили наши обозреватели новостей, уже превысило 400 тысяч, причем за год их число выросло в пять раз, а лицензий на серверы Informix по результатам 1995 года было продано около 500 тысяч. А ведь до недавнего времени хранилищем данных Web служила файловая система Unix, и никаких других решений не существовало.
Первой начала разрабатывать новые задачи Oracle Corp. Такое впечатление, что поворот, начавшийся с объявления о разработке малтимидийного сервера, стал некой вехой в ее жизни, ознаменовав в частности, завершение перехода к форме публичной компании управляемой профессиональными менеджерами. Основатель фирмы Лоренс Элисон не уволился, как это часто бывает, а начал осваивать роль визионера.
Его идеи относительно сетей часто недооцениваются или недопонимаются. Обычно все сводят к тому, что, мол, серьезная софтверная фирма занялась разработкой каких-то ублюдочных сетевых компьютеров. Между тем, сетевые инициативы Oracle охватывают весьма широкий круг технологий и, как показали недавние события, фирма отнюдь не видит себя в роли производителя клиентской аппаратуры.
Программные серверы и сети находятся, вообще говоря, в антагонистических отношениях. Чем лучше работают сети, тем меньше продается серверных лицензий. Видение Элисона, насколько можно судить, подсказывало ухватиться за оба конца и перестроить бизнес так, чтобы доходы компании росли с ростом Сети.
Когда в своем недавнем пресс-релизе, составленном в необычайно резких выражениях, вице-президент Oracle по серверам отвечал на выдвинутые Informix обвинения в перекупке специалистов, он, в частности, указывал на заслуги своей фирмы в создании сетевых и малтимидийных решений, и на отставание Informix в этих вопросах. Верно: еще два года назад Informix относилась к затеям Элисона весьма скептически. Однако, проснувшись, она одним усилием выскочила в дамки.
Несомненно, Oracle очень обижена тем, как повернулось дело. Не могу избавиться от ощущения, что ее сотрудником маневр Informix кажется уж слишком ловким трюком, из тех, что демонстрируют преимущества воровства перед честным трудом. Они словно говорят - ну, раз Informix решила проблему в которую мы вкладываем столько труда и денег, покупкой Illustra, то мы возьмем и перекупим людей у In-formix. Словесная битва разворачивается именно в этом измерении, в плоскости интерпретации моральных и правовых норм добросовестной конкуренции. Но до чего же рутинным занятием становится компьютерная промышленность, если остроумных технический ход, архитектурная идея уже воспринимаются, как нечестная игра!
Кто сильнее?
Отличившаяся на первом витке гонки фирма Informix Software обычно находится в тени Oracle Corp., которую принято величать королевой рынка реляционных СУБД, работающих на платформах Unix. Это открытый рынок на котором идет горизонтальная конкуренция решений, хотя в действительности все игроки ориентируются на определенные ниши или системы ниш.
Не только аналитики, но и сама Informix Software называет себя номером вторым. Сообщают, однако, что на открытом рынке ею продано более 30% установленных серверов, хотя в силу количественных (ценовых) и структурных причин накопленная доля рынка в денежном выражении составляет лишь 10%. По тем же данным, на долю Ora-cle приходится лишь 10% лицензий, но 40% стоимости. Воспринимая эти цифры прошу иметь в виду, что СУБД представляет собою многопользовательский продукт, и большее число лицензий не обязательно означает большую сферу влияния.
Informix любит подчеркивать, что хочет наилучшим образом делать главное - саму СУБД - и опираться на партнеров в части вспомогательных продуктов, полуфабрикатов и услуг. Считают, что объем рынка товаров и услуг, привязанных к СУБД, превышает стоимость последних в десятки раз. К сожалению, у меня нет данных о совокупном объеме сектора, возглавляемого Informix - возможно, их нет вообще ни у кого. Остается предполагать, что доля рынка, генерируемого этой СУБД, как-то соответствует ее доле среди других серверов, а лояльность партнеров обеспечивает дополнительный запас устойчивости компании In-formix Software. Кстати, у последней особенно сильные позиции на рынках Европы, и в частности - Восточной Европы.
Oracle Corp. является крупнейшим игроком на открытом рынке. Ее продукты дороже, и, по-видимому, она более тяготеет к тому, чтобы зарабатывать все деньги самой, но и тут не обходится без многочисленных и преданных партнеров, так что совокупный объем рынка, завязанного на продукты Oracle, во много раз больше.
По оценкам, оборот Informix за прошлый год составил около 1 миллиарда долларов, а прирост составляет около 30%. У Oracle за прошлый год более четырех миллиардов, но это все общие цифры по корпорациям. Что касается собственно систем управления базами данных, то вот только что распространенные предварительные цифры IDC. В стоимостном выражении продажи Oracle составили 1,67 миллиардов, рост 11.2%. Informix продала на 0,71 миллиарда и прибавила целых 38,6%. Sybase продала на 0,47 миллиарда и потеряла 16,7%. Данные по разделу рынка таковы: Informix выиграла 4%, Oracle потеряла 1%, а главная конкурентка Infor-mix, фирма Sybase, сдала 4%. Общая доля лидирующих реляционных продуктов потихоньку падает, а значит, новые технологии прибавляют.
На таком рынке как этот, отобрать у конкурента его пользователей - почти немыслимое дело. Передел происходит за счет борьбы за новые ниши, и проблемой для Oracle является как раз то, что Informix завоевывает новых партнеров и распространяется на новые прикладные области.
Вселенский сервер
Универсальный сервер Informix возник в результате молниеносного объединения разработанного ею и широко применяемого на практике реляционного ядра, называемого DSA (Dynamic Scalable Architec-ture, то есть, динамическая масштабируемая архитектура) и СУБД Illustra фирмы Illustra Infor-mation Technologies, которую In-formix купила год назад. Самая интересная часть - так называемые DataBlades - взята из Illustra.
Фирма Illustra была признанным лидером в своей возрастной группе и весовой категории, причем исключительно быстро набирала обороты. Создавшие ее люди пришли из Калифорнийского университета в Беркли, а идеи - из университетского проекта Post-gres. Руководитель этой команды профессор Майкл Стоунбрейкер (Michael Stonebraker), ныне ставший замом по технологиях (CTO) в Informix, возглавил процесс слияния двух серверов, состоящих из полутора и одного миллиона строк кода, в один продукт.
DataBlades, как видно из рисунка, это "попросту" программные модули, присоединяемые к прямо к ядру универсального сервера СУБД. Несколько десятков их поставляется самой Informix, но еще больше создается независимыми поставщиками, и компания изо всех сил старается развить этот рынок. Стандартный набор DataBlades, отчасти унаследованных от Illustra, весьма впечатляет. В него входит, например, публикатор для Web, который автоматически генерирует описания страниц на языке HTML по шаблонам и данным, хранимым в СУБД. Имеется модуль поддержки двумерной геометрии (той же картографии), и еще одного трудного для традиционных СУБД объекта - временнЫх рядов.
В списке стандартных DataBlades встречаются знакомые называния фирм, которые уже интегрировали в универсальный сервер свои технологии работы с данными. Среди них уникальные полнотекстовые решения Verity и Exalibur, поисковая машина PLS, модули для работы с изображениями Exalibur и для поиска их Virage, средства работы с геодезической информацией Geodetic. Выпущены на рынок и разрабатываются буквально сотни других. Дело идет к тому, что конкурентам придется признать наличие на рынке фактического стандарта.
Из рисунка видно, какие компоненты сервера СУБД расширяются новым программным кодом при подключении DataBlade. Главным образом, это подсистема разбора запросов на языке SQL (Informix, как и все остальные, опирается на проект стандарта SQL3) и оптимизатор. Внутри себя DataBlade должен нести специфические для него методы доступа к данным и определения операций над ними.
Программы DataBlade могут обращаться к основной СУБД и хранить в ней обычную реляционную информацию. Кроме того, они могут перекрестно использовать друг друга, и в особенности стандартные DataBlades, которые в системе должны быть всегда. Так, все DataBlades других фирм могут опираться на уже имеющиеся полнотекстовые средства. Наконец, DataBlade может нести в себе программы для клиента, которые переходят на рабочую станцию, присоединяются к выполняемой на ней прикладной программе и встраивают в нее новые средства интерфейса пользователя.
DataBlades безупречно эффективны, поскольку встраиваются прямо в ядро наряду с "родными" компонентами системы. В этом же состоит наиболее сильный аргумент против них. Поскольку между DataBlades и СУБД нет аппаратной защиты, наподобие той, которая изолируют друг от друга процессы в многозадачной системе, DataBlade, в принципе, может разрушить остальные программы. Не нужно даже злого умысла, достаточно ошибки. Страшнее всего, что при этом может пострадать база данных.
Главный идеолог проекта Майкл Стоунбрейкер настаивает на том, что интерфейс DataBlades очень хорошо продуман, и они совершенно безопасны как сами по себе, так и в сочетаниях. Впрочем, Informix создала программу поддержки партнеров и ведет сертификацию их продуктов. Многим все это приводит на ум Novell, которая за много лет борьбы с применением тех же приемов так и не смогла сделать Netware безопасным носителем прикладных серверов из-за органических дефектов заложенной в нее архитектуры многозадачности.
Oracle вводила в свою основную СУБД поддержку так называемых картриджей данных, Data Car-tridges, которые первоначально были применены в ее WebServer. Это независимые программы, которые выполняются в отдельных процессах или на отдельных компьютерах, а сообщаются между собой в соответствие с известной архитектурой CORBA. Будучи весьма серьезным и ответственным промышленным решением, Data Cartridges "в разы" менее эффективны, чем DataBlades. Представляя свой универсальный сервер, Informix даже заготовила и показала публике специальный эксперимент на эту тему.
Не будем, однако, забывать, что пользователи склонны мириться с ненадежностью программ. Одно дело, если разрушаются данные на диске, и совсем другое, если "падает" время от времени оболочка. Эффективностью - по крайней мере в таких масштабах - ради этого пожертвуют немногие. Для Oracle картриджи данных были временным решением. Она уже давно объявила, что занимается радикальной переделкой своей системы на объектно-ориентированный лад. Злопыхатели утверждают, что ядра Oracle рука программиста не касалась уже десять или двенадцать лет. Тем временем Informix уже начала создавать новые рынки и утверждаться на них в качестве локомотива прогресса.
Готовя эту статью, я побеседовал с Алексеем Тимониным из представительства фирмы Sy-base, которая, как вы могли заметить, закончила прошлый год не слишком удачно. Оказывается, Sybase, на продуктах которой, по слухам, работает чуть ли не вся Wall Street, тоже готовится ввести в свой сервер возможности работы с данными новых типов. Преимущество их архитектуры в том, что между собственно сервером СУБД и клиентами всегда стояло промежуточное, программируемое потребителем звено - так называемый Open Server - выполняющее роли операционной системы с "легкой" многозадачностью, сервера приложений, монитора транзакций, языкового препроцессора и тому подобное. Теперь Sybase намерена воспользоваться этим обстоятельством и дать возможность подключать через Open Server специализированные серверы данных.
Если все так и будет, то решение Sybase окажется еще медленнее. Его можно подтянуть до уровня картриджей данных Oracle, а вот как таким путем можно было бы сделать нечто подобное по эффективности DataBlades, я не могу себе представить. Впрочем, продукт Sybase ожидается лишь к концу этого года.
Важным фактором, который, тем не менее, тоже не поддается количественной оценке, являются намерения IBM. Не так давно принадлежащая ей первая коммерческая реляционная СУБД DB2 сошла с мэйнфреймов на RS/6000, а затем первой из программных продуктов IBM перебралась на компьютеры SUN и HP. Одновременно с запуском универсального сервера Informix, IBM раскрыла свои карты в части новой версии DB2, которая скоро должна войти в стадию бета-тестирования. В ней тоже появится механизм расширения, через который в виде отдельных серверов, но на уровне языка запросов будут подключаться подсистемы полнотекстовых баз данных, изображений и другой малтимидийной информации. К счастью для остальных, продукт, который IBM называет Universal Database пока не готов, да и современная DB2 не занимает сколько-нибудь значительной доли открытого рынка. К тому же, IBM пока вроде бы не собирается активно привлекать на свою платформу сторонних поставщиков.
Интересно, что название Univer-sal Server компания Informix увела из-под носа у Oracle, которая первой начала употреблять его для обозначения своего перспективного продукта. Так Oracle, наконец, пострадала через свою порочную привычку продавать, что называется, va-porware. Попытка судиться ни к чему ни привела - словосочетание не было, да и едва ли могла быть зарегистрировано, как торговая марка. А злодейка Informix в своей рекламе подчеркивает у слова universal иной и очень сильный смысл, который на русский язык можно перевести как "вселенский". Помните реляционного Бога?
