Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
1.8. Особенности управления в распределенных информационных системах Объединение компьютеров в единые вычислительные системы на основе технологии компьютерных сетей поставило перед разра- ботчиками информационных систем новые задачи и предопределило необходимость реализации принципиально новых подходов к органи- зации информационного процесса в компьютерных сетях. Качествен- ный скачок в этой области возможен благодаря созданию гибких, вы- сокопроизводительных и экономичных распределенных информаци- онных систем. Распространение концепции баз данных (БД) на новый уровень позволяет определить распределенную информационную систему как комплекс логически интегрированных и территориально рассредото- ченных БД, технических, программных, языковых и организацион- 59 ных средств, предназначенных для накопления, ведения и использо- вания информации. В свою очередь, распределенная база данных (РБД) определяется как интегрированная БД, физически размещаемая на нескольких территориально распределенных компьютерах сети. Для таких систем характерными являются следующие функции: Накопление, обновление и хранение данных в географиче- ски удаленных узлах сети; Логическая интеграция территориально распределенных данных, процессов обработки, обновления и поиска информации; Обеспечение автоматического взаимодействия между ло- кальными базами данных в процессе исполнения запросов и решения задач пользователей. Управление выполнением основных функций ИС осуществляет комплекс программных средств, который включает систему управле- ния распределенными базами данных (СУРБД) в качестве основного компонента, а также сетевую операционную систему, систему разгра- ничения доступа и др. Под СУРБД понимают систему, реализующую принцип логиче- ской интеграции данных, физически распределенных между различ- ными взаимосвязанными компьютерами. К основным функциям СУРБД можно отнести анализ и распределение запросов, а также управление их прохождением. Следует отметить, что реализация концепции распределенных БД обеспечивает независимость программ по отношению к распреде- лению данных в вычислительной сети. Это означает, что пользова- тель может иметь доступ к любым данным сети в пределах своих полномочий как к собственной локальной базе данных. В этом кон- тексте существенный интерес представляет рассмотрение различных способов распределения данных по узлам сети для обеспечения эф- фективного доступа к ним. Стратегии распределения данных по узлам компьютерной сети могут классифицироваться по различным признакам. К основным из них можно отнести наличие дублирования информации и количество узлов, содержащих копии данных. В соответствии с указанными 60 классификационными признаками представляется возможным выде- лить четыре альтернативных стратегии распределения: Централизация (единственная копия БД, расположенная в одном узле); Расчленение (единственная копия БД, непересекающиеся фрагменты которой распределены по нескольким узлам); Дублирование (несколько копий БД, в каждом узле распо- лагается полная копия всей базы); Смешанная (несколько копий БД, в каждом узле распола- гается произвольный фрагмент базы). Ранжирование стратегий по предпочтительности их использо- вания в общем случае не представляется возможным. Определение ситуаций, в которых та или иная стратегия является наиболее подхо- дящей, целесообразно после выявления преимуществ и недостатков каждой из них. Стратегия централизации. Названная стратегия характеризует предельный случай распределения данных. Строго говоря, БД, по- строенная по этой стратегии, не является распределенной. Тем не ме- нее системы, реализующие стратегию централизации, могут быть вы- несены в класс систем распределенной обработки, в которых рассре- доточены вычислительные ресурсы и программное обеспечение. К несомненным достоинствам централизованной БД следует отнести ее простоту, так как все операции обращения к данным вы- полняются под управлением одного узла. В то же время недостатки рассматриваемой стратегии связаны именно с локальным расположением данных. Естественно, что объем базы данных ограничен емкостью запоминающих устройств цен- трального узла. К тому же запросы на операции над данными должны направляться только в этот узел со всеми вытекающими транспорт- ными издержками. Центральный узел становится узким местом всей сети по следующим причинам: Во-первых, скорость обработки дан- ных ограничивается его быстродействием; во-вторых, БД становится недоступной для других узлов при появлении неисправностей в сети 61 передачи данных и полностью отказывает при выходе из строя цен- трального узла. Любая из трех других стратегий помогает преодолеть указанные недостатки ценой определенных затрат. Стратегия расчленения. При использовании этой стратегии база разделяется на непересекающиеся подмножества данных, называемые логическими фрагментами. Каждый такой фрагмент размещается в отдельном узле. Число узлов, хранящих данные, может быть произ- вольным, в предельном случае равным общему числу узлов сети. Преимущества расчленения данных перед централизованным размещением следующие. Размер базы ограничивается объемом за- поминающих устройств всей сети (ее части). Снижается чувствитель- ность к узким местам в сети передачи данных, поскольку нагрузка на нее распределяется более равномерно. Повышается доступность дан- ных. Даже если сеть передачи данных полностью или частично выхо- дит из строя, то доступными для пользователей могут оставаться фрагменты БД в отдельных узлах или узлах, остающихся связанными. Это обеспечивает реализацию функций информационной системы, хотя и в сокращенном объеме. Важную роль при определении потенциальной доступности данных в критических ситуациях играет степень локализации ссылок. Под локализацией ссылок понимают характер расположения данных относительно запросов пользователей. Наивысшая степень локализа- ции ссылок существует в случае, если данные, расположенные в од- ном узле, запрашиваются исключительно пользователями этого узла. Напротив, степень локализации ссылок мала, если подобное расчле- нение базы невозможно. Таким образом, если запрос пользователя может быть исполнен с помощью локально хранимых данных (сте- пень локализации ссылок высока), то неисправности в других узлах или в сети передачи данных не окажут влияния на результат. Если же степень локализации ссылок незначительна или запросы являются сложными, то в большинстве случаев пользователям могут потребо- ваться данные от других узлов. Недоступность хотя бы одного узла приведет к неисполнению запроса пользователя. В подобной ситуа- 62 ции доступность данных в расчлененной базе может быть хуже, чем в централизованной, так как вероятность того, что по меньшей мере один узел сети будет недоступен, выше вероятности недоступности единственного конкретного узла. Следовательно, стратегия расчленения обеспечит меньшую по времени доступность БД, чем стратегия централизации. Степень локализации ссылок влияет и на временные характери- стики расчлененной БД. Так, если большая часть запросов обслужи- вается локально, уменьшаются затраты времени на передачу данных. С другой стороны, если исполнение запроса требует доступа ко мно- гим узлам, среднее время задержки может превышать аналогичный показатель централизованной базы. Тем не менее, уменьшение вре- мени реакции может быть достигнуто, если в полной мере использу- ется параллелизм в вычислительной сети. Стратегия дублирования. Реализация этой стратегии предпола- гает размещение полной копии БД в нескольких узлах сети (в пре- дельном случае в каждом узле). Отсутствует задача определения, ка- кую часть базы должен содержать тот или иной узел. Однако первоочередное значение приобретают вопросы, свя- занные с согласованием многочисленных копий данных. Рассматриваемая стратегия обеспечивает наивысший уровень доступности и надежности данных, но при явных затратах внешней памяти сети. Объем базы данных ограничивается наименьшей емко- стью запоминающих устройств в узлах, хранящих данные. Обработка данных большей частью проводится локально, но согласование мно- жества копий требует синхронизации. Способы согласования в кон- кретных приложениях могут быть различными, а уровень транспорт- ных издержек существенно зависит от степени постоянства данных. Необходимость согласования копий и сложность управления этим процессом являются причиной того, что стратегия дублирования позволяет реализовать параллельную обработку не столь просто, как стратегия расчленения. В свою очередь, каждый узел может работать асинхронно, а время реакции на запросы может быть небольшим, особенно при исполнении запросов, не требующих согласования ко- 63 пий, например при выполнении поисковых процедур. Налицо просто- та замены разрушенной копии или восстановления процесса обработ- ки в случае выхода из строя узла. Согласованная копия может быть получена из любого рабочего узла, после чего обращение к восста- новленному узлу может проводиться в полном объеме. Следует заме- тить, что если часть сети недоступна по какой-либо причине, необхо- димым становится наложение ограничений на выполнение операций обновления данных для поддержания глобальной согласованности копий базы данных. Действительно, если разрешить две операции об- новления в двух узлах при отсутствии согласования, то при возобнов- лении нормального функционирования сети возможно нарушение со- гласованности базы данных. Таким образом, стратегия дублирования наиболее применима в ситуациях, когда объем данных невелик, фактор доступности и надежности обращения к данным играет значительную роль, а интен- сивность обновления данных невысока. Последнее обстоятельство наиболее характерно для информационно-поисковых систем. Смешанная стратегия. Эта стратегия распределения данных объединяет подходы, используемые при расчленении и дублирова- нии, с целью приобретения преимуществ последних. Но в то же время смешанная стратегия не лишена недостатков, присущих своим прото- типам. Использование смешанной стратегии предполагает деление БД на логические фрагменты (расчленение) и наличие в сети произволь- ного числа их физических копий, называемых хранимыми фрагмен- тами (дублирование). Общность стратегии состоит в том, что любая часть базы может быть дублирована произвольное число раз, при этом в каждом узле может храниться желаемое подмножество дан- ных. Основным преимуществом смешанной стратегии, несомненно, является гибкость. Это важное свойство позволяет достичь компро- мисса между объемом памяти, используемой в целом и в каждом уз- ле, с одной стороны, и обеспечиваемым уровнем надежности и опера- тивности, с другой. Например, архивные данные могут храниться в 64 одном узле, а часто используемые могут быть дублированы. При дуб- лировании логического фрагмента усложняются процедуры обновле- ния хранимых фрагментов, но значительно большее количество дан- ных становится локально доступным, то есть повышается степень ло- кализации ссылок. Последнее ведет к снижению транспортных из- держек за счет уменьшения числа пересылок. Стратегия допускает довольно простую организацию параллельной обработки, что ведет к уменьшению времени реакции на запросы. Появляется возможность обхода узких мест в сети передачи данных. Недостатком смешанной стратегии является необходимость хранения информации о местонахождении данных в сети. Нетрудно заметить, что без наличия такой справочной информации невозможна реализация стратегии расчленения. Однако в последнем случае всегда можно указать однозначное соответствие между логическим фраг- ментом, с одной стороны, и узлом, в котором расположена его физи- ческая копия, с другой. В свою очередь, смешанная стратегия характеризуется много- значностью подобного соответствия, что существенно увеличивает объем справочных данных и требует введения процедур оптимизации доступа к хранимым фрагментам. Сложности возникают также при согласовании произвольного числа хранимых фрагментов, связанных с каждым логическим фрагментом. Обработка и оптимизация запро- сов являются нетривиальными задачами. Рассматриваемая стратегия может быть рекомендована к реали- зации тогда, когда ни одна из более простых стратегий не признается удовлетворительной. Например, необходимо обеспечить выполнение высоких требований по надежности, предъявляемых к отдельным ча- стям большой по объему БД. При этом каждый узел может обращать- ся к некоторым частям базы довольно часто, а к остальным – значи- тельно реже. В этом случае стратегия расчленения не может обеспе- чить достаточной надежности, а стратегия дублирования может быть неприемлемой из-за требований на объем памяти в узлах. Подводя итог рассмотрению стратегий, следует заметить, что первоочередные проблемы, связанные с распределением данных в се- 65 ти, подлежат разрешению на стадии проектирования РБД, которая имеет ряд существенных особенностей по сравнению с проектирова- нием локальных БД. В распределенной информационной системе логически целост- ная БД может быть фрагментирована и широко распределена по сети с целью улучшения производительности и надежности ИС. Фрагмен- тация и распределение данных без централизованного планирования часто являются причиной несогласованного использования данных. Поэтому последовательность этапов проектирования РБД должна учитывать этот факт. Приведем краткую характеристику этапов проектирования РБД. Этап анализа предметной области. Его реализация предпо- лагает изучение и описание предметной области, а также анализ пользовательских потребностей в информации. Этап концептуального проектирования. По результатам предыдущего этапа разрабатывается инфологическая модель (инфор- мационная структура) предметной области. Этап логического проектирования (проектирования реали- зации). Вовремя его проведения осуществляется выбор системы управления РБД и наложение ограничений выбранной СУРБД на ин- формационную структуру. Результатом логического проектирования выступает глобальная структура БД. Этап расчленения базы данных. Рассматриваемый этап связан с делением глобальной БД на логические фрагменты. При ре- шении задачи расчленения учитывают требования к обработке дан- ных, характеристики выбранной СУРБД, а также характеристики тех- нических и программных средств в узлах сети. Результатами являют- ся совокупность логических фрагментов и размер каждого из них. Этап размещения базы данных. На этом этапе решается за- дача выбора узлов сети для размещения в них хранимых фрагментов, соответствующих логическим фрагментам БД. Определенные огра- ничения накладывают требования по обработке данных и разграниче- нию доступа, особенности сети передачи данных (ее топология, про- пускная способность каналов), а также характеристики аппаратуры и 66 программного обеспечения узлов вычислительной сети. Решение представляет собой перечень узлов, с каждым из которых связан спи- сок фрагментов БД. Этап проектирования локальных баз данных. Является за- ключительным в рассматриваемой последовательности. На нем осу- ществляется проектирование физических структур локальных БД, об- разованных в результате выполнения всех процедур предшествую- щих шагов. Главное различие процессов проектирования РБД и локальных БД состоит в наличии этапов расчленения и размещения БД, которые поэтому заслуживают более подробного рассмотрения. При расчленении исходная глобальная база разделяется на мно- жество логических фрагментов, называемых также разделами. Есте- ственно, что должно выполняться требование о сохранении информа- ции, то есть разделы должны содержать все сведения, имеющиеся в исходной глобальной базе. Дополнительно на процесс формирования разделов накладываются ограничения по их допустимому размеру, времени реакции на запрос и надежности обращения. Вследствие это- го в раздел рекомендуется объединять такие часто используемые совместные записи, чтобы он улучшал характеристики времени отве- та на запрос. Также следует стремиться к получению требуемого уровня надежности, используя по возможности меньшую кратность дублирования, то есть степень локализации ссылок должна быть вы- сокой при минимальном числе копий хранимых фрагментов. Допу- стимый размер каждого раздела как неделимой совокупности данных определяется фиксированным объемом памяти в каждом узле сети. И в общем случае ограничения на класс допустимых расчленений накладывает емкость внешних запоминающих устройств в узлах сети. Задача размещения распределенной базы данных решается сравнительно просто для двух стратегий: централизации и дублиро- вания. Вполне очевидно, что отпадает необходимость в выполнении процедуры расчленения базы данных. Если принята первая стратегия, то перед разработчиком стоит один вопрос: в каком узле следует раз- местить базу данных? Реализация второй стратегии для каждого узла 67 сети требует решения вопроса: размещать или не размещать полную копию базы? Ответы на поставленные вопросы зачастую предопреде- лены и зависят от структуры сети, объема памяти в ее узлах, перечня альтернатив и здравого смысла. Значительно сложнее представляется задача размещения при использовании стратегии расчленения, особенно сложной при сме- шанной стратегии. В случае реализации стратегии расчленения необ- ходимо: во-первых, расчленить базу на логические фрагменты и, во- вторых, разместить каждый фрагмент в конкретном узле с учетом ограничений на размещение. Задача является итеративной, и возмож- но, что расчленение базы данных потребуется проводить неоднократ- но. Если же используется смешанная стратегия, решение становится более сложным: каждый логический фрагмент может быть размещен в любом числе узлов. Количество перестановок фрагментов растет очень быстро, и это является одной из причин того, что ограничива- ются нахождением не оптимального, а рационального размещения. Решение задачи оптимального размещения фрагментов по узлам сети методами линейного программирования возможно при довольно жестких допущениях о характере потока запросов к базе, предопреде- ленном числе и неизменности этих запросов, заранее известном числе хранимых фрагментов. Количество переменных и ограничений про- грессирует с увеличением числа узлов сети, и поэтому получение ре- шения возможно лишь для задач малой размерности. Решение также усложняется при предъявлении менее жестких требований к характе- ру запросов пользователей. Подходы к решению используют в своей основе метод динамического программирования. Если же типовые запросы первоначально неизвестны, то используются статистические методы для определения этих запросов, а результаты их определения служат входными данными для решения задачи размещения. В целом процесс разработки распределенных баз данных отли- чается высокой трудоемкостью и значительными материальными за- тратами. Задача выбора наилучшего соответствия между характери- стиками РБД и методами распределения данных в сети требует все- стороннего анализа, так как принятые проектные решения оказывают 68 непосредственное влияние на реализацию и последующее функцио- нирование информационной системы. Очевидно, что распределенные БД, в отличие от локальных баз, должны потребовать большего числа уровней представления данных для реализации принципа независимости описания структуры баз от данных. Действительно, трехуровневая архитектура в случае РБД расширяется до пяти уровней (рис. 1.7). Пользовательский уровень представления данных. Служит для описания части базы данных, доступной одному конкретному пользо- вателю или группе пользователей, рассматриваемых как один. Эта часть многоуровневого представления является, по сути, внешней моделью в концепции ANSI. Каждый пользователь может иметь от- личное от других пользователей представление, соответствующее его требованиям и требованиям разграничения доступа. Глобальный логический уровень представления данных. Этот уровень подобен концептуальному уровню представления концепции ANSI. Используется для описания логической структуры всей рас- пределенной базы данных, то есть в представлении администратора РБД. При описании РБД этому уровню ставится в соответствие гло- бальная представляющая схема. Существование третьего и четвертого уровней объясняется рас- пределенной природой РБД. Фрагментный уровень представления данных. Используя этот уровень, администратор РБД определяет несвязанные подмножества базы данных, то есть логические фрагменты, и описывает их сред- ствами СУБД в виде локальных представляющих схем. Уровень представления распределения данных. На данном уровне определяется географическое расположение экземпляров каж- дого логического фрагмента. Уровень допускает существование не- скольких физических фрагментов, соответствующих логическому фрагменту. Этому уровню соответствует схема распределения дан- ных. Уровень локального представления данных. Соответствует опи- санию той части базы данных, которая существует в конкретном узле. 69 Несомненно, что эта локальная база может рассматриваться с точки зрения, как логической, так и физической структуры. Однако локаль- ное представление считается описанием логической структуры, при этом физическая структура является скрытой от администратора РБД. Локальная БД как база в полном понимании этого слова имеет не- сколько уровней представления, но в данном рассмотрении эти уров- ни не принимают участия. Рис.1.7. Уровни представления данных в РБД При обращении множества пользователей или прикладных про- грамм к распределенной базе данных на первый план выдвигается проблема управления параллельным выполнением запросов к СУРБД. Обязательным условием является то, что каждый запрос, связанный с корректировкой данных, должен оставлять РБД в непротиворечивом состоянии. В таком случае по окончании исполнения запроса необхо- димо установить, что СУРБД завершила выполнение всех подзапро- сов, изменяющих данные. При подобном подходе исключается воз- можность использования информации, определяемой переходным со- стоянием базы данных. Данное условие может выполняться по- разному в зависимости от времени проведения операций обновления данных. Оперативная актуализация проводится в реальном масштабе 70 времени, а периодическая – в некоторые установленные моменты по- сле накопления изменений данных. В последнем случае выполнение запросов на выборку данных при обновлении блокируется. Реализа- ция периодической актуализации представляется довольно простой, однако данный подход не может быть признан удовлетворительным для использования в базах данных, являющихся информационными моделями систем, состояние которых подвержено частым изменени- ям. При оперативной актуализации действия над данными, прово- димые в соответствии с различными запросами, могут выполняться СУРБД параллельно. При этом возникает несколько ситуаций, когда операция над данными может быть не завершена. Это тупиковые си- туации и циклические рестарты. Тупиковые ситуации характеризуют- ся тем, что операции в нескольких запросах (транзакциях) вынужде- ны ждать завершения друг друга. Явление циклического рестарта свя- зано с периодическим попаданием транзакции в такое состояние, ко- гда ее выполнение становится невозможным, после чего она отменя- ется, а затем производится повторный запуск. Механизм управления параллельным выполнением транзакций должен либо исключать по- добные ситуации, либо обеспечивать их разрешение. К основным ме- тодам, позволяющим корректно завершать выполнение оперативной актуализации распределенной базы данных и оставлять ее в непроти- воречивом состоянии, относят методы: блокировок данных, согласия большинства и предварительного анализа конфликта транзакций. Метод блокировок данных. Данный метод является наиболее распространенным. На практике применяются две его модификации, различающиеся выбранным способом управления. При централизо- ванной блокировке в сети выделяется главный распределитель ресур- сов, которому направляются все требования транзакций по блокиров- ке изменяемых данных. С получением права пользования ресурсом транзакция актуализации осуществляет доступ к данным в любом уз- ле, хранящем копию. Для обеспечения гарантированного использова- ния непротиворечивых данных транзакции, осуществляющие только операции чтения, должны придерживаться принятой дисциплины до- 71 ступа к данным. Реализация децентрализованной блокировки устра- няет главный недостаток предыдущей модификации – низкую сте- пень параллелизма и малую живучесть системы управления БД, но при этом не исключается возможность образования тупиков. Метод согласия большинства. При использовании названного метода узлам предоставлено право решать вопрос об изменении дан- ных по конкретному запросу «голосованием». Это позволит разре- шить конфликтные ситуации, возникающие при обращении к дан- ным, и полностью исключить тупиковые ситуации. Степень парал- лельного выполнения транзакций та же, что и при децентрализован- ной блокировке данных. Сущность метода согласия большинства состоит в следующем. С каждым компонентом базы данных связывается временная метка, фиксирующая момент его последнего изменения. Операторы измене- ния данных принимаются к исполнению только в том случае, если они относятся к транзакциям, выполнение которых началось позднее времени, указанного в метке. В операторах изменения указываются: уникальный код транзакции, ее временная метка, список изменяемых ресурсов, новые значения данных, список базовых ресурсов (исполь- зуемых при формировании изменения), значения их временных меток и т.д. При получении оператора узел обязан выполнить одно из сле- дующих действий: Проголосовать отрицательно (отклонить оператор) в слу- чае, если нарушено условие соотношения временных меток, указан- ное ранее, и временные метки базовых ресурсов, сообщенные в опе- раторе, относятся к более ранним моментам, чем фактически зафик- сированные в узле; Проголосовать положительно (принять оператор) при условии, что все соотношения временных меток являются удовлетво- рительными и данный оператор не вступает в конфликт с другим ак- тивным оператором. (Конфликт возможен, если активный оператор, то есть не принятый и не отклоненный, пытается изменить базовый ресурс рассматриваемого оператора или модифицируемый рассмат- 72 риваемым оператором ресурс является базовым для любого активного оператора); Воздержаться от голосования, когда соотношение времен- ных меток является удовлетворительным, но имеет место конфликт с другими активными операторами. Метод предварительного анализа конфликта транзакций. Этот метод предполагает анализ возможности возникновения конфликта и его характера. Каждому виду конфликта ставится в соответствие спе- циализированный протокол синхронизации транзакций, эффективно разрешающий возникшую ситуацию. В основе работы протокола находится техника временных меток. Предварительный анализ ситуации, проводимый центральным узлом, исключает образование тупиковых ситуаций. Выбор того или иного метода для его последующей реализации зависит от конкретных приложений. Выработка общих рекомендаций является затруднительной вследствие отсутствия сведений о достига- емых значениях показателей эффективности функционирования раз- личных СУРБД. |