Ландшафт области управления данными: аналитический обзор
| Вид материала | Реферат |
- Библиотеки Челябинского региона – юношеству Аналитический обзор по материалам отчетов, 678.96kb.
- Аналитический обзор нормативных правовых актов, регламент, 713.14kb.
- «Аналитический обзор харьковской недвижимости и рынка недвижимости Украины», 614.94kb.
- Советский «культурный ландшафт», 317.52kb.
- Аналитический обзор, 3813.67kb.
- Аналитический обзор материалов V всероссийской конференции оториноларингологов, 154.56kb.
- Тезисы доклада на семинаре «Культурный ландшафт», 22.64kb.
- Viii. Управление данными план, 131.4kb.
- Группа социально-политического мониторинга и маркетинговых исследований аналитический, 404.84kb.
- Закрытое акционерное общество «НижБизнесКонсалтинг», 1672.18kb.
Ландшафт области управления данными: аналитический обзор
С.Д. Кузнецов, М.Н. Гринев
Институт системного программирования РАН
Содержание
1. Введение
2. Реляционные производственные системы
2.1. SQL как практическая замена реляционной модели данных
2.2. Новые возможности основных коммерческих SQL-ориентированных СУБД
2.3. Российская SQL-ориентированная СУБД Линтер
2.4. Перспективы свободно доступных SQL-ориентированных СУБД
3. Объектно-ориентированные базы данных
3.1. История ООСУБД
3.2. Современное состояние дел и перспективы
4. Объектно-реляционные отображения
4.1. История проблемы impedance mismatch и подходы к ее решению
4.2. Почему объектно-ориентированных программистов не устраивают ни объектные расширения SQL-ориентированных баз данных, ни ООСУБД?
4.3. Подходы к обеспечению объектно-реляционного отображения
4.4. Современное состояние и проблемы
5. Новые технологии для обработки потоковых и сенсорных данных
5.1. Требования реального времени
5.2. Прикладные области, в которых требуется обработка потоковых данных
5.3. История потоковых систем, существующие системы и их особенности
5.4. Проблемы управления данными в сенсорных сетях
5.5. История систем управления сенсорными данными и их особенности
6. Системы управления полуструктурированными и неструктурированными данными
6.1. XML как общепринятый формат представления полуструктурированных данных, стандарты XML
6.2. Особенности и подходы систем управления XML-данными
6.3. Проблемы XML-СУБД
6.4. Системы текстового поиска и потребности в поддержке семантики
6.5. Краткая характеристика целей и методов направления Semantic Web
6.6. Проблемы семантически обогащенных систем
7. Фундаментальные проблемы управления данными
7.1. Интеграция текста, данных, кода и потоков
7.2. Интеграция информации
7.3. Сенсорные данные и сенсорные сети
7.4. Использование неточных данных
7.5. Самоадаптация
7.6. Безопасность и конфиденциальность данных
Литература
1. Введение
Программные средства управления данными составляют важнейшую часть системного программного обеспечения. Сегодня, как и в прошлые годы, наиболее распространенной категорией средств управления данными являются системы управления базами данных (СУБД). Однако все чаще возникает потребность в программных средствах, характеристики которых существенно отличаются от характеристик традиционных СУБД, и которые применяются в приложениях, где универсальные SQL-ориентированные СУБД слишком тяжеловесны и/или недостаточно функциональны и эффективны. Кроме того, и в самих «традиционных» SQL-ориентированных СУБД появляется все больше совсем нетрадиционных возможностей, предназначенных для расширения их областей применения.
Тем самым, область управления данными непрерывно расширяется, и в ней все труднее ориентироваться. Тем более трудно написать материал осмысленного объема, в котором анализировались бы все интересные черты современного состояния этой области. В этом обзоре мы ограничиваемся некоторой субъективной выборкой тем, относящихся к области управления данными, которые кажутся нам наиболее существенными и перспективными, оставляя вне рассмотрения ряд направлений, возможно, заслуживающих внимания.
Во втором, самом объемном разделе обзора, обсуждаются наиболее интересные возможности, появившиеся в последних версиях семи SQL-ориентированных СУБД: трех ведущих коммерческих реляционных СУБД (Oracle, IBM DB2 и Microsoft SQL Server), единственной российской коммерческой СУБД Линтер компании Релэкс и трех наиболее развитых SQL-ориентированных СУБД с открытыми исходными текстами (MySQL, PostgreSQL и Firebird). Конечно, имеется ряд других SQL-ориентированных СУБД, которые, безусловно, заслуживают внимания, но в данном обзоре авторы приняли решение ограничиться этой выборкой.
Третий раздел обзора посвящен объектно-ориентированным СУБД (ООСУБД), которые были очень популярны до конца 1990-х гг. В начале этого века интерес к ним упал ниже критической отметки, но в последние годы ООСУБД начинают заново набирать популярность. Описываются основные черты наиболее известных ООСУБД прошлых лет и рассматриваются текущие события, свидетельствующие о возрождении этого направления.
В четвертом разделе обсуждается направление, целью которого является создание средств промежуточного программного обеспечения, обеспечивающего так называемое объектно-реляционное отображение, т.е. возможность работы с реляционными данными через объектную модель, на основе которой строится приложение. Приводятся соображения авторов по поводу причин неудовлетворенности объектно-ориентированных программистов базовыми средствами SQL-ориентированных и объектно-ориентированных СУБД, описываются категории средств объектно-реляционного отображения и присущие им проблемы.
В пятом разделе рассматривается состояние дел в направлении систем управления сенсорными и потоковыми данными. Обсуждаются причины, по которым в соответствующих прикладных областях непригодны универсальные СУБД. Описываются некоторые исследовательские и коммерческие системы.
Шестой раздел посвящается системам управления неструктурированными и полуструктурированными данными. В частности, обсуждается состояние дел в направлении систем управления XML-данными.
Наконец, в седьмом разделе рассматривается несколько фундаментальных проблем области управления данными. Некоторые из этих проблем частично решаются в системах, рассматриваемых в предыдущих разделах, но в целом для их решения необходимо проведение масштабных исследований и разработок.
2. Реляционные производственные системы
Основным видом систем управления данными, с которыми работают приложения, являются «реляционные», а точнее SQL-ориентированные СУБД. В этом разделе описываются текущее состояние и проблемы этой области.
2.1. SQL как практическая замена реляционной модели данных
Сегодня для большинства людей, не являющихся профессионалами в области баз данных, язык SQL является практическим воплощением реляционной модели данных. В действительности, в стандартах языка SQL определяется некоторая собственная модель данных, в чем-то похожая на реляционную модель, но значительно от нее отличающаяся [1].
SQL-ориентированная база данных представляет собой набор таблиц, каждая из которых в любой момент времени содержит некоторое мультимножество строк, соответствующих заголовку таблицы. В этом состоит первое и наиболее важное отличие модели данных SQL от реляционной модели данных, в которой фундаментальная абстрактная «родовая» структура данных отношение, представляет собой множество кортежей. Вторым существенным отличием является того, что для таблицы поддерживается порядок столбцов, соответствующий порядку их определения. В реляционной модели данных атрибуты отношения не упорядочены. Другими словами, таблица – это вовсе не отношение, хотя во многом они похожи.
Из этого, в частности, следует, что в модели данных SQL отсутствует обязательное предписание об ограничении целостности сущности. В базе данных могут существовать таблицы, для которых не определен первичный ключ. С другой стороны, если для таблицы определен первичный ключ, то для нее ограничение целостности сущности поддерживается точно так же, как это требуется в реляционной модели данных.
Ссылочная целостность в модели данных SQL поддерживается в обязательном порядке, но в трех разных вариантах, лишь один из которых полностью соответствует реляционной модели. Это связано с интенсивным использованием в SQL неопределенных значений.
Наличие модели данных SQL, похожей на реляционную модель данных, но принципиально от нее отличающейся, затрудняет использование SQL-ориентированных СУБД. Часто проектировщики баз данных не учитывают эти различия и производят схемы SQL-ориентированных баз данных с иногда неожиданным поведением. После появления стандартов SQL:1999 и SQL:2003 [1], в которых определены возможности определения произвольно сложных «пользовательских» типов данных и «типизированных» таблиц, ситуация с проектированием SQL-ориентированных баз данных еще больше усложнилась. Требуется проведение исследовательских работ с целью выработки методологии использования всех возможностей SQL, понятной разработчикам приложений баз данных.
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. Заключение раздела
Как показывает краткий (и далеко не полный) обзор наиболее интересных возможностей СУБД трех ведущих производителей, в них действительно удалось реализовать очень развитые технологии управления данными. Однако этим системам свойственен ряд проблем, все более затрудняющих их использование и дальнейшее развитие: чрезмерная сложность и тяжеловесность, переизбыток возможностей, трудность внедрения средств для поддержки новых приложений.
2.3. Российская SQL-ориентированная СУБД Линтер
СУБД Линтер является единственной существующей в настоящее время коммерческой российской СУБД. Она разработана и развивается компанией Релэкс, г. Воронеж. Конечно, по набору поддерживаемых возможностей, по производительности при работе со сверхбольшими базами данных, по объему своего внедрения эта система значительно уступает SQL-ориентированным СУБД, обсуждавшимся в разд. 2.2, но она обладает рядом интересных особенностей, которые делают ее привлекательной для разработчиков приложений, в особенности, в России.
2.3.1. Основные технические характеристики СУБД Линтер
В СУБД Линтер [23] полностью поддерживается стандарт SQL/92, включая средства определения данных, выборки и манипулирования данными, определения ограничений целостности, управления транзакциями и т.д. В последних выпусках системы имеется поддержка некоторых средств, определенных в стандартах SQL:1999 и SQL:2003 (аналитические функции, предикаты similar и match и т.д) За счет использования версионного метода управления транзакциями поддерживается режим неблокирующего выполнения транзакций, в которых отсутствуют операции изменения базы данных. Имеется возможность использования типа данных BLOB, позволяющего работать с большими (объемом до двух Гб) неструктурированными объектами данных. Поддерживаются средства определения хранимых процедур и триггеров.
В системе обеспечивается ряд средств, позволяющих создавать гибкую и надежную систему безопасности и конфиденциальности информации (эти средства сертифицированы Гостехкомиссией на соответствие 2-му классу защиты информации от несканкционированного доступа).
В состав дистрибутива СУБД Линтер входят следующие компоненты:
- ядро СУБД Линтер (подсистема управления данными, транслятор SQL, процессор сортировки, компилятор хранимых процедур, сетевые драйверы, менеджер распределённых транзакций);
- программы обслуживания базы данных (генератор системной базы данных, тестер физических структур);
- организующие интерфейсы (инструментарий администратора, менеджер хранимых процедур со встроенным отладчиком, интерактивный SQL-интерфейс);
- средства разработки приложений (встроенный SQL для C/C++, исполняющая система 4GL языка Intcom, средство интерактивной разработки Лакуна);
- средства сохранения/восстановления данных (в том числе «горячее» архивирование, быстрая загрузка/выгрузка всей базы данных или отдельных её частей и т.п.);
- средства миграции данных (импорт из DBF, ODBC-средство миграции и т.п.);
- интерфейсы различного уровня (ODBC-драйвер, интерфейс прямого доступа к Линтер из Delphi/Kylix/C++ Builder, интерфейс для Java-программ, API-интерфейс Линтер, Call-интерфейс и т.д.).
2.3.2. Поддержка реального времени
Многие заказчики компании Релэкс используют в своей работе операционные системы реального времени. СУБД Линтер изначально проектировалась так, чтобы удовлетворять ограничениям, которые накладывает функционирование в таких операционных системах [24]. Архитектура Линтер достаточно гибка для переноса в разные программно-аппаратные среды. В настоящее время СУБД Линтер функционирует как на платформах Windows CE и Linux, так и в средах различных операционных систем реального времени (QNX 4, QNX6, VxWorks, ОС РВ, OS/9, OS9000) на разнообразных аппаратных платформах (x86, PPC, Sparc, ARM, MIPS и т.д.). При этом обеспечивается полная совместимость по протоколам взаимодействия между узлами под управлением разных операционных систем, что позволяет использовать единую инфраструктуру и для поддержки технологического оборудования, и для аналитических систем.
Использованию СУБД Линтер во встроенных системах реального времени способствуют небольшие требования к оперативной памяти. Даже полный серверный вариант системы может поместиться в 4Мб оперативной памяти. Важным фактором использования Линтер в системах реального времени является постоянство используемых ресурсов, или возможность ограничения ресурсов. Гарантируется постоянство использования оперативной памяти (вне зависимости от объема базы данных, сложности выполняемых запросов и количества одновременно работающих пользователей и приложений).
При создании базы данных имеется возможность гибкой конфигурации расположения файлов базы данных. Допускается размещение файлов разных таблиц и типов на разных устройствах. Это особенно актуально при эксплуатации СУБД во встроенной технике, когда у разных устройств имеются разные характеристики скорости и надежности хранения информации. Наличие журнала и механизмы восстановления базы данных гарантируют восстановление базы данных после сбоев по питанию, что особенно важно для технологических и встроенных необслуживаемых систем, которые обычно и разрабатываются с использованием операционных систем реального времени.
Отличительной особенностью интерфейса СУБД Линтер является полная асинхронность. Любой запрос, поданный ядру СУБД, будет выполняться асинхронно. В системах реального времени возможность продолжать обработку данных вне зависимости от реакции хранилища данных очень важна. Во время обработки запроса к базе данных можно продолжать обработку входных данных или управлять исполнительными устройствами. Интерфейс Линтер позволяет также функционировать многопотоковым приложениям: вся синхронизация обмена с базой данных выполняются прозрачно для программы. Потоки могут также работать асинхронно.
Дополнительной возможностью для повышения производительности является предварительная трансляция запросов. В случае такой трансляции при выполнении запроса уже не требуется его синтаксически разбирать, вырабатывать план выполнения и т.п. В полностью готовый к исполнению запрос необходимо будет только подставить параметры (если они есть), и его можно выполнить.
В системах реального времени особое внимание уделяется приоритетам исполнения запросов. Возможность исполнения запросов с различными приоритетами была заложена в Линтер, начиная с самых первых версий, и с тех пор была значительно усовершенствована. Предлагаются три класса приоритетов исполнения запросов: обычные приоритеты, приоритеты Round Robin и приоритеты реального времени. Приоритетами исполнения запросов можно управлять в процессе работы системы через специальные управляющие команды. Кроме изменения приоритета возможна отмена выполнения запроса или приостановка его выполнения на некоторое время.
Очень мощным аппаратом СУБД Линтер, активно используемым в системах реального времени, является аппарат событий. Событие представляет собой объект синхронизации распределенных приложений или извещения приложений об изменении в данных.
Перспективным планом компании Релэкс является постепенная переделка ядра СУБД в соответствии с микроядерной технологией. Новая архитектура должна обеспечить возможности «горячего» обновления отдельных модулей и наращивания функциональности без остановки СУБД. Конечно, для перехода на новую архитектуру коллективу предстоит решить ряд опытно-конструкторских задач.
2.4. Перспективы свободно доступных SQL-ориентированных СУБД
Наряду с коммерческими системами в мире SQL-ориентированных СУБД существуют и развиваются системы, разрабатываемые и распространяемые на основе подхода «открытых исходных текстов» (open source). Среди них наиболее известны MySQL [25], PostgreSQL [26] и Firebird [27]. В этих системах интересны не только способы их разработки, технические особенности и области применения, но также и то, что в их развитии и совершенствовании активно участвуют российские разработчики.
В этом разделе приводится общая характеристика систем, рассматриваются различия в их организации и способах разработки. Обсуждается, в каких областях эти системы могут конкурировать с коммерческими системами, и указываются основные проблемы, которые, по мнению авторов обзора, предстоит решить для обеспечения надежной жизнеспособности SQL-ориентированных СУБД с открытыми кодами.
2.3.1. MySQL
Особенностью СУБД MySQL является то, что, будучи системой с открытыми исходными текстами, она разрабатывалась коммерческой компанией MySQL AB (в числе сотрудников этой компании немало специалистов из России и Украины). Более того, в действительности компания распространяла свою систему в двух вариантах: бесплатном и корпоративном, под разработанной в самой MySQL AB коммерческой лицензии. До августа 2007 г. исходные коды обоих вариантов находились в свободном доступе, но затем доступ к текстам программ коммерческой версии был закрыт для всех, кроме корпоративных клиентов, оплативших лицензию.
В начале 2008 г. компания MySQL AB была приобретена компанией Sun Microsystems. Sum Microsystems официально утверждает, что «новая СУБД MySQL корпорации Sun Microsystems является ключевым компонентом популярных программных комплексов для создания приложений Web 2.0». [28]. Однако к середине 2008 г. не видно серьезного воздействия перехода MySQL в собственность Sun Microsystems на дальнейшую разработку MySQL. Пока все работы по развитию MySQL идут по ранее намеченному плану.
Текущим выпуском системы является MySQL Enterprise Server 5.1 [29]. По сравнению с предыдущей версией 5.0, вышедшей в октябре 2005 г., в MySQL 5.1 появился ряд новых возможностей, которые компания MySQL AB относит к областям хранилищ данных и интеллектуального анализа данных; средств обеспечения высокой доступности данных; упрощенного управления и средств обеспечения высокой производительности.
В области хранилищ данных и интеллектуального анализа данных основным нововведением является средство горизонтального разделения таблиц и индексов (по диапазону значений, с хэшированием и т.д.). Разделение таблиц возможно для всех подсистем хранения данных, используемых в MySQL: MyISAM, Archive, InnoDB и т.д. Кроме того, к этой области относится новый подключаемый модуль, поддерживающий полнотекстовый поиск, и поддержка XPath для работы с XML-данными с возможностью выбора и модификации узлов XML-документов на стороне сервера баз данных.
Для повышения уровня доступности данных наряду с механизмом репликации на основе операторов SQL, существовавшим в MySQL 5.0, в MySQL 5.1 обеспечивается средство репликации таблиц на уровне строк. В MySQL Cluster появилась поддержка данных, сохраняемых в дисковой памяти, и также обеспечивается возможность асинхронной репликации данных из одного кластера в другой.
Для облегчения управления системами баз данных в MySQL 5.1 появился планировщик событий, позволяющий администраторам базы данных создавать и запускать запланированным образом задания, выполняющие различные функции на сервере баз данных.
Достижению более высокой производительности содействует новое средство параллельной загрузки базы данных, а также утилита стрессового тестирования, которая моделирует поведение заданного числа пользователей, задающих запросы разного вида. После завершения работы этой утилиты формируется отчет, содержащий статистические данные о работе сервера.
На конец 2008 г. планируется выпуск MySQL 6.0, в котором будет внедрена новая подсистема управления данными Falcom, обеспечивающая полную поддержку транзакций со свойствами ACID. Эта подсистема не предназначена для замены транзакционной подсистемы управления данными InnoDB, но, по мнению разработчиков, в ряде случаев будет работать более эффективно. Кроме того, в MySQL 6.0 должны обеспечиваться поддержка неблокирующих вариантов операций, изменяющих схему таблиц, а также ожидается ряд нововведений в оптимизаторе запросов SQL.
2.3.2. PostgreSQL
Под названием PostgreSQL система существует с 1996 года. Это название отражает связь PostgreSQL с оригинальным проектом Postgres и внедрением в систему поддержки языка SQL [30]. Управление проектом осуществляет небольшая группа инициативных пользователей и разработчиков, называемая PGDG (PostgreSQL Global Development Group). В число основных разработчиков PostgreSQL входит ряд российских специалистов.
В начале февраля 2008 г. была выпущена СУБД PostgreSQL 8.3 [31], в работе над которой принимали участие десятки разработчиков из 18 стран. В течение 15 месяцев разработки и тестирования были обработаны и успешно внедрены более 280 пакетов изменений исходного кода. Основные изменения и новшества разработчики разбивают на три части: средства, способствующие улучшению производительности; новые возможности для программистов приложений баз данных; нововведения, предназначенные для администраторов баз данных.
Основными новыми средствами, способствующими повышению производительности СУБД PostgreSQL 8.3, являются механизм асинхронной фиксации транзакций и синхронизованные просмотры таблиц. При асинхронной фиксации не происходит немедленного выталкивания во внешнюю память записи о фиксации транзакции. Тем самым, существенное повышение производительности сопровождается риском потери результатов последних по времени транзакций при крахе системы. Синхронизированный просмотр таблицы позволяет избежать нескольких просмотров одной таблицы при одновременном выполнении нескольких однотипных запросов.
Наиболее существенным изменением PostgreSQL, затрагивающим интересы разработчиков приложений, является миграция модуля полнотекстового поиска tsearch2 в ядро системы. Другое заметное изменение — поддержка XML. Появился специальный тип данных xml, встроенный в ядро. В соответствии со стандартом SQL:2003 реализован набор функций для преобразования реляционных данных в XML (т. н., функции публикации SQL/XML). Для ускорения выполнения запроса к XML-данным возможно использование функциональных индексов и GIN-индексов, а также использования полнотекстового поиска для XML-данных. Соответствующие программные средства были разработаны российскими программистами.
Администраторам наиболее полезно новое средство EXPLAIN ANALYZE, позволяющее узнать, какой именно алгоритм сортировки был выбран для выполнения запроса, и сколько памяти было израсходовано. При определении функции теперь можно переопределять переменные окружения, которые будут действовать только в рамках выполнения данной функции (привязка к функциям значений переменных).
В настоящее время уточняется состав новых функциональных возможностей, которые должны войти в следующую версию PostgreSQL 8.4. Работа над этой версией уже активно ведется, и завершение планируется в начале 2009 г.
Продукты на основе исходных текстов PostgreSQL производит не только сообщество PostgreSQL под управлением PGDG, но и коммерческие компании, наиболее известной среди которых является EnterpriseDB Corporation [32]. Эта компания выпускает свободно доступный продукт Postgres Plus и совместимую с Oracle коммерческую систему Postgres Plus Advanced Server. Наиболее интересным и совершенно новым для мира PostgresSQL является интегрированный с Postgres Plus продукт GridSQL, в котором реализуется архитектура распределенных баз данных без общих ресурсов между узлами.
2.3.3. Firebird
Как говорится на официальном сайте проекта [27], «Firebird – это коммерчески независимый проект программистов сообщества C/C++, технических консультантов и спонсоров, разрабатывающих и совершенствующих мультиплатформенную реляционную СУБД, основанную на исходных кодах, которые были переданы в свободное использование 25 июля 2000 г. компанией Inprise Corp. (называемой теперь Borland Software Corp)». Речь здесь идет про исходные тексты СУБД InterBase 6.0. Коммерческую линию развития этой системы продолжает Borland.
В апреле 2008 г. после двухлетней работы команды разработчиков, значительную часть которой составляют российские специалисты, была выпущена версия Firebird 2.1 [33]. В этой версии улучшены средства администрирования баз данных, повышена производительность системы и введена поддержка ряда новых средств языка SQL.
Упростить администрирование позволяют новые виртуальные таблицы мониторинга, на основе которых администраторы могут увидеть статистическую информацию о сервере в целом, а рядовые пользователи – только те данные, которые соответствуют их соединению. Введена возможность аутентификации пользователей средствами Windows.
На уровне SQL появилась возможность определения триггеров, условием срабатывания которых являются подключение к базе данных, начало, фиксация и откат транзакции и т.д. Появилась возможность использования глобальных временных таблиц и общих табличных выражений, которые, в частности, можно использовать для формулировки рекурсивных запросов. Введена конструкция UPDATE OR INSERT, срабатывающая как UPDATE, если условию оператора соответствует хотя бы одна строка целевой таблицы, и как INSERT в противном случае. Наконец, поддерживается оператор MERGE, позволяющий слить две таблицы. Следует заметить, что не все введенные средства SQL присутствуют в стандарте языка.
Наконец, основным средством повышения производительности является новый сетевой протокол, в котором, в частности, некоторые виды пакетов группируются и посылаются в сеть вместе.
Ожидаемый в конце этого года выпуск Firebird 2.5 разработчики рассматривают как важный шаг на пути к СУБД Firebird 3.0, которая будет представлять собой параллельный масштабируемый сервер с универсальной архитектурой, ориентированной на симметричные мультипроцессоры.
2.3.4. Плюсы и минусы SQL-ориентированных СУБД с открытыми кодами
СУБД этой категории активно используются в разных приложениях, в которых не требуются качества, присущие коммерческим системам высшего класса. Одной из наиболее важных заслуг этого направления является то, что оно дает возможность приобретения мастерства разработки и сопровождения СУБД молодежи, в том числе, и российским молодым специалистам. Открытость систем позволяет участвовать в их разработке практически всем желающим при наличии соответствующих наклонностей и способностей.
Проблемами сводобно доступных SQL-ориентированных СУБД, которые необходимо решить для обеспечения их надежной жизнеспособности, являются отсутствие новых идей и подходов, вечная погоня за «большой тройкой», недостаточная надежность, производительность и масштабируемость. Все эти проблемы очень серьезны, и удастся ли их преодолеть в полном объеме хотя бы в одном из проектов, покажет будущее.