ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 406
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
только такой уровень прозрачности распределенности, была приемлема для конечного пользователя.
Прямым следствием обсуждавшихся выше вариантов прозрачности распределенности является требование наличия прозрачности именования. Как и в случае централизованной базы данных, каждый элемент распределенной базы данных должен иметь уникальное имя. Следовательно, СУРБД должна гарантировать, что никакие два сайта системы не смогут создать некоторый объект базы данных, имеющий одно и то же имя.
Одним из вариантов решения этой проблемы является создание центрального сервера имен, который будет нести ответственность за полную уникальность всех существующих в системе имен. Однако подобному подходу свойственны такие недостатки, как:
утрата определенной части локальной автономии;
появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);
снижение доступности – если центральный сайт по какой-либо причине станет недоступным, все остальные сайты системы не смогут создавать никаких новых объектов базы данных [7].
Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект [7]. Аналогичным образом, необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию. Однако подобный подход приводит к утрате прозрачности распределенности.
Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных [7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.
5.6.2. Прозрачность транзакций
Прозрачность транзакций в среде распределенных СУБД означает, что при выполнении любых распределенных транзакций гарантируется сохранение целостности и согласованности распределенной базы данных.
Распределенная транзакция осуществляет доступ к данным, сохраняемым более чем в одном местоположении. Каждая из транзакций разделяется на несколько субтранзакций – по одной для каждого сайта, к данным которого осуществляется доступ. На удаленных сайтах субтранзакции представляются агентами.
Неделимость остается фундаментальной концепцией понятия транзакции и в случае распределенных транзакций, однако дополнительно СУРБД должна гарантировать неделимость и каждой из ее субтранзакций [7]. Следовательно, СУРБД должна гарантировать не только синхронизацию субтранзакций с другими локальными транзакциями, выполняющимися параллельно с ними на одном сайте, но и обеспечить синхронизацию субтранзакций с глобальными транзакциями, выполняющимися одновременно с ними на этом и других сайтах системы. Прозрачность транзакций в распределенных
СУБД дополнительно усложняется за счет наличия фрагментации, распределения данных и использования репликации. Существуют два дополнительных аспекта прозрачности транзакций, таких как прозрачность параллельности и прозрачность отказов.
Прозрачность параллельности обеспечивается СУБРД в том случае, если результаты всех параллельно выполняемых транзакций (как распределенных, так и нераспределенных) генерируются независимо и являются логически согласующимися с результатами, которые были бы получены в том случае, если бы все эти транзакции выполнялись последовательно в некотором произвольном порядке, по одной в каждый момент времени. В случае распределенных СУБД имеют место дополнительные усложнения, связанные с необходимостью гарантировать, что как глобальные, так и локальные транзакции не могут оказывать влияния друг на друга. Кроме того, СУРБД должны гарантировать согласованность всех субтранзакций каждой глобальной транзакции.
Наличие в системе репликации еще более усложняет проблему организации параллельной обработки в системе. Если одна из копий реплицируемых данных подвергается обновлению, сведения об этом в конечном счете должны быть представлены в каждой из существующих копий. В данном случае наиболее очевидная стратегия – сделать распространение сведений об изменении частью исходной транзакции, оформив его как еще одну атомарную операцию. Однако, если один из содержащих копию измененных данных сайтов окажется в момент внесения изменения недоступным из-за отказа на самом сайте или в канале связи, то выполнение транзакции будет отложено до тех пор, пока этот сайт вновь не
116
Прямым следствием обсуждавшихся выше вариантов прозрачности распределенности является требование наличия прозрачности именования. Как и в случае централизованной базы данных, каждый элемент распределенной базы данных должен иметь уникальное имя. Следовательно, СУРБД должна гарантировать, что никакие два сайта системы не смогут создать некоторый объект базы данных, имеющий одно и то же имя.
Одним из вариантов решения этой проблемы является создание центрального сервера имен, который будет нести ответственность за полную уникальность всех существующих в системе имен. Однако подобному подходу свойственны такие недостатки, как:
утрата определенной части локальной автономии;
появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);
снижение доступности – если центральный сайт по какой-либо причине станет недоступным, все остальные сайты системы не смогут создавать никаких новых объектов базы данных [7].
Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект [7]. Аналогичным образом, необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию. Однако подобный подход приводит к утрате прозрачности распределенности.
Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных [7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.
5.6.2. Прозрачность транзакций
Прозрачность транзакций в среде распределенных СУБД означает, что при выполнении любых распределенных транзакций гарантируется сохранение целостности и согласованности распределенной базы данных.
Распределенная транзакция осуществляет доступ к данным, сохраняемым более чем в одном местоположении. Каждая из транзакций разделяется на несколько субтранзакций – по одной для каждого сайта, к данным которого осуществляется доступ. На удаленных сайтах субтранзакции представляются агентами.
Неделимость остается фундаментальной концепцией понятия транзакции и в случае распределенных транзакций, однако дополнительно СУРБД должна гарантировать неделимость и каждой из ее субтранзакций [7]. Следовательно, СУРБД должна гарантировать не только синхронизацию субтранзакций с другими локальными транзакциями, выполняющимися параллельно с ними на одном сайте, но и обеспечить синхронизацию субтранзакций с глобальными транзакциями, выполняющимися одновременно с ними на этом и других сайтах системы. Прозрачность транзакций в распределенных
СУБД дополнительно усложняется за счет наличия фрагментации, распределения данных и использования репликации. Существуют два дополнительных аспекта прозрачности транзакций, таких как прозрачность параллельности и прозрачность отказов.
Прозрачность параллельности обеспечивается СУБРД в том случае, если результаты всех параллельно выполняемых транзакций (как распределенных, так и нераспределенных) генерируются независимо и являются логически согласующимися с результатами, которые были бы получены в том случае, если бы все эти транзакции выполнялись последовательно в некотором произвольном порядке, по одной в каждый момент времени. В случае распределенных СУБД имеют место дополнительные усложнения, связанные с необходимостью гарантировать, что как глобальные, так и локальные транзакции не могут оказывать влияния друг на друга. Кроме того, СУРБД должны гарантировать согласованность всех субтранзакций каждой глобальной транзакции.
Наличие в системе репликации еще более усложняет проблему организации параллельной обработки в системе. Если одна из копий реплицируемых данных подвергается обновлению, сведения об этом в конечном счете должны быть представлены в каждой из существующих копий. В данном случае наиболее очевидная стратегия – сделать распространение сведений об изменении частью исходной транзакции, оформив его как еще одну атомарную операцию. Однако, если один из содержащих копию измененных данных сайтов окажется в момент внесения изменения недоступным из-за отказа на самом сайте или в канале связи, то выполнение транзакции будет отложено до тех пор, пока этот сайт вновь не
116
станет доступным.
Если существует большое количество копий данных, то вероятность успешного завершения транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной стратегией является ограничение распространения сведений об изменении только теми сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении поступят, как только они вновь станут доступными.
Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно, через некоторое время после внесения исходного обновления. Задержка в восстановлении целостности может варьироваться от нескольких секунд до нескольких часов [7].
Любая централизованная СУБД должна включать механизм восстановления, который в подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения транзакций – либо все операции транзакции будут завершены, либо ни одна из них. Если транзакция выполнена, внесенные ею изменения приобретают длительный характер. Среди отказов централизованных СУБД выделяют: сбои системы, отказ носителей, ошибки в программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В распределенных СУБД необходимо дополнительно учитывать следующее:
возможность потери сообщения;
возможность отказа линии связи;
аварийный останов одного из сайтов;
расчленение сетевых соединений.
СУРБД должна гарантировать атомарность глобальных транзакций, т.е. должна синхронизировать выполнение глобальной транзакции так, чтобы все ее субтранзакции были успешно завершены до финальной операции фиксации результатов глобальной транзакции.
5.6.3. Прозрачность выполнения
Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась аналогично работе в централизованной СУБД. В распределенной среде не должно быть видно снижение производительности из-за наличия медленных сетевых соединений и т.д. Прозрачность выполнения требует также, чтобы
СУРБД могла находить наиболее эффективные стратегии выполнения запросов.
В централизованной СУБД обработчик запросов оценивает каждый запрос на доступ к данным и находит оптимальную стратегию его выполнения в виде упорядоченной последовательности операций с базой данных. В распределенной среде обработчик запросов отображает запрос на доступ к данным в упорядоченную последовательность операций с локальными базами данных. При этом дополнительная сложность возникает из-за необходимости учитывать наличие фрагментации, репликации и определенной схемы размещения данных.
Обработчик распределенных запросов должен знать:
к какому фрагменту следует обратиться;
какую копию фрагмента использовать, если его данные реплицируются;
какое из местоположений должно использоваться [7].
Обработчик распределенных запросов вырабатывает стратегию выполнения, которая является оптимальной с точки зрения некоторой стоимостной функции. Обычно используются следующие показатели:
время доступа, включающее физический доступ к данным на диске;
время работы центрального процессора, затрачиваемое на обработку данных в первичной памяти;
время, необходимое для передачи данных по сетевым соединениям.
Первые два фактора аналогичны тем, которые учитываются в централизованных системах для оптимизации выполнения запросов. Но в СУРБД доминирующую роль играет время передачи данных по сетевым соединениям, что особенно актуально для глобальных сетей. Скорость передачи в таких каналах может составлять лишь несколько Кбайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют скорость передачи данных, сравнимую со скоростью доступа к дискам (в локальных сетях). В этом случае целесообразно учитывать все три указанных показателя.
117
Если существует большое количество копий данных, то вероятность успешного завершения транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной стратегией является ограничение распространения сведений об изменении только теми сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении поступят, как только они вновь станут доступными.
Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно, через некоторое время после внесения исходного обновления. Задержка в восстановлении целостности может варьироваться от нескольких секунд до нескольких часов [7].
Любая централизованная СУБД должна включать механизм восстановления, который в подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения транзакций – либо все операции транзакции будут завершены, либо ни одна из них. Если транзакция выполнена, внесенные ею изменения приобретают длительный характер. Среди отказов централизованных СУБД выделяют: сбои системы, отказ носителей, ошибки в программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В распределенных СУБД необходимо дополнительно учитывать следующее:
возможность потери сообщения;
возможность отказа линии связи;
аварийный останов одного из сайтов;
расчленение сетевых соединений.
СУРБД должна гарантировать атомарность глобальных транзакций, т.е. должна синхронизировать выполнение глобальной транзакции так, чтобы все ее субтранзакции были успешно завершены до финальной операции фиксации результатов глобальной транзакции.
5.6.3. Прозрачность выполнения
Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась аналогично работе в централизованной СУБД. В распределенной среде не должно быть видно снижение производительности из-за наличия медленных сетевых соединений и т.д. Прозрачность выполнения требует также, чтобы
СУРБД могла находить наиболее эффективные стратегии выполнения запросов.
В централизованной СУБД обработчик запросов оценивает каждый запрос на доступ к данным и находит оптимальную стратегию его выполнения в виде упорядоченной последовательности операций с базой данных. В распределенной среде обработчик запросов отображает запрос на доступ к данным в упорядоченную последовательность операций с локальными базами данных. При этом дополнительная сложность возникает из-за необходимости учитывать наличие фрагментации, репликации и определенной схемы размещения данных.
Обработчик распределенных запросов должен знать:
к какому фрагменту следует обратиться;
какую копию фрагмента использовать, если его данные реплицируются;
какое из местоположений должно использоваться [7].
Обработчик распределенных запросов вырабатывает стратегию выполнения, которая является оптимальной с точки зрения некоторой стоимостной функции. Обычно используются следующие показатели:
время доступа, включающее физический доступ к данным на диске;
время работы центрального процессора, затрачиваемое на обработку данных в первичной памяти;
время, необходимое для передачи данных по сетевым соединениям.
Первые два фактора аналогичны тем, которые учитываются в централизованных системах для оптимизации выполнения запросов. Но в СУРБД доминирующую роль играет время передачи данных по сетевым соединениям, что особенно актуально для глобальных сетей. Скорость передачи в таких каналах может составлять лишь несколько Кбайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют скорость передачи данных, сравнимую со скоростью доступа к дискам (в локальных сетях). В этом случае целесообразно учитывать все три указанных показателя.
117
1 ... 9 10 11 12 13 14 15 16 ... 20
5.6.4. Прозрачность использования
Прозрачность использования СУБД позволяет скрыть от пользователя тот факт, что на разных сайтах могут функционировать различные локальные СУБД. Данный тип прозрачности является самым сложным, и применим только для гетерогенных распределенных систем.
Таким образом, концепция прозрачности не может быть отнесена к типу «все или ничего», так как может быть организована на нескольких различных уровнях. Каждый из уровней подразумевает определенный набор соглашений между сайтами системы. Так, при полной прозрачности сайты должны следовать общему соглашению по вопросам модели данных, интерпретации схем, представления данных и т.п. В непрозрачных системах единственным соглашением является формат обмена данными и набор функциональных возможностей, предоставляемых каждым сайтом в системе.
С точки зрения конечного пользователя полная прозрачность желательна. Но с точки зрения АБД локальной базы полностью прозрачный доступ связан с трудностями осуществления контроля.
Традиционный способ работы с представлениями, используемый для построения защитного механизма, в такой ситуации может оказаться неэффективным. Например, механизм работы с представлениями языка SQL позволяет ограничивать доступ к базовым таблицам или подмножеству данных базовой таблицы и разрешать его только конкретным пользователям. Однако он не позволяет также легко ограничивать доступ к данным на основе набора критериев, отличных от имени пользователя,
Проще обеспечить подобный тип функциональности с помощью процедур, которые будут запускаться удаленным пользователем. В этом случае локальные пользователи смогут работать с данными так же, как они работали прежде, при использовании стандартного механизма защиты СУБД.
Однако удаленные пользователи смогут получать только такой тип доступа к данным, который реализован в предоставленном им наборе процедур, подобно тому, как это делается в объектно- ориентированных системах. Подобный тип федеральной архитектуры реализовать проще, чем обеспечить полную прозрачность системы
, к тому же он предоставляет более высокий уровень локальной автономности.
В приложении 7 сведены правила, при выполнении которых СУБД может считаться распределенной.
ЗАКЛЮЧЕНИЕ
Наиболее перспективные направления в развитии информационных технологий – это базы данных и сети. Следовательно, симбиоз этих концепций – применение распределенных баз данных, как основы систем искусственного интеллекта (экспертных систем), перерастание баз данных в базы знаний, доступные широким массам общества, будет определять дальнейший ход революции в электронно- вычислительной технике и информационной технологии.
Учебный материал, собранный в данном учебном пособии, в целом представляет основной спектр проблем и подходов, существующих в современней организации баз данных. Особую роль в разработке структуры и содержания учебного пособия сыграли источники [5, 7, 8, 17].
Читатель, имевший терпение прочесть данное издание, несомненно, серьезно отнесется к процессу проектирования и реализации баз данных в интересующих его предметных областях. А серьезный, научно-обоснованный подход – это подход профессионала.
Целесообразно было включить в качестве приложения краткий толковый словарь по организации баз данных. Знание единой терминологии снимает проблему «языкового барьера», способствует пониманию новых идей.
Остается пожелать успехов в применении полученных знаний в полезных предметных областях.
ПРИЛОЖЕНИЯ
Приложение 1. Недостатки файловых систем
Ограничения файловых систем, закрывающие перспективы их использования при обработке значительных объемов информации большим количеством конкурирующих пользователей следующие
[7, 11].
1. Разделение и изоляция данных.
2. Дублирование данных.
118
3. Зависимость данных.
4. Несовместимость форматов файлов.
5. Фиксированный набор запросов, быстрое увеличение количества приложений.
1. Разделение и изоляция данных
Данные изолированы в отдельных файлах, доступ к ним затруднен. Например, для создания списка всех домов, отвечающих требованиям потенциальных арендаторов, предварительно нужно создать временный файл со списком арендаторов, желающих арендовать недвижимость типа «дом». Затем в соответствующих файлах следует осуществить поиск объектов недвижимости типа «дом» с арендной платой ниже установленного арендатором максимума. Выполнять подобную обработку данных в файловых системах достаточно сложно. Для извлечения соответствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необходимо извлечь данные из более чем двух файлов.
2. Дублирование данных
Из-за децентрализованной работы с данными проводимой в каждом отделе организации независимо от других отделов, в файловой системе фактически поощряется бесконтрольное дублирование данных, что, в принципе, неизбежно. Бесконтрольное дублирование данных нежелательно по двум причинам:
1) дублирование данных сопровождается неэкономным расходованием ресурсов. Во многих случаях дублирования данных можно избежать за счет совместного использования файлов;
2) дублирование данных может привести к нарушению их целостности, данные из разных файлов могут стать противоречивыми. Поскольку не существует никакого автоматического способа обновления данных одновременно и в нескольких файлах, подобные противоречия с какой-то вероятностью будут возникать.
3. Зависимость данных
Физическая структура и способ хранения записей файлов данных жестко зафиксированы в коде программ приложений. Это значит, что изменить существующую структуру данных достаточно сложно.
Для этого придется создать одноразовую программу специального назначения, которая выполняется один раз.
Помимо этого, все обращающиеся к файлу данных программы должны быть изменены с целью соответствия новой структуре этого файла. Причем таких программ может быть очень много.
Следовательно, программист должен прежде всего выявить такие программы, а затем перепроверить их и изменить. Ясно, что выполнение всех этих действий требует больших затрат времени и может явиться причиной появления ошибок. Данная особенность файловых систем называется зависимостью от программ и данных.
4. Несовместимость форматов файлов
Поскольку структура файлов определяется кодом приложений, она также зависит от языка программирования этого приложения. Например, структура файла, созданного программой на языке
COBOL, может совершенно отличаться от структуры файла, создаваемого программой на языке С.
Прямая несовместимость таких файлов затрудняет процесс их совместной обработки.
5. Фиксированный набор запросов, быстрое увеличение количества приложений
С точки зрения пользователя возможности файловых систем намного превосходят возможности ручных картотек. Соответственно возрастают и их требования к реализации новых или модифицированных запросов. Однако файловые системы во многом зависят от программиста, потому что все требуемые запросы и отчеты должны быть созданы именно им. В результате события обычно развивались по одному из сценариев. Во многих организациях типы создаваемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или
119