Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT (стр. 6 из 27)

Для DB2/390 основными тенденциями развития являются, с одной стороны, стремление к наращиванию производительности, что связано с тенденцией физического роста корпоративных баз данных, а с другой стороны, укрепление интеграции с прочими программными средствами на различных платформах.

DB2 для MVS версии 3, появившаяся в 1992 году, обладала серьезными улучшениями в области производительности, на основе распараллеливания операций ввода/вывода и работы с независимыми разделами дисковых устройств, использования возможностей аппаратного обеспечения и операционной системы, например методов компрессии данных и аппаратной поддержки сортировки.

В DB2 для MVS версии 4 важные добавления были сделаны в поддержку архитектуры клиент-сервер, использования DB2 в масштабируемой архитектуре Parallel Sysplex, возможности распараллеленного исполнения запросов. Появились также хранимые процедуры как важное средство снижения сетевого трафика и перенесения бизнес-логики приложений на сервер баз данных. Также увеличились возможности DB2 по поддержке клиентов до 25 тысяч на один сервер, а с учетом возможности параллельной работы в группе до 32 узлов DB2 в Parallel Sysplex - до 800 тысяч клиентов.

Для архитектуры клиент-сервер наиболее важные улучшения связаны с поддержкой клиентов в сетях TCP/IP, хранения данных в ASCII-форматах, более развитых механизмов хранимых процедур, стандартизацией DB2 SQL и появлением продукта DB2 WWW Connection для доступа к данным из Internet.

Архитектура DRDA. При изначальной ориентации DB2 на платформах MVS, VM, VSE на централизованные приложения впоследствии, в условиях распространения архитектуры клиент-сервер, потребовалась дополнительная поддержка удаленного доступа для PC- и Unix-рабочих станций к базам данных на мэйнфреймах и на системах типа AS/400.

Решая проблему поддержки архитектуры клиент-сервер, IBM предложила архитектуру DRDA (Distributed Relational Database Architecture) в виде открытой спецификации, описывающей протоколы взаимодействия удаленного клиента с базами данных. Реализация DRDA должна была позволить продуктам от разных производителей баз данных прозрачно взаимодействовать и, в частности, образовывать единую распределенную базу данных.

Подход DRDA позволяет решить многочисленные проблемы кросс-платформенного взаимодействия, в частности конвертацию ASCII- и EBCDIC-данных, различия в диалектах SQL, командах, типах данных, строении каталогов. В настоящее время архитектуру DRDA поддерживают прежде всего все серверы семейства DB2; остальные производители реализовали продукты типа DRDA-реквесторов, которые позволяют прикладным программам-клиентам иметь доступ к базам DB2, например к DB2/390.

Типичный пример такого DRDA-реквестора производства IBM - продукт DDСS, работающий на OS/2, AIX, Windows, Windows NT, служащий многопользовательским шлюзом к DB2 для пользователей локальной сети или, в случае однопользовательского варианта, работающий на компьютере клиента. Реализация поддержки DRDA по протоколам TCP/IP, в добавление к традиционной поддержке протоколов SNA, в новых версиях серверов DB2 и шлюзов DDCS значительно упрощает многочисленным пользователям доступ к базам данных DB2 на мэйнфреймах и AS/400.

DB2 Common Server. Эксплуатация реляционных баз данных поставила перед разработчиками практические задачи по дополнению СУБД новыми возможностями и привела к появлению нового поколения систем управления базами данных, так называемых расширенных реляционных (extended relational) СУБД. К этому классу относят системы управления базами данных, поддерживающие ряд дополнительных возможностей, которые выходят за рамки реляционной алгебры, - триггеры, хранимые процедуры, контроль целостности и т. д.

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

Целью проекта IBM Starburst в конце восьмидесятых годов было создание такой расширяемой системы управления реляционными базами данных. Практическим результатом проекта Starburst и его продолжения проекта Starwings было появление семейства DB2 Common Server в 1993 г.

Для поддержки OLTP-приложений в DB2 Common Server реализовано большое число механизмов, улучшающих производительность, включая разнообразные алгоритмы буферизации, алгоритмы контроля ресурсов и методы мониторинга, конфигурации и настройки параметров системы, использующие статистику системы.

Система управления буферизацией использует алгоритмы распараллеливания операций ввода/вывода, предварительного чтения данных и индексов, асинхронной записи на диск и многие другие. DB2 Performance Monitor, поставляемый вместе с DB2, предоставляет широкие возможности для сбора и анализа данных о производительности системы, включая информацию о событиях и периодические срезы параметров производительности.

Оптимизатор DB2 является одним из наиболее важных компонентов, обеспечивающих DB2 высокую производительность и адаптацию к различным задачам. DB2 строит так называемую QGM (Query Graph Model) для внутреннего представления запросов и использует ее на этапах проверки семантики запросов, преобразования запросов к оптимальному виду и построения плана исполнения запроса. Расширяемость QGM позволяет легко добавлять к SQL DB2 новые конструкции.

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

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

DB2 Common Server, появившаяся в 1995 году, уже содержит инфраструктуру для реализации объектно-ориентированных функций, на основании которой построены реляционные расширения DB2 (relational extenders). Расширения позволяют определять структуру, атрибуты и поведение новых типов данных, сохранять эти данные в таблицах DB2 и затем использовать их в SQL-выражениях. В общем случае при создании новых типов данных используется UDT (User Defined Type - определяемые пользователем типы данных) DB2, часто основанные на применении больших объектов DB2, поведение новых типов данных определяется с помощью нескольких UDF (User Defined Function - определяемая пользователем функция). При этом механизмы триггеров (triggers) и ограничений (constrains), предлагаемые DB2, оснащающие базу данных возможностями хранить правила поведения данных, могут использоваться для управления внутренней структурой новых сложных типов данных.

Подобно некоторым другим базам данных, DB2 Common Server позволяет хранить данные в больших бинарных (BLOB) и символьных (CLOB) объектах. Размер объекта может достигать 2 Гбайт.

Поскольку размер таких объектов сильно отличается от традиционных данных, на обработку которых настроены серверы реляционных баз данных, то DB2 содержат ряд функций помогающих обеспечить нормальную производительность: переменные типа локаторов, ссылки, специальные режимы при журналировании. Кроме того, IBM предлагает специализированные программные и аппаратные решения, такие как Digital Library, ориентированные на хранение и высокопроизводительную обработку мультимедийных данных и на взаимодействие с DB2.

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

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

DB2 кроме естественной роли быть источником операционных данных для пополнения хранилищ обеспечивает хранение самих информационных данных и эффективное выполнение сложных запросов, включающих многочисленные соединения таблиц, вычисления и методы группировки данных. В частности, уже сейчас оптимизатор DB2 Common Server поддерживает оптимизацию запросов к базам данных, смоделированным по принципу звезды (Star Schema), широко используемым для OLAP (Online Analytical Processing) приложений и состоящим из большой таблицы фактов и нескольких таблиц размерностей.

Для поддержки очень больших баз данных объемом в сотни гигабайт и даже терабайт семейство DB2 предлагает два решения, основанные на технологиях распараллеливания - DB2/390 в Parallel Sysplex (архитектура Data Sharing) и DB2 Parallel Edition.

Архитектура DataSharing позволяет масштабировать решения путем подключения дополнительных серверов и при увеличении объемов данных, и при увеличении количества и сложности запросов. При выполнении сложных запросов поддерживается техника разделения запроса на отдельные задачи и выполнение этих задач параллельно несколькими серверами DB2, входящими в Sysplex.