|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #01/97
|
|
Уже сейчас мы можем с уверенностью сказать, что сегодняшний день в развитии систем управления базами данных является переломным этапом, который определит стратегию развития этой отрасли на много лет вперед. Давайте оглянемся немного назад и посмотрим, какие же причины привели нас к этому перелому.
Еще совсем недавно большинство систем управления базами данных занимались настоящими "гонками транзакций", т. е. старались достичь наибольшей скорости обработки наибольшего числа одновременных транзакций. Последние десять лет поставщики СУБД конкурировали в основном в достижении максимального числа транзакций и улучшении соотношения цена/производительность простых коротких транзакций и запросов к простым данным. Эта "арена состязаний" определялась тестами производительности (benchmarks), разработанными Tran-saction Processing Performance Council (TPC). В жертву скорости приносилось разнообразие типов данных и сложность транзакций. Транзакции, которые выполнялись все быстрее и быстрее, работали с самыми простыми типами данных, набор которых был чрезвычайно ограничен - числа, даты, текстовые строки. Такая стратегия приносила успех, так как компьютерное оборудование тогда было как раз достаточно мощным для поддержки систем, которые могли с достаточной эффективностью управлять такими данными. Существующие системы охватывали только от 5 до 20% всего многообразия данных, с которыми работали компании и организации. Несмотря на это, реляционные СУБД и на сегодняшний день занимают самую большую долю рынка систем управления данными.
Однако развитие компьютерной индустрии, в том числе компьютерного оборудования, повышение производительности компьютеров, особенно мощности процессоров, емкости памяти, дисков, пропускной способности сети, широкое использование параллельных архитектур позволили перейти к новому этапу в индустрии программного обеспечения. Появились возможности, более того, необходимость обрабатывать все более сложные данные. Повсеместное распространение компьютерной индустрии, проникновение электронной обработки во все сферы человеческой деятельности предъявили невиданные доселе требования как к обрабатываемым данным, так и к методам их обработки.
Новые сферы деятельности требовали новых типов данных простые числа и символьные строки явно недостаточны для новых мультимедийных систем. Новых типов данных требовали и "старые" области. Так, в финансовых приложениях растущие объемы данных и сложность их обработки потребовали новых методов хранения и использования информации.
Появилась также совершенно новая область в компьютерной индустрии - World Wide Web, которая потребовала появления совершенно новых подходов к обработке данных, а также ужесточила "старые" требования к производительности и надежности работающих в WWW систем.
Систематизируем все присутствующие на рынке средства управления данными при помощи следующей схемы на рис. 1 (схема взята из книги Michael Stonebraker и Dorothy Moore "Object-Relational DBMSs: The Next Great Wave", Morgan Kaufmann Publishers, 1996).
Рисунок 1.
В качестве самых простых систем управления данными мы можем рассматривать файловую систему. Примером приложения, использующего такую "СУБД", может служить текстовый редактор. Текстовый редактор является приложением, в котором нет запросов. Единственный запрос, который делает текстовый редактор, - это "получить файл", единственное обновление - "сохранить файл". Однако сегодня очевидна тенденция к миграции этих приложений в другие области приведенной матрицы, так как модель данных даже для таких систем становится более сложной. Так, например, документы становятся структурированными объектами, включающими в себя отчеты, графики и таблицы.
Этот набор продуктов прекрасно иллюстрируют реляционные базы данных, использующие стандартный SQL92. Их можно назвать также системами обработки бизнес-данных. Стандартные данные, которыми оперирует SQL92, - числа, даты и символьные строки - можно классифицировать как простые.
Рынок обработки бизнес-данных очень велик, на нем фигурируют системы управления базами данных, которые, различаясь во многих деталях реализации, в целом предоставляют похожие возможности. Такие системы баз данных должны обеспечивать определенный спектр возможностей, таких как высокая производительность выполнения транзакций и их сериализацию, обеспечение безопасности данных, поддержку многопроцессорных платформ и гетерогенных сред.
Рынок реляционных СУБД составляет примерно 8 миллиардов долларов в год, при годовом росте более чем на 25%.
Однако в свете сегодняшних требований реляционные СУБД уже не могут оставаться чисто реляционными. Требования рынка заставляют поставщиков изыскивать новые возможности для работы с данными сложной структуры.
Особняком от реляционных систем управления данными стоят объектно-ориентированные СУБД (ООСУБД). Эти системы специально создавались для работы со сложными объектами данных. Они не старались проецировать сложные объекты на простые реляционные структуры, а хранили объекты в той форме, в которой они затем обрабатывались. Тем самым достигалось преимущество в обработке сложных объектов, но при этом в жертву приносилась сложность запросов. Для объектов сложной структуры невозможно было разработать такой мощный и теоретически обоснованный язык запросов, как SQL для реляционных данных. Для работы со сложными данными использовались объектные языки программирования высокого уровня, которые позволяли строить и поддерживать объекты сложной структуры, но не позволяли осуществлять к этим данным сложные запросы. Доступ к объектам производится посредством уникальных идентификаторов или ссылок. Запросы, основанные на содержимом или внутренней структуре объектов, требуют большого дополнительного кодирования на языке программирования высокого уровня.
В целом поставщики объектных СУБД занимают рынок порядка 80 миллионов долларов в год, при годовом росте на 50%.
Еще одним недостатком подобных систем являются относительные слабые возможности предоставления одновременного доступа большому количеству пользователей. Многие компании, работающие с данными системами, сообщают, что ООСУБД начинают испытывать проблемы, когда число одновременно работающих пользователей превышает 50-100.
Необходимость сложной интеллектуальной обработки данных заставляет изыскивать новые пути работы с данными, иные, чем предоставляются ООСУБД.
В 1993 году на рынке появилась новая СУБД Illustra - объектно-реляционная СУБД, которая позиционировала себя в пустующем верхнем правом квадранте нашей матрицы. С одной стороны, эта система поддерживает язык запросов SQL, отвечая стандарту SQL92. В то же время посредством расширений стандарта SQL обеспечивается создание, хранение и получение объектов произвольно сложной структуры. Тем самым, с одной стороны, решается проблема объектно-ориентированных СУБД - отсутствие языка запросов. С другой стороны, данные уже не нужно "насильно" загонять в рамки плоских таблиц, но можно создавать сложные взаимосвязи объектов данных, используя при этом SQL.
Illustra также ввела принципиально новое понятие - DataBlade - расширений типов данных. Технология DataBlades позволяет не только строить объекты сложной структуры из простых "кирпичиков" - простейших типов данных (поддержка составных типов, множеств, массивов, ссылок), но и "заглянуть внутрь" объекта - структурировать большой объект, разложив его на составляющие, и передать серверу СУБД знания о том, как интеллектуально работать с объектами такой структуры. Это решило проблему обработки больших объектов (BLOBs) в реляционных СУБД, когда сервер ничего "не знал" о структуре такого объекта и вся обработка перекладывалась на плечи разработчиков приложений.
Однако у молодой компании Illustra были свои проблемы. "Монстры", работающие на рынке СУБД, не один год решали проблемы масштабируемости своих серверов, поддержки многопроцессорных архитектур, одновременной работы большого числа пользователей. Обладая уникальной технологией, которая позволяла добиться огромной скорости при работе со сложными данными, Illustra столкнулась с несколько иными проблемами. Решения Illustra начали выбирать организации и компании (NASA, Sony, Sun Microsystems, Warner Brothers и т. д.), приложения которых могли оказаться слишком "тяжелыми". Требовалось решить проблемы масштабируемости для работы с кластерными и массивно-параллельными архитектурами, создать масштабную систему технической поддержки, консалтинга и обучения, требовался абсолютно иной уровень маркетинга и организационных структур. Потребовалось бы много времени на то, чтобы успешно соревноваться в этом плане с конкурентами, уже давно работающими с такими крупными заказчиками.
Именно поэтому объединение передовых идей и технологии Illustra и мощной динамической масштабируемой архитектуры Informix явилось таким значимым событием в мире систем управления данными. Именно компания Informix, переписав в начале 90-х годов ядро своего сервера и предусмотрев в нем поддержку объектных расширений, создала тем самым прекрасную базу для включения в свои серверы новой технологии, предоставляемой Illustra.
Итак, сейчас нам нужна система, которая гармонично соединяла бы в себе лучшие черты реляционных СУБД, обеспечивая мощный непроцедурный язык запросов к данным, и объектно-ориентированных СУБД, позволяя работать с данными сложной структуры. При этом она должна органично поддерживать многопроцессорную архитектуру, быть хорошо масштабируемой и позволять одновременную работу пользователей в корпоративных масштабах.
Сегодня мы можем сказать, что такая система есть и это INFORMIX-Universal Server (IUS).
Давайте подробнее рассмотрим архитектуру INFORMIX-Universal Server, которая позволяет нам обеспечить такие уникальные возможности (рис. 2).
Рисунок 2.
В основе всего лежит динамическая масштабируемая архитектура Informix, которая идеальна для параллельной обработки данных. Она позволяет сбалансировать рабочую загрузку между существующими ресурсами, поддерживая реальное параллельное выполнение многих операций, таких как сканирование, объединение, построение индексов, загрузка данных и пр. Эта архитектура хорошо масштабируется, т. е. добавление дополнительного оборудования эффективно влияет на производительность сервера баз данных. Эта архитектура прекрасно работает как для коротких OLTP-транзакций, так и для систем поддержки принятия решений. Мы не будем сейчас обсуждать преимущества DSA, этому была посвящена отдельная статья.
Универсальность INFORMIX-Universal Server заключается в органичном сочетании и реляционных, и объектных возможностей в одной СУБД.
К реляционным возможностям сервера мы можем отнести:
В рамках данной статьи мы не будем подробно обсуждать эти возможности, отметим только что именно они определяют основные достоинства реляционных СУБД.
К объектным характеристикам INFORMIX Universal Server мы можем отнести:
Рассмотрим подробнее объектные возможности INFORMIX Universal Server, которые делают его поистине универсальным, позволяя работать с любым типом данных:
(1) Появление новых возможностей работы с данными в INFORMIX Universal Server основано на поддержке концепции расширяемых типов (extensible types).
В IUS стало возможным расширение "плоских" атомарных типов данных либо при помощи конструкторов, которые позволяют строить новые типы из уже существующих (составные типы), либо при помощи определяемых пользователем типов (иногда в данном случае предпочитают использовать термин "абстрактные типы данных" чтобы отличать их от составных типов, которые в общем-то тоже определяются пользователем).
При использовании составных типов конструкторы позволяют создавать типы двух видов.
Они являются аналогами структур С или С++. Могут быть именованными или неименованными.
Пример создания неименованного типа-записи:
create table employee (
name VARCHAR(30),
address ROW (street CHAR(20),
city CHAR(20),
state CHAR(2),
zip CHAR(9)),
salary INTEGER
);
Пример использования именованного типа-записи:
CREATE ROW TYPE address_t(street CHAR(20),
city CHAR(20),
state CHAR(2),
zip char(9));
CREATE ROW TYPE employee_t(name CHAR(30),
address address_t,
salary INTEGER);
CREATE TABLE employee OF TYPE employee_t;
В примере приведено построение составного типа из простых. Однако составной тип данных может также включать в себя любой тип - простой, составной, определенный пользователем и т. д.
Эти типы могут строится с помощью соответствующих конструкторов: set (множество), list (упорядоченный список) и multiset (множество, допускающее повторяющиеся элементы).
Элементы в наборе могут быть любого типа данных (в том числе и составного). Пример создания типа-множества:
CREATE TABLE recordings
(label VARCHAR(50),
album_name VARCHAR(50),
songs MULTISET(ROW
(artist_name VARCHAR(50),
song_name VARCHAR(50),
seconds INTEGER)
NOT NULL));
Манипулировать элементами данного типа мы можем при помощи предложений SQL.
Ввод первого элемента в таблицу:
INSERT INTO recordings VALUES ('Capitol', 'Sgt.Peppers Lonely',
MULTISET{ROW("The Beatles','Fixing a hole',153)});
Ввод второго элемента в уже существующую запись:
INSERT INTO THE (SELECT songs FROM recordings r WHERE
r.label='Capitol')
AS X VALUES MULTISET{ROW("The Beatles','Lovely Rita',163)});
Как видно из примера, для доступа к отдельным элементам составного типа используется нотация с точкой.
(2) IUS поддерживает классический набор объектных возможностей, которые включают в себя наследование, полиморфизм и инкапсуляцию.
Наследование возможно для широкого спектра объектов баз данных: типов, таблиц, функций и др.
Предположим, вы построили тип данных person_t:
create type person_t(name varchar(30));
Теперь мы можем создать два новых типа employee_t и student_t, которые будут наследниками типа person_t:
create type employee_t (salary int,
startdate date) under person_t;
create type student_t (level int) under person_t;
Приведенные предложения создают подтипы employee_t и student_t для супертипа person_t. Подтипы наследуют все поля данных своего супертипа и добавляют новые. У одного супертипа может быть несколько подтипов.
Параллельно наследованию типов производится наследование таблиц. Вы можете получать данные как отдельно из каждой таблицы иерархии, так и из всей иерархии таблиц.
Наследуется не только структура таблицы. Наследуются также конструкции целостности и триггеры. Все индексы, определенные для полей супертаблицы автоматически распространяются на иерархию подтаблиц. Таким образом, мы видим, что наследуется не только структура таблиц, но и их свойства и поведение. Более того, одним из наиболее мощных возможностей наследования является наследование процедур и функций, связанных с типами.
С наследованием функций вы получаете возможность использовать возможности переопределения функций и позднего связывания.
Необходимо сказать несколько слов о возможности переопределения функций, которая позволяет нам говорить о полиморфизме. Так конкретная функция, которая должна выполняться в ответ на вызов, определяется по ее сигнатуре, т. е. по имени и набору параметров. Например, вызвав Display для текста, вы можете получить распечатку исходного текста, для изображения - вывод его параметров, для видео - просмотр видеофильма. Это позволяет упростить интерфейс обращения к данным и сделать процесс разработки более простым и интуитивно ясным.
Итак, до сих пор мы говорили о типах данных, которые представляют собой композицию более простых типов. Однако для того, чтобы охватить все разнообразие данных, таких типов становится недостаточно.
Существует набор ключевых возможностей, встроенных в ядро традиционных СУБД, для каждого стандартного типа данных. Эти возможности включают в себя:
Именно они и определяют эффективность и производительность доступа к стандартным типам сервера, управляющего данными.
Когда вы управляете типами данных, которые не относятся к простым предопределенным типам, реляционные СУБД расценивают сложные типы как типы другого класса, хранимые в виде больших двоичных объектов - блобов (BLOBs). Так как блобы являются не интерпретируемыми наборами, СУБД не знает, как выполнять над ними запросы, основанные на содержимом. Поэтому над такими типами сервер не может выполнять операции сравнения, значит, не может быть построен оптимальный план выполнения запроса, следовательно, не может быть высокой производительности сохранения и получения данных. Фактически СУБД не могут предоставить для блобов никаких возможностей сервера, что делает СУБД не способными управлять более сложными данными, чем стандартные. Вся работа ложится на разработчиков конкретных приложений - работа по трактовке содержимого, формата и метода доступа, требуемых для каждого типа данных, и эта работа повторяется для каждого приложения. Более того, так как СУБД не может трактовать содержимое блобов, они должны передаваться по сети для обработки клиенту, что предъявляет жесткие требования к пропускной способности сети.
(3) В IUS вводится новое понятие определяемого пользователем или абстрактного типа данных. В IUS для данной конструкции используеется зарезервированное слово "opaque". Такой тип полностью "непрозрачен" - инкапсулирован, доступ к этому типу осуществляется посредством определенных для него функций. Вы можете создать свой собственный абстрактный тип, определив для него параметры хранения, функции ввода-вывода, а также набор дополнительных функций для манипуляции объектами этого типа. Тем самым вы передаете серверу баз данных знания о том, что представляют собой объекты нового типа, как их хранить и возвращать, как сравнивать друг с другом. Учитывая ограниченный размер статьи, авторы не стали приводить развернутый пример создания определяемого пользователем типа данных. Читатели, которые заинтересованы в более подробном изучении данного вопроса, могут всегда связаться с авторами.
Вы добавляете сведения и опыт в саму СУБД, расширяя систему ключевыми функциональными возможностями, требуемыми для поддержки специфического типа данных, а значит даете серверу баз данных возможность управлять новым типом так же эффективно, как и любым стандартным типом.
Когда говорится, что вы можете определить собственные методы доступа к объектам данных абстрактного типа, то имеются в виду не только первичные методы доступа, которые определяют манипулирование данными, хранящимися в таблице. В IUS мы можем говорить о возможности определения так называемых вторичных методов доступа, которые используются для построения и доступа к индексам для нового типа. Ведь в некоторых случаях (а для новых многообразных типов - в подавляющем большинстве случаев) стандартное индексирование B-tree не эффективно для объектов абстрактного типа. Функции вторичного метода доступа оптимизируют доступ к типу и делают максимально производительными запросы к его содержимому.
Если же B-tree является удовлетворительным методом доступа для объектов нашего типа, то нам достаточно просто определить функции сравнения объектов типа (Equal, LessThan и др.), чтобы к ним мог применяться стандартный метод индексирования.
В IUS поддерживаются функциональные индексы, которые позволяют сохранять в индексном дереве в качестве ключевого значения не значения полей, по которым производится индексирование, а результат выполнения над ними заданной функции. Функциональные индексы обеспечивают лучшую производительность в тех случаях, когда в запросах используется не само значение индексного поля, а некоторая функция над ним.
Обсуждая абстрактные типы данных, мы вплотную подошли к идее DataBlades.
Рисунок 3.
Технология DataBlade основана на возможности определения абстрактных типов данных. DataBlades представляют собой абсолютно новое средство для поддержки сложных данных. DataBlade - это встраиваемый модуль, который добавляет сведения и опыт в саму СУБД, расширяя систему ключевыми функциональными возможностями, требуемыми для поддержки специфического типа данных.
Модули DataBlades позволяют приспосабливать сервер к обработке информации, определяемой требованиями бизнеса. Если ваша компания работает с изображениями или видеоинформацией - просто добавьте соответствующий модуль DataBlade. Вам необходим финансовый инструментарий, который анализирует серии данных, получаемые через определенные промежутки времени, - использует Time-Series DataBlade. Если вам требуется интегрировать информацию о пространственной модели в систему автоматического проектирования - подключите модуль Spatial DataBlade.
Используя несколько DataBlades, вы можете хранить все многообразие данных, применяемых в вашем бизнесе в едином репозитории. Это обеспечит более быструю обработку запросов и предоставит широкие возможности для комплексного анализа данных.
В сегодняшнем быстро меняющемся мире необходимо, чтобы решения, касающиеся управления информацией, легко адаптировались к новым рынкам и учитывали появление новых возможностей. Технология DataBlade позволяет организациям быстро реагировать на любые изменения.
На сегодняшний день существует 29 модулей DataBlade для INFORMIX-Universal Server, которые охватывают широкий спектр типов данных. К июлю 1997 года количество поставляемых DataBlades увеличится где-то до 50. Для расширения возможностей своего сервера вы можете использовать уже готовые решения, если они отвечают вашим потребностям.
Более того, используя средства, предоставляемые Informix, вы можете разработать собственный DataBlade, который будет поддерживать именно ту функциональность, которая необходима для вас и ваших заказчиков. Если у вас уже есть собственные разработки, которые были сделаны для манипулирования вашими данными, их можно переработать в виде DataBlade так, чтобы работать с данными уже под управлением сервера, получив все преимущества работы в полнофункциональной среде базы данных. При разработке собственного DataBlade вы можете использовать собственную методологию и приемы манипулирования данными, что будет способствовать наиболее эффективной реализации работы с данными и позволит применять уже накопленный опыт и написанный код.
Функции для работы с данными пишутся на С/С++, что делает реальным использование уже существующих программ. Так как реализация методов работы с данными в виде DataBlade требует соблюдения определенных условий и приемов, то Informix предоставляет специальное средство - DataBlade Developer Kit, которое позволяет разрабатывать собственные DataBlades, которые будут органично вливаться в работу INFORMIX-Universal Server. Существует специальная программа DataBlade Developer Programme, участие в которой принимают уже и российские разработчики.
|
|