Автор: М. Зельцер. Перевод: С.В. Кузнецов
Источник: Інформаційні управляючі системи та комп’ютерний моніторинг (ІУС КМ - 2011) - 2011 / Матерiали II мiжнародної науково-технiчної конференцiї студентiв, аспiрантiв та молодих вчених. — Донецьк, ДонНТУ — 2011, Том 2, с. 132-136.
М. Зельцер, С.В. Кузнецов. За пределами реляционных баз данных: доступ к базам данных не ограничивается возможностями SQL Рассмотрены системы блочного моделирования. Исследовано моделирование уравнения гармонического осциллятора. Проведено сравнение моделирующих сред.
Ассортимент компьютерных устройств в окружающей человека среде быстро расширяется, а их число непрерывно возрастает. Компьютеры теперь не обязательно стоят на рабочих столах или запираются в серверных помещениях. PDA, мобильные планшетные компьютеры и ноутбуки, карманные компьютеры и мобильные телефоны теперь представляют собой мощные платформы, способные поддерживать новые приложения и сервисы. Однако эти устройства являются только вершиной айсберга. От нашего взора скрывается много компьютерных и сетевых элементов, требуемых для поддержки инфраструктуры, которая обеспечивает возможность всепроникающего компьютинга (ubiquitous computing).
На основе использования таких вычислительных мощностей, перемещаемых в портфелях или карманах, разработчики создают приложения, которые были невозможны всего несколько лет назад. К доступным сегодня интересным сервисам относятся передача текстовых и мультимедийных сообщений, поиск и информационные услуги с учетом местоположения (например, просмотр информации о находящихся поблизости ресторанах) и сетевые игры. Конечно, в течение нескольких следующих лет будут разработаны новые виды мобильных и персонализируемых сервисов, суть которых сегодня невозможно предсказать.
Хотя во многих важных отношениях эти сервисы существенно различаются, у них присутствуют некоторые важные общие свойства. Одним из них – и именно ему, главным образом, посвящена эта статья – является потребность в функциональных возможностях хранения и выборки данных, встраиваемых в приложение. Приложения, ориентированные на поддержку сообщений, нуждаются в надежной передаче сообщений по сети с гарантией доставки. Для сервисов, основанных на учете местоположения, требуются средства отображения физических координат местоположения в логические координаты (например, отображения координат GPS или телефонной базовой станции в почтовый код) и поиска соответствующей информации. Для игровых приложений требуется регистрация и совместное использование текущего состояния игры на распределенных устройствах и управление выборкой и доставкой игрового контента на каждое из устройств в реальном времени. Во всех этих случаях критичной является возможность быстрого сохранения и выборки данных.
Как только речь заходит о хранении и выборке данных, на ум приходят реляционные базы данных. В течение последних трех десятков лет реляционные базы данных имели огромный успех, и SQL стал lingua franca доступа к данным. Однако, хотя термин управление данными стал почти синонимом РСУБД, имеется возрастающее число приложений, для которых больше подходят облегченные альтернативы.
Мы начнем эту статью с краткого обсуждения того, как реляционным системам удалось так возвыситься на ландшафте управления данными, а затем обсудим эволюцию реляционных технологий, представим обзор появляющихся сегодня приложений с позиций управления данными и исследуем потребности в средствах управления данными сегодняшних и завтрашних приложений.
Реляционные базы данных появились в результате исследований, выполнявшихся в IBM и Калифорнийском университете в Беркли в 1970-е гг. По существу, появление технологии реляционных баз данных было реакцией на возрастающую стоимость внедрения и поддержки сложных систем.
Ключевое наблюдение состояло в том, что очень дорогостоящие программисты были вынуждены вручную переписывать большие части прикладного программного обеспечения при каждом изменении содержимого или физической организации базы данных. Поскольку, вообще говоря, приложение опиралось на детальные знания о том, как хранятся данные, включая их размещение на дисках, реорганизация баз данных или добавление новой информации в существующие базы данных вынуждало производить массовые изменения кода, осуществляющего доступ к этим базам данных.
В реляционных базах данных эта проблема решалась двумя способами. Во-первых, физическая организация базы данных скрывалась от приложения, которому предоставлялось только логическое представление данных. Во-вторых, для доступа к требуемым данным формулировались запросы на декларативном языке, и программист больше не принуждался к написанию последовательности вызовов функций для выборки данных. Эти два изменения позволяли программистам описывать нужную им информацию и перекладывать оптимизацию доступа к данным на систему управления базами данных. В результате программисты были освобождены от бремени переписывания кода приложения при каждом изменении физического расположения или организации базы данных.
Реляционные базы данных пользовались огромным успехом в IT-компаниях и центрах данных всего мира. Компании, которые обладали большими объемами данных и сложными приложениями, использующими эти данные, быстро признали новую технологию. Потребность в реляционных продуктах привела к созданию рынка с ежегодным доходом от продажи лицензий в миллиарды долларов. В 1980-е гг. появилось несколько поставщиков РСУБД, конкурирующих за этот выгодный бизнес.
За 20 прошедших лет возникли две взаимосвязанные тенденции. Во-первых, поставщики РСУБД наращивали функциональные возможности своих систем, чтобы обеспечить их отличительные качества на рынке, а также быть в состоянии претендовать на любую новую рыночную нишу. Во-вторых, лишь немногим приложениям требуются все средства, доступные в сегодняшних РСУБД, так что, по мере расширения набора предлагаемых возможностей, в каждом приложении использовалась все меньшая доля этих возможностей.
Это стремление к наращиванию функциональных возможностей РСУБД сопровождалось повышением сложности, и для большинства внедрений этих систем для поддержки работоспособности систем и приложений теперь требовался специалист, подготовленный в области администрирования баз данных. Поскольку такие систем разрабатываются и продаются как монолитные объекты, при каждой установке приходится платить за их общую сложность. Несомненно, должен иметься более подходящий выход из положения.
Мы не первые отмечаем эти потребности в переменах. В 1988 г. ведущие исследователи в области баз данных пришли к соглашению, что системы управления базами данных стали слишком сложными, и что стало важно обеспечить средства автоматического конфигурирования и администрирования (http://citforum.ru/database/digest/asil_01.shtml). Два года спустя Сураджит Чаудхари (Surajit Chaudhuri) и Герхард Вейкум (Gerhard Weikum) предложили радикальный пересмотр архитектуры систем управления базами данных. Они полагали, что системы управления базами данных должны делаться более модульными, и что нам нужно расширить свои представления об управлении данными для учета возможности использования упрощенных, компонентных строительных блоков. Позднее к этому хору присоединился Майкл Стоунбрейкер (Michael Stonebraker), утверждавший, что «один размер всем не годится», и приводивший примеры приложений, для которых не подходит традиционная архитектура РСУБД.
Как говорил Стоунбрейкер, поставщики реляционных систем поддерживают иллюзию того, что РСУБД является ответом на потребности любого приложения, связанного с управлением данными. Например, когда хранилища данных и системы поддержки принятия решений стали важными прикладными областями, поставщики адаптировали свои продукты к потребностям, возникшим в этих новых областях. Они обеспечивают новые возможности поверх не слишком пригодных для этого реализаций систем управления данных, которые ориентированы на поддержку знакомого всем языка SQL. Однако эта модель рушится, когда кто-нибудь начинает более глубоко анализировать возникающие потребности.Ниже приводится список некоторых новых проблем, возникающих в области управления данными. При анализе этих примеров нашей целью является получение некоторых классов возникающих приложений, для которых применение традиционных подходов к управлению данными не является оптимальным.
В организациях розничной торговли теперь имеется возможность фиксировать каждую транзакцию клиента, производя гигантский источник данных, который можно «раскапывать» для извлечения информации о структурах покупок клиентов, тенденциях к повышению или понижению популярности продуктов, географических предпочтениях и бесчисленных других феноменах, которые можно использовать для увеличения объема продаж и сокращения расходов на поддержку бизнеса. Такая база данных в основном используется для чтения: она обновляется массовым образом путем периодического добавления в коллекцию новых транзакций, но над ней часто выполняются операции выборки, когда аналитик отбирает данные, извлекая из базы данных полезные «лакомые кусочки». Эта прикладная область характеризуется наличием огромных таблиц (десятки и даже сотни терабайт), запросов, обращающихся только к нескольким из многочисленных столбцов таблицы и потребности в просмотре таблицы в различных порядках сортировки.
По мере того как организации становятся все в большей степени зависимыми от распределенных ресурсов и персонала, резко возрастает потребность в службах каталогов. Службы каталогов обеспечивают быстрый поиск объектов, размещенных в некоторой иерархической структуре, которая часто соответствует иерархической структуре организации. В 1990-х гг. в противовес тяжеловесному стандарту службы каталогов ISO X.400/X.500 появился стандарт LDAP. В настоящее время именно на LDAP основываются системы управления аутентификацией и идентификационной информацией от ряда поставщиков (например, Directory Server в системе Tivoli компании IBM, Active Directory Server компании Active Directory Server и Sun ONE Directory Server). Подобно хранилищам данных, LDAP характеризуется обращением к данным в основном по чтению. Запросы сводятся либо к выборке одной строки (найти запись, соответствующую данному пользователю), либо к поиску на основе значений атрибутов (найти всех пользователей, относящихся к техническому отделу). Распространенность многозначных атрибутов приводит к неэффективности использования реляционного представления.
Поисковые машины Internet относятся к пересечению областей управления базами данных и информационного поиска. Объекты, над которыми они оперируют, обычно являются полуструктурированными (т.е. это HTML, а не сплошной текст), но обрабатываемые ими запросы в большинстве случаев сводятся к поиску по ключевым словам, когда требуемым результатом является отсортированный список возможных ответов. Сегодня практически для всех успешных поисковых машин разработаны собственные средства управления данными, решающие эту проблему путем построения эффективных инвертированных индексных структур и реализации массивно-параллельного доступа к индексам и поиска. Это приложение также относится к числу тех, которые в основном читают данные и периодически производят их массовое обновление; кроме того, в них используется нетрадиционная индексация.
Распространенность небольших мобильных устройств приводит к появлению еще одной категории приложений: кэшированию уместных частей крупных наборов данных в небольшом устройстве с ограниченными функциональными возможностями. Хотя сегодняшние пользователи считают записную книжку в своем мобильном телефоне собственной коллекцией данных, можно было бы относиться к ней как к кэшу глобального телефонного и адресного справочника. У этой модели имеются привлекательные свойства – в частности, возможность добавления к локальному набору данных используемых или требуемых записей. В инфраструктуре мобильной телефонии аналогичные возможности кэширования требуются для поддержки коммуникационных каналов к устройствам. Доступ к данным в таких кэшах производится, в основном, по чтению, и сами данные являются полностью временными; они могут быть утрачены и, при необходимости, восстановлены.
Онлайновые транзакции все чаще производятся путем обмена документами, представленными в формате XML. Сегодняшнее стандартное решение заключается в преобразовании этих документов к канонической реляционной организации, сохранении их в базе данных, управляемой РСУБД, и обратном преобразовании при потребности их повторного использования. По мере возрастания числа создаваемых, передаваемых и обрабатываемых XML-документов эти преобразования становятся излишними, неэффективными и трудоемкими. Безусловно, должен иметься лучший выход из положения. Естественные (native) хранилища XML-данных, в которых поддерживается доступ на основе языков XQuery и XPath, представляют следующий этап эволюции технологии хранения данных. Хотя в репозитории XML постоянно происходит добавление и удаление элементов, сами документы в основном только читаются.
Обработка потоковых данных – это нечто вроде изгоя в нашем черновом списке приложений, требующих обработки большого объема данных. Строго говоря, обработка потоков данных не является задачей управления данными; это задача фильтрации данных, т.е. данные производятся в некотором источнике и потоковым образом посылаются получателям, которые отфильтровывают поток на предмет обнаружения «интересных» событий. Например, финансовые организации отслеживают символы акций для определения того, какие акции наиболее хорошо продаются и покупаются, а какими из них обмениваются не так интенсивно, как ожидалось.
Причина, по которой эти приложения потоковой обработки данных включены в наш список, является лингвистической: фильтры, которые обычно требуются в этих средах, выглядят подобно SQL; однако, в то время как SQL предназначался для работы с постоянно хранимыми таблицами, эти запросы выполняются над потоком значений данных, поступающих в реальном времени. Стоунбрейкер довольно глубоко разъясняет, насколько плохо для решения этой задачи подходят системы баз данных. Возможно, более удивительно не то, что системы баз данных плохо подходят для решения этой задачи, а то, что, поскольку SQL показал себя «правильным» языком запросов, разработчики используют системы реляционных баз данных для приложений, в которых отсутствует постоянное хранение данных!
Потоковая обработка данных представляет собой класс приложений, которые могут выиграть от использования подобного языка запросов поверх системы управления данными со свойствами, радикально отличающимися от свойств РСУБД . Поскольку потоковые запросы обычно выполняются над данными, наблюдаемыми в течении некоторого временного окна, требуется некоторое временное локальное хранилище данных, но от это хранилище не обязано обладать свойствами персистентности, транзакционности, а также поддержки выполнения сложных запросов. Реляционные базы данных хорошо приспособлены для обработки динамических запросов над сравнительно статическими или медленно изменяемыми данными, а этот класс приложений характеризуется довольно статическим набором запросов над весьма динамическими данными.
Реляционные системы разрабатывались для удовлетворения требований OLTP (online transaction processing, оперативная обработка транзакций), рабочей нагрузки, характеризуемой наличием непредусмотренных запросов, существенного трафика записи, а также для гарантированного обеспечения транзакционности и целостности. В отличие от этого, в почти всех перечисленных выше приложениях доминирует доступ к базе данных по чтению, а в потоковых приложениях даже не используются персистентные данные, а лишь применяется SQL-подобный язык. Лишь в немногих приложениях требуются транзакционные гарантии, и в данных, к которым требуется доступ, по существу, присутствует мало реляционных черт. Таким образом, перед сообществом управления данными встает вопрос: как наилучшим образом удовлетворить потребности этих разных типов приложений? Как утверждает Стоунбрейкер, на этот вопрос невозможно предоставить единственный верный ответ. Вместо этого нам необходимо сосредоточиться на гибких решениях, которые можно приспосабливать к потребностям конкретного приложения.
Имеется несколько способов обеспечения гибкости в сегодняшней изменяющейся среде данных. При использовании подхода, предполагающего возврат к исходным принципам, для каждого отдельного приложения создается собственная служба хранения данных. Этот простой подход практически пригоден только для простейших приложений. Однако некоторые функционирующие сегодня приложения, требующие интенсивной обработки данных, основываются на подобных простых, доморощенных решениях.
Второй подход к удовлетворению потребности в гибкости состоит в обеспечении «шведского стола» вариантов управления данными, каждый из которых адресован к некоторому классу приложений. Мы видим, как этот подход проявляется на традиционном рынке реляционных систем, где за облицовкой SQL скрываются разные возможности, требуемые для OLTP и хранилищ данных.
Третий подход к обеспечению гибкости состоит в создании более конфигурируемого средства хранения, которое может настраиваться в соответствии с потребностями индивидуальных приложений. Это решение позволяет сконцентрировать инвестиции на одной системе хранения, что способствует достижению ее более высокого качества. Однако наличие свойства конфигурируемости ставит новые требования перед разработчиками, использующими базу данных, поскольку они должны хорошо понять опции конфигурирования, а затем правильно интегрировать компонент управления данными в свои разработки.
На самом деле, решение, появляющееся на рынке, состоит в том, чтобы иметь небольшое количество умеренно конфигурируемых систем хранения, каждая из которых полезна для некоторого широкого класса приложений.
По существу, имеется два свойства, которыми должно обладать такое решение, отвечающее возникающим сегодня потребностям широкого класса приложений: модульность и конфигурируемость. Лишь для немногих приложений требуются все функциональные возможности какой-либо системы управления данными. Если некоторому приложению не нужна какая-то возможность, оно не должно «расплачиваться» на нее своим размером (объемом занимаемой основной памяти, использованием дисковой памяти и т.д.), сложностью и стоимостью. Следовательно, гибкое программное средство должно позволять разработчику использовать или исключать основные подсистемы в зависимости от того, требуются ли они приложению. Если система является достаточно модульной, чтобы при ее использовании размер приложения увеличивался незначительно, то она будет внедряться на множестве аппаратных платформ с потрясающе большими различиями в возможностях. В этих случаях система должна обладать свойством конфигурируемости под свою операционную среду: конкретную аппаратуру, операционную систему и использующее ее приложение. В оставшейся части статьи мы обсудим эти два свойства более подробно.
Некоторые люди утверждают, что архитектура баз данных нуждается в революции, схожей с RISC-революцией в архитектуре компьютеров. Традиционная монолитная архитектура СУБД не является достаточно гибкой для адаптации к сегодняшним требованиям, поэтому нам требуется создавать средства управления данными из набора небольших, простых, повторно используемых компонентов. Например, вместо того чтобы относиться к SQL как к единственной возможности выбора, Чаудхари и Вейкум утверждают, что возможности запросов должны обеспечиваться на разных уровнях сложности. Можно начать с процессора выборки из одной таблицы, имеющего индекс в виде B+-дерева и поддерживающего простые возможности индексирования, модификации и выборки. Можно добавить к этому процессору средства управления транзакциями. Продолжая подниматься по иерархии сложности, можно перейти к процессору выборки-проецирования-соединения. Потом можно добавить к нему поддержку агрегатов. Таким образом, вы преобразуете SQL из монолитного языка в семейство языков с последовательно увеличивающейся мощностью, причем каждый из этих языков представляется как некоторый компонент, удовлетворяющий потребности достаточно большого числа прикладных областей. Для любого конкретного приложения выбираются те компоненты, которые для него требуются. Эта идея компонентной архитектуры может быть расширена для включения других аспектов архитектуры систем баз данных: управления параллелизмом, транзакций, журнализации и обеспечения высокого уровня доступности.
Подсистему управления параллелизмом можно представить в виде иерархии, похожей на ту, которая обсуждалась в примере с языком запросов. Некоторые приложения являются полностью последовательными, и для них не требуются блокировки; у других приложений имеется низкий уровень параллелизма, и для них достаточно обеспечить блокировки на уровне таблиц или API (т.е. разрешить доступ к системе баз данных только одному изменяющему процессу или нескольким читающим процессам). Наконец, приложения с высоким уровнем параллелизма нуждаются в мелкоструктурных блокировках и нескольких уровнях изоляции (когда у приложений имеется потенциальная возможность видеть значения, записанные незавершенными транзакциями). В традиционной системе управления базами данных наличие блокировок само собой разумеется; в отважном новом мире, обсуждаемом в этой статье, блокировки необязательны, и можно использовать различные компоненты для обеспечения разных уровней параллелизма.
Транзакции обеспечивают иллюзию того, что набор операций применяется к базе данных в виде некоторого атомарного блока, и что результаты этих операций будут сохранены в базе данных, несмотря на сбой приложения или системы. Управление транзакциями лежит в основе большинства систем управления базами данных, хотя для многих приложений транзакции не требуются. В мире, основанном на компонентах, и транзакции должны стать необязательными. Для удовлетворения потенциальной потребности в поддержке транзакций в системе должен иметься ряд различных компонентов, обеспечивающих базисные транзакционные механизмы; точки сохранения (возможность указать точку во времени, к которой можно откатить базу данных); двухфазную фиксацию для поддержки транзакций, охватывающих несколько баз данных; вложенные транзакции для декомпозиции крупной операции в набор более мелких операций; компенсирующие транзакции для аннулирования результатов высокоуровневых логических операций.
Во многих транзакционных системах используется какая-либо разновидность журнализации для обеспечения возможностей отката и восстановления. В этом контексте едва ли кажется необходимым представлять журнализацию как отдельный компонент, но это все-таки требуется. Компонент управления транзакциями может быть сконструирован в расчете на работу в нескольких реализациях, в некоторых из которых журнализация не используется (например, вместо нее применяется механизм теневых страниц). Возможно, еще более интересно то, что система журнализации может оказаться полезной вне контекста транзакций; она может использоваться для аудита или обеспечения некоторой разновидности резервного копирования. В любом случае принимать решение о том, требуется ли в данном приложении журнализация, должен разработчик приложения, а не поставщик базы данных.
Наконец, иногда данные являются настолько критичными, что простои системы неприемлемы. Во многих системах баз данных для удовлетворения этой потребности обеспечиваются реплицированные системы или системы с высоким уровнем доступности. Хотя эта функциональная возможность в сегодняшних системах часто предоставляется в виде некоторой пристройки, их разработчики не идут достаточно далеко. Разработчику может понадобиться использовать некоторую базу данных в конфигурации HA (high-availability), но использовать ее в соединении с основой HA некоторой другой компании. Если в приложении уже имеется некоторая такая основа, поддерживающая протоколы обмена контрольными сообщениями (heartbeat protocol) (или какой либо другой механизм, позволяющий оповестить приложение или систему об отказе компонента), перехваты управления при отказах (fail-over) и резервные коммуникационные каналы, то разработчик может пожелать исключить соответствующие компоненты из системы управления базами данных и привязаться к существующим функциональным возможностям. Монолитные системы сделать это не позволяют, а в модульной архитектуре, основанной на компонентах, это вполне возможно.
Кроме обеспечения возможности создавать меньшие по размерам, более простые приложения, компоненты с правильно определенными, точными, открытыми интерфейсами обеспечивают возможность расширяемости, которую просто нереально получить в монолитных системах. Например, рассмотрим базовый набор компонентов, требуемых для построения транзакционной системы: менеджер транзакций, менеджер блокировок и менеджер журнала. Если эти модули являются открытыми и расширяемыми, то разработчик может придавать свойства транзакционности различным системам, включающим элементы, не управляемые системой баз данных. Возьмем, к примеру, сетевой коммутатор: состояние базы данных конфигурации зависит от состояния аппаратуры внутри устройства и наоборот. Если электрическое управление микросхемами и платами можно включить в транзакции, позволяя программисту расширить систему блокировок и журнализации для общения с ними, то такие операции, как «включить питание резервной карты интерфейса сети», можно сделать транзакционными.
Модульность – это мощное средство управления размером и сложностью приложений и систем, обеспечивающее, в то же время, возможность бесшовного взаимодействия функциональных компонентов приложения и системы управления данными. Этот тип архитектуры позволяет разработчикам исключать ненужные функциональные возможности и включать требуемые функциональные возможности, которые не предоставляются поставщиком базы данных.
Вторым свойством гибкой системы управления данными является конфигурируемость. В то время как модульность представляет собой архитектурный механизм, конфигурирование – это, главным образом, механизм времени выполнения. При использовании компонентной архитектуры конфигурирование времени сборки состоит в выборе подходящих компонентов. Один и тот же набор компонентов может выполняться в ряде систем с очень разными возможностями. Например, то, что для некоторых двух приложений требуются транзакции и B-деревья, вовсе не означает, что оба они могут сохранять в кэше основной памяти несколько гигабайт данных. Критичной является возможность адаптации к радикально различным условиям. Показатель конфигурируемости характеризует возможность системы соответствовать своей среде и потребностям приложений. В этой статье мы обсуждаем конфигурируемость по отношению к аппаратуре, среде, в которой выполняется приложение (например, операционной системе), архитектуре программного обеспечения приложения и «естественному» формату данных приложения.
Разным аппаратным средам свойственны различные соотношения скорости ЦП, размеров памяти и возможностей внешней памяти. При наличии сред с разными соотношениями скорости процессора и пропускной способности дисковой подсистемы можно компенсировать одни показатели за счет других. При использовании быстрого процессора может оказаться выгодно сжимать данные, потребляя для этого время процессора, чтобы сэкономить на вводе-выводе; на PDA, в котором используется процессор с низкой тактовой частотой, а внешняя память является быстрой, компрессия не является правильным компромиссным решением.
В мире, где для устройств с ограниченными ресурсами требуется потенциально усложненное управление данными, у разработчиков должен иметься контроль над политиками базы данных потребления ресурсов основной и дисковой памяти. В разных средах приложениям может понадобиться контролировать максимальный размер структур данных, располагаемых в основной памяти, максимальный размер постоянно хранимых данных и объем дисковой памяти, расходуемой под журналы транзакций. Политики потребления этих ресурсов должны устанавливаться разработчиками приложений, а не конечными пользователями, поскольку у разработчика более вероятно имеется техническая смекалка, необходимая для принятия правильных решений.
Новые требования к системе баз данных возникают и по причине наличия различных технологий персистентной памяти. Система должна хорошо работать не только при наличии магнитных дисков, но и при использовании других носителей (например, флэш-память) с учетом их ограничений (таких как число записей в конкретную область памяти), а при необходимости и в условиях отсутствия какой бы то ни было персистентной памяти. Некоторым приложениям требуется управление данными полностью в основной памяти без какой-либо персистентности; другим приложениям требуется управление данными с поддержкой гарантированной полностью синхронной транзакционности; для третьих приложений требуется что-то среднее между этими крайностями. Каждая из этих политик должна реализовываться одним и тем же компонентом поддержки транзакций, но система баз данных должна позволять программисту управлять тем, должны ли сохраняться данные после выключения питания, и какова должна быть строгость транзакционных гарантий, обеспечиваемых системой для конечного пользователя.
Хотя во многих встроенных системах теперь можно использовать аппаратные платформы категории COTS (commercial off-the-shelf hardware), все еще существует много проприетарных устройств. Для вездесущего решения управления данными должна иметься возможность переноса на эти специализированные аппаратные устройства. Должна также иметься возможность его переноса в среды разнообразных операционных систем; ресурсы, которые можно получить от операционной системы мобильного телефона, отличаются от ресурсов, имеющихся в распоряжении операционной системы, которая выполняется на компьютере с 64-разрядным процессором и несколькими гигабайтами основной памяти, хотя в обоих случаях может использоваться Linux. Если система управления данными должна запускаться на чем угодно, то она должна полагаться только на службы, присутствующие в большинстве операционных систем, и в ней должны обеспечиваться явные механизмы поддержки переносимости за счет использования промежуточных библиотек или доступности исходного текста программ.
Даже на одной платформе у разработчика имеется возможность выбора архитектурных деталей, влияющих на систему баз данных. Например, систему можно построить с использованием одного потока управления; набора взаимодействующих процессов, в каждом из которых имеется один поток управления; нескольких потоков управления в одном процессе; нескольких процессов, в каждом из которых имеется несколько потоков управления; или архитектуры, строго основанной на событиях.
При разработке системы баз данных следует избегать принятия решений по поводу сетевых протоколов. Поскольку система баз данных будет использоваться как в средах, в которых коммуникации обеспечиваются на основе объединительных плат (backplane), так и в средах, где основой коммуникаций является WAN (Wide Area Network), подходящую коммуникационную инфраструктуру должен выбирать разработчик. В специализированном блоке коммутатора мобильного телефона может поддерживаться специальная объединительная плата и протокол быстрых коммуникаций с резервными платами; система баз данных не должна препятствовать использованию этих коммуникационных механизмов разработчиком.
До сих пор мы обсуждали аспекты конфигурируемости, относящиеся к адаптации системы баз данных к аппаратной и программной среде приложения. Последняя область конфигурирования, которую мы затронем в этой статье, затрагивает данные приложения. Размещение данных, индексация и доступ к ним являются важными факторами эффективности. По отношению к данным имеются три основные проектные характеристики: физическая кластеризация, механизм индексации и внутренние структуры базы данных. Выбор некоторых из них, таких как механизм индексации, в действительности происходит при конфигурировании системы во время выполнения, но по поводу других характеристик разработчик может принимать решения во время проектирования приложения, причем эти решения не навязываются системой управления базами данных.
В системах управления базами данных, разработанных в расчете на использование вращающихся магнитных носителей внешней памяти, тратятся значительные усилия на кластеризацию на диске взаимосвязанных данных, чтобы можно было амортизировать время подвода магнитных головок и прокручивания диска передачей большого объема данных. Вообще говоря, кластеризация является хорошим приемом, если только данные кластеризуются в соответствии с «правильным» критерием. В случае конфигурируемой системы баз данных это означает, что у разработчика должны иметься возможности управления выбором первичного ключа (как это и делается в большинстве систем управления реляционными базами данных) и игнорирования аспектов кластеризации, если носители персистентных данных отсутствуют или если доступ к области внешней памяти, «близкой» к той, к которой производился предыдущий доступ, не обеспечивает выигрыша в производительности.
В связи с этим также заметим, что у разработчика должна иметься возможность выбора индексной структуры для поддержки первичного ключа, соответствующей ожидаемой рабочей нагрузке. Для рабочей нагрузки, в которой соблюдается локальность ссылок, вероятно, хорошо подойдут B+-деревья; для рабочих нагрузок с громадными наборами данных и случайными ссылками более подходящими могут оказаться хэш-таблицы. Приложению могут потребоваться многомерные данные, для работы с которыми нужны совсем другие индексные структуры; обсуждавшиеся ранее возможности расширений должны позволить разработчику обеспечить специализированный механизм индексации и использовать его наравне с другими средствами системы (например, механизмами блокировок, транзакций и т.д.). Как минимум, в конфигурируемой базе данных должен обеспечиваться набор альтернативных индексных структур, поддерживающих последовательный просмотр, быстрый поиск по значению ключа и поиск по диапазону значений ключа, включая поиск по частичному значению ключа.
В отличие от случая использования РСУБД, у программиста должна иметься возможность определения внутренней структуры элементов данных, с которыми работает конфигурируемая система. Если приложение имеет дело с динамической или развивающейся схемой базы данных, или если в нем должны поддерживаться непредвиденные запросы, то внутренняя структура базы данных должна допускать доступ на основе высокоуровневых запросов с использованием средств SQL, XPath, XQuery, LDAP и т.д. Однако если схема базы данных является статической, и набор запросов известен заранее, то существенный выигрыш в производительности обеспечивается при выборе внутренней структуры, которая более естественно отображается во внутренние структуры данных приложения. Например, если данные приложений являются, по сути, не реляционными (например, содержат многозначные атрибуты или большие порции неструктурированных данных), то насильственное их приведение к реляционной форме только для обеспечения доступа на основе SQL приведет к появлению накладных расходов на эти преобразования и вряд ли позволит извлечь выгоду из реляционного хранения данных. Аналогично, если бы данные приложения были по своей сути реляционными, то насильственное приведение их к другому формату (например, XML или объектно-ориентированное представление) привело бы только к новым накладным расходам без получения каких-либо преимуществ. В конфигурируемой системе баз данных должно поддерживаться хранение данных в формате, наиболее естественном для приложения. За выбор формата, отвечающего критерию «наибольшей естественности», должен отвечать программист.
Системы баз данных старого типа позволяют решать проблемы старого типа; нам требуются базы данных нового типа для решения нового типа проблем. Хотя потребность в традиционных системах управления базами данных не исчезает, для решения многих сегодняшних проблем требуются конфигурируемые системы баз данных. Даже не глядя в магический кристалл, кажется ясным, что для завтрашних систем также потребуется существенный уровень конфигурируемости. Будучи программистами и инженерами, мы учимся выбирать правильные инструменты для выполнения своей работы; выбор базы данных не является исключением. Нам требуются такие условия работы, в которых имеются понимаемые нами варианты средств управления данными, и мы должны выбирать правильные инструментальные средства, чтобы выполнить работу настолько эффективным, надежным и простым образом, насколько это возможно.
1.Codd, E. F. 1970. A relational model of data for large shared data banks. Communications of the ACM 13(6): 377-387.
2.Astrahan, M. M., et al. 1976. System R: Relational approach to database management. ACM Transactions on Database Systems 1(2): 97-137.
3. Stonebraker, M. 1976. The design and implementation of Ingres. ACM Transactions on Database Systems 1(3): 189-222.
4. Bernstein, P., et al. 1998. The Asilomar report on database research. ACM SIGMOD Record 27(4).
5. Chaudhuri, S., and Weikum, G. 2000. Rethinking database system architecture: Towards a self-tuning RISC-style database system. The VLDB Journal: 1-10.
6. Stonebraker, M., and Cetintemel, U. 2005. One size fits all: An idea whose time has come and gone. Proceedings of the 2005 International Conference on Data Engineering (April).
7. Broussard, F. 2004. Worldwide IT asset management software forecast and analysis, 2002-2007. IDC Doc. #30277.
8. Gray, J., and Reuter, A. 1993. Transaction Processing: Concepts and Technologies, 397-402. San Mateo, CA: Morgan Kaufman Publishers.