2.2. Новые возможности основных коммерческих SQL-ориентированных СУБД

Абсолютными лидерами на рынке коммерческих SQL-ориентированных СУБД являются системы Oracle, IBM DB2 и Microsoft SQL Server. В 2007-2008 гг. вышли новые версии этих продуктов: Oracle 11g [2], DB2 v.9 [3], SQL Server 2008 [4]. В совокупности в этих системах поддерживается множество новых и полезных возможностей, некоторые из которых кратко характеризуются ниже.

2.2.1. Поддержка параллельных баз данных

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

Та же идея перенесена Oracle в кластерную среду. В решении Oracle Real Application Cluster (RAC) [5] узлы кластера имеют равноправный доступ к общей дисковой подсистеме, и для всех узлов программным образом создается единое виртуальное буферное пространство. Другими словами, логика организации RAC, фактически, не отличается от логики построения параллельной СУБД для симметричных мультипроцессоров, хотя для реализации RAC потребовалось решение многих сложных технических проблем.

У компании IBM имеется кластерное решение DB2 Database Partitioning Feature (DPF) [6], ранее обеспечивавшееся продуктом DB2 Parallel Edition. По своей организации DB2 c DPF очень хорошо соответствует кластерной архитектуре: для работы системы не требуется общая основная или дисковая память, при оптимизации запросов минимизируется передача данных между узлами, система практически неограниченно масштабируется.

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

2.2.2. Встроенная поддержка хранилищ данных, OLAP и data mining

Параллельные версии всех трех семейств СУБД позволяют эффективно строить хранилища данных терабайтного и даже петабайтного масштаба. (Конечно, для этого требуется привлечение дорогостоящих аппаратных средств.) Однако при использовании традиционной для этих СУБД табличной организации данных становится трудно, а иногда и невозможно поддерживать специальные «аналитические» запросы к базам данных, характерные для приложений оперативной аналитической обработки данных (Online Analytical Processing, OLAP).

Для выполнения таких запросов требуется использовать «многомерные» модели данных, позволяющие представлять данные в виде многомерных кубов. Традиционно для этих целей использовались отдельные OLAP-серверы, однако в последние годы появилась тенденция включать средства поддержки многомерных кубов данных в состав программного обеспечения основных SQL-ориентированных СУБД. В частности, так было сделано в Microsoft SQL Server 2005 и Oracle 10g. Но эта тенденция не является безусловной. Например, после приобретения в 2007 г. компании Hyperion Oracle решила вернуться к использованию отдельного OLAP-сервера Essbase от Hyperion.

Все три компании обладают развитыми инструментами интеллектуального анализа данных (data mining) и продолжают активно развивать это направление. Средства data mining интегрированы в основные СУБД. Однако интересно то, что доступ к этим средствам во всех этих СУБД дается только при приобретении наиболее дорогостоящей «корпоративной» лицензии (хотя, например, средства OLAP предоставляются покупателям «стандартной» лицензии, ориентированной на предприятия малого и среднего бизнеса). Похоже, что сами поставщики не имеют четкого представления о том, кому и как следует пользоваться data mining. Требуются исследования практических потребностей пользователей.

2.2.3. Адаптивная оптимизация запросов

С каждым новым выпуском рассматриваемых СУБД в них повышается качество оптимизации запросов. Если еще 15 лет тому назад можно было серьезно относиться к «оценочной» (cost-based) оптимизации запросов только в СУБД IBM DB2, то в настоящее время развитые средства оптимизации запросов поддерживаются и в Oracle [7], и в Microsoft SQL Server [8].

В этой работе невозможно привести сколько-нибудь подробный обзор и анализ применяемых средств оптимизации запросов, поскольку это очень широкая и специальная область, но нужно отметить, что больше всего усилий тратится на поддержание надежной статистической информации о распределениях значений столбцов в таблицах, хранимых в базах данных и динамически образуемых при выполнении запросов. В этой связи нельзя не отметить влияние подхода IBM, реализованного в экспериментальном адаптивном оптимизаторе LEO [9], на основе которого разрабатывались средства оптимизации запросов в последующих выпусках DB2. В этом оптимизаторе статистическая информация уточняется при выполнении каждого запроса, а запросы, планы которых к моменту выполнения не соответствуют текущей статистической информации, динамически перекомпилируются.

