Введение в системы БД (542480), страница 204
Текст из файла (страница 204)
БтАтБ 6 ьОИООИ р После выполнения этого оператора пользователь сможет с одинаковым успехом ввести любой из двух приведенных ниже операторов. яеьест ЕКОМ Бтйтя Беьест УКОМ иятАтя В первом случае, т.е. при использовании локального имени, система будет подразумевать, что все компоненты расширенного системного имени определяются по умолчанию, а именно, что объект создан данным пользователем, создан на данном узле и сохранен на данном узле.
Кстати, благодаря такому допущению по умолчанию старые приложения системы К могут выполняться без каких-либо исправлений в новой версии системы Кв (т.е. после переопределения данных системы К для системы К*; напомним, что система К была предшествующим прототипом системы К*). З В системе Вч базовые переменные-отношения физически хранятся так, как они хранятся почти ва всех известных автору системах. 784 Часть р: дополнительные аспекты Во втором случае, т.е. при использовании синонима, система для определения расширенного системного имени проанализирует соответствующую таблицу синонимов. Таблицы синонимов могут рассматриваться как первый компонент каталога.
Каждый узел поддерживает некоторый набор таких таблиц, созданных лля каждого пользователя данного узла, что позволяет системе отображать известные пользователю синонимы в соответствующие расширенные системные имена. Кроме таблиц синонимов, на каждом узле поддерживаются следующие данные. 1. Элементы каталога для каждого объекта, местом рождения которого является данный узел. 2. Элементы каталога для кажаого объекта, хранимого в данный момент на данном узле. Предположим теперь, что пользователь выдал запрос, содержащий ссылку на синоним МЯТлТБ.
Сначала система выполнит поиск соответствующего расширенного системного имени в подходящей таблице синонимов (простой локальный просмотр). После того как станет известен узел рождения (в нашем примере это узел в Лондоне), можно будет опросить каталог узла в Лондоне (здесь мы для общности подразумеваем удаленный просмотр — первое удаленное обращение). Каталог узла из Лондона будет содержать элемент для объекта в соответствии с и. 1. Если объект по-прежнему хранится на узле в Лондоне, он будет найден. Однако, если объект перемещен, скажем, на узел в ЛосАнджелесе, элемент каталога на узле в Лондоне будет содержать сведения об этом и система должна будет опросить каталог на узле в Лос-Анджелесе (второе удаленное обращение).
Каталог на узле в Лос-Анджелесе будет содержать элемент лля искомого объекта согласно п. 2. Таким образом, для поиска объекта будет выполнено не более двух удаленных обращений. Кроме того, если объект вновь потребуется переместить, скажем, на узел в СанФранциско, системой будут выполнены следующие действия. ° Вставка элемента в каталог на узле в Сан-Франциско. ° Удаление элемента каталога на узле в Лос-Анджелесе.
° Обновление элемента каталога на узле в Лондоне, который теперь будет указывать на узел в Сан-Франциско вместо узла в Лос-Анджелесе. В результате объект всегда может быть найден с помощью не более двух удаленных обращений. И это полностью распределенная схема — нет никакого узла с основным каталогом и нет никакого единого источника ошибок внутри системы. Отметим, что схема идентификации объектов, которая используется в распределенной СУБД РВ2, хотя и подобна описанной выше, не полностью совпадает с ней. Распространение обновлений Основная проблема репликации данных, как указывалось в разделе 20.3, заключается в том, что обновление любого заданного логического объекта должно распространяться на все хранимые копии этого объекта.
Сложности, которые немедленно возникают в этом случае, состоят в том, что некоторый узел, содержащий копию данного объекта, в момент обновления может оказаться недоступным, поскольку или он сам, или канал доступа находится в аварийном состоянии. Таким образом, очевидная стратегия немедлен- 785 Глава 20. Распределенные базы данных ного обновления всех существующих копий будет, вероятно, неприемлема, поскольку любая операция обновления, а значит, и вся включающая ее транзакция, закончится аварийно, если одна из требуемых копий в момент обновления окажется недоступной.
В каком-то смысле при этой стратегии данные будут менее доступны, чем при отсутствии репликации. Таким образом, исчезает одно из главных преимуществ репликации, которое указывалось в предыдущем разделе. Общая схема решения рассматриваемой проблемы (это не единственное возможное решение) состоит в использовании так называемой схемы первичной копии, которая действует следующим образом. ° Одна копия для каждого реплицируемого объекта устанавливается как первичная копия, а все оставшиеся копии — как вторичные.
° Первичные копии различных объектов находятся на различных узлах (поэтому данная схема все же является распределенной). ° Операции обновления считаются логически завершенйыми, как только обновлена первичная копия. Узел, содержащий такую копию, будет отвечать за распространение обновления на вторичные копии в течение некоторого последующего времени. (Это "последующее время", тем не менее, должно предшествовать операции завершения транзакции СОИМ1Т, если должны гарантироваться АС!1Э-свойства распределенных транзакций, т.е. свойства атомарности, согласованности, изолированности и долговечности. Дополнительные замечания по этому вопросу будут приведены ниже.) Конечно, данная схема порождает несколько дополнительных проблем, обсуждение большинства которых в этой книге не предусматривается. Отметим также, что эта схема приводит к нарушению принципа локальной автономии, поскольку транзакция может теперь завершиться аварийно из-за того, что удаленная (первичная) копия некоторого объекта недоступна (даже если локальная копия доступна).
Заиечание. Как уже указывалось, вследствие требования гарантии соблюдения АС!О-свойств транзакций, весь процесс распространения обновлений должен быть завершен прежде, чем соответствующая транзакция может быть зафиксирована ("синхронная репликация"). Однако несколько коммерческих продуктов поддерживают менее строгую форму репликации, в которой распространение обновлений откладывается на некоторое более позднее время (возможно, на некоторое указываемое пользователем время) и не обязательно в рамках соответствующей транзакции ("асинхронная репликация"). Фактически термин ренликаиия, к сожалению, в какой-то степени узурпирован этими продуктами, в результате чего, по крайней мере на коммерческом рынке, под ним подразумевается, что распространение обновлений откладывается до тех пор, пока соответствующая транзакция не завершится (например, )20.1), (20.18) и 120.21)).
Проблема подобного подхода с задержкой распространения обновлений заключается, конечно, в том, что база данных не может больше гарантировать согласованности всех ее данных в любой момент. В действительности пользователь даже может не знать, согласованна ли база данных. Завершая этот подраздел, приведем пару дополнительных замечаний в отношении подхода с задержкой распространения обновлений. 786 Часть !'. Дополнительные аспекты 1. Концепция репликации в системе с задержкой распространения обновлений может рассматриваться как применение идеи моментальных снимков, речь о которых шла в главе 9з.
На самом деле лучше было бы использовать другой термин для такого вида репликации. Тогда можно было бы сохранить термин "реплика" для обозначения того, что понимается под ним в обычном разговоре (а именно — точной копии). Заиечание. Мы не утверждаем, что задержка распространения обновлений — плохая идея.
Это, очевидно, самое лучшее, что можно было сделать при определенных обстоятельствах, как мы убедимся, например, в главе 21. Суть в том, что задержка распространения подразумевает, что "реплики" — не настоящие реплики, а система — не настоящая распределенная система баз данных. 2. Одна из причин (может быть, даже главная причина), по которой репликация в коммерческих продуктах реализована с задержкой расширения, заключается в следующем; альтернатива, т.е. обновление всех дубликатов перед выполнением операции СОИИ1Т, требует поддержки двухфазной фиксации транзакции (см.
ниже), что может существенно повлиять на производительность системы. Именно по этой причине в компьютерных журналах иногда встречаются статьи с озадачивающими названиями, например "Репликация или двухфазная фиксация?" (озадачиваюшими потому, что, по существу, в их названиях сравниваются качества совершенно разных предметов). Управление восстановлением Как уже разъяснялось в разделе 20.3, управление восстановлением в распределенных системах обычно базируется на протоколе двухфазной фиксации транзакций (или некоторых его вариантах).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
