Стратегические направления в системах баз данных

А.Зильбершац, С.Здоник
Перевод: М.Р. Когаловский

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

5. Препятствия

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

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

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

5.1. Накладные расходы

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

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

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

5.2. Масштаб

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

На другом конце спектра объем данных в будущих приложениях может быть на много порядков выше, чем тот, с которым обычно имеют дело сегодня приложения баз данных. Если мы собираемся помещать информацию в Internet, мы должны быть готовыми, по крайней мере, концептуально к тому, чтобы управлять многими петабайтами данных. Объем этих данных растет с непредсказуемой скоростью, над которой мы не имеем никакого контроля.

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

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

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

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

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

5.3. Организация схемы

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

Теперь все более часто придется сталкиваться с ситуацией, когда мы не будем иметь такой роскоши, как априорная схема. В настоящее время многие приложения создают данные независимо от какой-либо системы базы данных⁷ (например, научные приложения), и поскольку информация получается более легким путем для сбора, передачи и хранения, такое несоответствие будет только усиливаться. По этой причине возникает необходимость отображения в схему (и, возможно, в новые структуры хранения) данных, сгенерированных вне системы, пост-фактум. Этот подход "снизу-вверх" к наполнению баз данных не часто поддерживается в современных системах.

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

Может оказаться, что данные, получаемые из какого-либо источника, например, из узла Web, имеют некоторую структуру. Фрагменты текста кодируются тегами, описывающими их роли. К сожалению, использование этих тегов может в значительной степени варьироваться. Тот факт, что на какой-либо одной странице используется тег H3 для заголовков, совсем не обязательно имеет силу для других страниц, и может быть даже из того же самого сайта. Такая вариация в использовании кодировки текстов затрудняет конструирование чего-либо такого, что мы могли бы понимать как схему, которая описывает как Web-страницы.

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

5.4. Качество данных

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

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

5.5. Неоднородность

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

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

Хотя проводилось довольно много исследований, посвященных интеграции данных из неоднородных источников и операциям над ними, программные продукты с такими возможностями только начинают появляться. Нам представляется, что доминирующим подходом является управление распределенными объектами, которое обеспечивается продуктами, поддерживающими CORBA, SOM И OLE. Каждый из этих подходов предоставляет некоторую объектно-ориентированную модель, на которой базируется общий язык описания интерфейсов распределенных объектов.

Хотя эти стандарты и поддерживающие их системы прошли долгий путь в интеграции различных систем программного обеспечения, они лучше всего подходят для обеспечения унифицированных синтаксических интерфейсов новых или существующих приложений. Эти подходы обеспечивают общий протокол для передачи сообщений между объектами в распределенной среде, однако в них не предпринимается попыток решить трудную проблему разрешения семантических противоречий. Они не могут быть также использованы для интеграции или создания унифицированных данных из различныхисточников. В общем, усложненный инструментарий для работы с неоднородными данными должен, тем не менее, являться надстройкой над интерфейсами CORBA, SOM или OLE.

5.6. Сложность запросов

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

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

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

Если мы рассмотрим, например, сценарий персональных информационных систем, то обнаружим потребность в более гибких методах оптимизации запросов, в которых будут приниматься во внимание изменения в стоимости широковещательной среды (например, основанной на радио или сотовых коммуникациях) при перемещении PID. Степень детализации или точности, обеспечиваемая сервером, может основываться на величине той суммы, которую желает платить данное лицо. Таким образом, в моделях оптимизации должны приниматься во внимание не только формулировки запросов, но также и описание целей оптимизации. Эти цели могли бы выражаться в терминах расхода ресурсов (например, оптимизировать по критерию минимизации затрат памяти и максимизации использования сети) или в виде ограничений на исполнение, основанных на точности ответа или допустимого расхода ресурсов ⁸.

5.7. Простота использования

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

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

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

5.8. Безопасность

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

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

Вторая трудность вытекает из того факта, что "элементы данных" гипертекстового документа не являются такими систематически структурированными, как данные в системах управления базами данных. Как отмечалось ранее (подразд. 5.3), не имеется также и эквивалента "схемы базы данных". В связи с этим администрирование санкционированием доступа становится более трудным.

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

5.9. Гарантирование допустимых последствий

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

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

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

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

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

5.10. Внедрение технологий

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

---

⁶⁾ Не следует здесь понимать авторов буквально. Схема базы данных вовсе не предоставляет никакого интерфейса. Она является дескриптивным компонентом системы базы данных и используется средствами системных интерфейсов для интерпретации. – Прим. пер.

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

⁸⁾ Обратим внимание на допущенную авторами неточность. Спецификация цели (критерия) является необходимым компонентом постановки задачи на оптимизацию. При этом, естественно, могут задаваться и какие-либо ограничения. Однако ограничения никаким образом не являются выражением цели оптимизации, а выполняют функцию задания области поиска оптимума. – Прим. пер.

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