Другим важным направлением оптимизации запросов является динамическое создание вспомогательных физических структур данных (индексов и материализованных представлений) на основе анализа потока запросов к базе данных. Здесь заметную роль сыграла группа исследователей компании Microsoft, лидером которой является Сураджит Чаудхари (Surajit Chaudhuri) [10].

Оптимизация запросов к SQL-ориентированным базам данных остается важной исследовательской областью, однако, по всей видимости, серьезный вклад в эти исследования могут внести только специалисты компаний, разрабатывающих основные SQL-ориентированные СУБД.

2.2.4. Управление транзакциями с поддержкой версий

Основной режим управления транзакциями в рассматриваемых СУБД основывается на двухфазном протоколе синхронизационных блокировок объектов базы данных. Этот подход был заложен еще в 1970-е годы в экспериментальном проекте System R компании IBM [11] и очень хорошо технически проработан. Однако применение этого подхода приводит к задержке выполнения транзакций, в которых данные только выбираются из базы данных и никогда не обновляются.

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

Начиная с SQL Server 2005, режим неблокирующего чтения поддерживается и компанией Microsoft [12]. Как и в Oracle 11g [13], в MS SQL Server, наряду с режимом «блокировочного» управления транзакциями пользователями может быть выбран режим «версионного» управления. Заметим, что IBM пока не следует примеру своих конкурентов, утверждая, что поддержка версий неоправданно повышает накладные расходы системы, не принося существенных преимуществ пользователям. По-видимому, и здесь требуются дополнительные исследования.

2.2.5. Встроенные файловые системы

Относительно возможности встраивания функций файловой системы в СУБД много говорилось еще до выхода Microsoft SQL Server 2005. Однако реальный шаг в этом направлении был сделан компанией Oracle в выпуске 11g. В этой СУБД появился новый тип данных SecureFiles [14], позволяющий создавать LOB-объекты, с которыми можно работать в файловом интерфейсе с сохранением всех прочих возможностей СУБД, в частности, журнализации и восстановления после сбоев. Oracle утверждает, что эта встроенная в базу данных файловая система исключительно эффективна, и призывает активно ей пользоваться для хранения обычных файлов.

В SQL Server 2008 Microsoft делает ответный ход, объявляя о поддержке типа данных FILESTREAM [15]. В решении Microsoft пользователи получают возможность доступа средствами SQL Server к файлам, хранящимся в файловой системе NTFS (при этом сохраняется ограниченная возможность доступа к тем же файлам на основе интерфейса Win32). Доступ к объектам типа FILESTREAM из SQL Server производится в транзакционном режиме с поддержкой журнализации и восстановления.

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

2.2.6. Средства расширения функциональных возможностей СУБД

Средства определения пользовательских типов данных, методов, функций и процедур появились в ведущих СУБД (Informix Universal Server, Oracle8, DB2 Universal Database) более десяти лет назад [16]. Тогда ожидалось, что эти средства будут активно использоваться партнерами компаний для обеспечения новых классов приложений. В течение примерно трех лет новая технология интенсивно обсуждалась. Многим в то время казалось, что объектно-реляционные СУБД (ОРСУБД) в корне изменят способы проектирования и разработки приложений баз данных.

Постепенно шум вокруг ОРСУБД затих. До конца 1990-х гг. Informix, Oracle и IBM совершенствовали свои ОРСУБД. В 1999 г. появился стандарт SQL:1999 [1], в котором были зафиксированы объектные расширения языка SQL. И, наконец, после выхода в 2003 г. стандарта SQL:2003, уточнившего и дополнившего SQL:1999, в сообществе баз данных окончательно перестали обсуждать объектно-реляционную технологию баз данных.

Однако, по нашему мнению, накопленный за 10 лет багаж объектных расширений, специфицированных в стандарте SQL и реализованных в передовых продуктах компаний IBM и Oracle, не должен бесславно пропасть. Это было бы нерационально, учитывая громадный объем человеческого труда, затраченного за создание этих расширений. Хочется надеяться, что с помощью исследовательского сообщества баз данных удастся решить упомянутые выше и другие проблемы и привлечь разработчиков к полноценному использованию возможностей ОРСУБД.

2.2.7. Поддержка темпоральных возможностей

Традиционные СУБД поддерживают работу с базами данных, в которых сохраняется только наиболее свежее состояние элементов данных. Идея «темпоральных» баз данных состоит в том, чтобы сделать время полноценным измерением данных, чтобы пользователи и приложения могли оперировать данными, соответствующими любому моменту времени прошлого. Следует отметить, что, несмотря на широкое признание полезности темпоральных баз данных, наличие большого числа выполненных исследовательских работ и большой задел в области темпоральных вариантов языка SQL [17], в ведущих SQL-ориентированных СУБД до последнего времени отсутствовала поддержка темпоральных возможностей.

