WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |
УПРАВЛЕНИЕ ДАННЫМИ: ДОСТИЖЕНИЯ И ПРОБЛЕМЫ М.Н. Гринев, С.Д. Кузнецов Институт системного программирования РАН 109004, г. Москва, ул. Б. Коммунистическая, д. 25 Аннотация. В статье приводится аналитический обзор нескольких областей управления данными, представляющихся в настоящее время наиболее важными.

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

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

Обсуждаются фундаментальные проблемы управления данными, требующие проведение научно-исследовательских работ.

Annotation. The paper provides an analytical overview of several areas of data management currently considered to be the most important. The authors are discussing directions of SQL-based DBMSs; object-oriented DBMSs; middleware tools that provide object/relational mapping; stream and sensor data management systems; XML DBMSs and unstructured data management systems. Each of these directions has its own advances and problems which solving will help to improve characteristics of systems. To solve these problems research and development work is needed. Challenges of data management field are also discussed that requires basic research.

1 1. Введение Статья содержит аналитический обзор достижений в разных областях управления данными и проблем, которые существуют в этих областях. В разделах 2-6 обсуждаются области, в которых уже существуют программные решения, в той или иной степени пригодные для использования в приложениях. Для преодоления недостатков существующих решений требуется проведение опытно-конструкторских работ, результатами которых должны являться новые экспериментальные системы управления данными. В разд. 7 приводится анализ областей управления данными, в которых требуется проведение фундаментальных исследований.

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) [6] узлы кластера имеют равноправный доступ к общей дисковой подсистеме, и для всех узлов программным образом создается единое виртуальное буферное пространство. Другими словами, логика организации RAC, фактически, не отличается от логики построения параллельной СУБД для симметричных мультипроцессоров, хотя для реализации RAC потребовалось решение многих сложных технических проблем.

У компании IBM имеется кластерное решение DB2 Database Partitioning Feature (DPF) [7], ранее обеспечивавшееся продуктом 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 [8], и в Microsoft SQL Server [9].

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

Другим важным направлением оптимизации запросов является динамическое создание вспомогательных физических структур данных (индексов и материализованных представлений) на основе анализа потока запросов к базе данных.





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

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

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

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

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

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

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

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

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

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

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

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.