Однако уже в Oracle9i появился механизм Flashback Query, позволяющий пользователям без внесения каких-нибудь структурных изменений в базу данных просмотреть состояние базы данных на какой-либо момент в прошлом. Механизм Flashback Query позволял получить доступ только к некоторому статическому снимку данных. В Oracle10g к этой технологии добавились еще несколько средств: Flashback Version Query позволяет просматривать все версии строк заданной таблицы в заданном интервале времени, находить транзакции, которые изменили заданную строку; Flashback Transaction Query дает возможность увидеть изменения, внесенные заданной транзакцией. Наконец, в Oracle 11g появилось средство Flashback Data Archive, позволяющее автоматически отслеживать и сохранять изменения всех данных, сохраняемых в базах данных Oracle. Эти данные могут сохраняться сколь угодно долго, и их можно запрашивать посредством Flashback SQL [18].

Oracle позиционирует свои средства категории Flashback, прежде всего, как средства восстановления баз данных после ошибок пользователей. Однако понятно, что их можно использовать для обеспечения истинно темпоральных свойств баз данных. Как кажется, компания Oracle двигается в направлении обеспечения полного спектра темпоральных расширений. Заметим, что отсутствие стандарта темпоральных расширений SQL мешает надеяться на то, что со временем все ведущие компании, производящие SQL-ориентированные СУБД, будут поддерживать унифицированные средства управления темпоральными данными.

2.2.8. Поддержка XML, неструктурированных и мультимедийных данных

В СУБД всех трех ведущих компаний уже сравнительно давно обеспечивается поддержка хранения XML-данных и доступа к ним. В последних выпусках систем поддерживается язык XQuery [59], языки модификации фрагментов XML-документов и т.д. В СУБД IBM DB2 v.9 и Oracle 11g для хранения XML-данных поддерживается отдельная подсистема управления памятью. Более того, в DB2 в качестве основного интерфейса доступа к базам данных можно использовать как SQL со встраиваемыми конструкциями XQuery, так и XQuery со встраиваемыми конструкциями SQL.

Базовые механизмы управления неструктурированными и мультимедийными данными опираются на поддержку типов данных BLOB и CLOB. Для работы с текстовыми документами обеспечиваются интегрированные с СУБД средства полнотекстового поиска: FullText Search в MS SQL Server 2005 [19], Oracle Text [20], начиная с Oracle8, Net Search Extender [21], начиная с DB2 v.8. Качество средств полнотекстового поиска повышается с каждым новым выпуском систем. В частности, с участием российских партнеров компаний совершенствуются возможности поиска в документах, представленных на русском языке.

Средства поддержки мультимедийных типов данных (геоинформационных, аудио- и видеоданных) в СУБД компаний Oracle и DB2 появились сразу после выпуска этими компаниями систем с объектными расширениями – Oracle8 и DB2 Universal Database. Пожалуй, именно в этой области объектные расширения принесли наибольшую пользу. Следует отметить, что Microsoft включает в свою систему поддержку геоинформационных данных, только начиная с SQL Server 2008.

Одной из проблем поддержки неструктурированных и мультимедийных данных (да и XML-данных) в SQL-ориентированных СУБД является то, что эти данные в них не являются «жителями первого сорта». Они вторичны по отношению к данным встроенных типов, поддерживаемым на уровне ядра СУБД. Отсюда следует неизбежное снижение эффективности при работе СУБД с такими данными.

2.2.9. Применение систем управления базами данных в основной памяти

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

Имеется альтернативный подход к организации баз данных, при котором база данных целиком поддерживается в основной памяти, и все структуры данных оптимизированы в расчете на это; журнализация изменений базы данных не производится, а поддержка транзакционности обеспечивается за счет репликации данных. К категории таких систем относится СУБД TimesTen [22], приобретенная Oracle вместе с одноименной компанией в 2005 г. После выпуска Oracle 11g этот продукт был переименован в Oracle In-Memory Database Cache. Компания планирует интегрировать его с 11g для использования в качестве кэширующего сервера при работе с основными базами данных. Можно ожидать очень интересных результатов.

2.2.10. Заключение раздела

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

Назад Содержание Вперёд