Основи на съвременните бази данни Предговор
СУБД в архитектурата "клиент-сървър"
Изтегляне 1.71 Mb.
|
- Навигация на страницата:
- 19.2. Клиенти и сървъри на локални мрежи
- 19.3. Системна архитектура "клиент-сървър"
- 19.4. Сървъри на бази от данни
- 19.4.1. Принципи на взаимодействието между клиентските и сървърните части
- 19.4.2. Предимства на протоколите за отдалечено извикване на процедури
- 19.4.3. Типичное разделение на функциите между клиенти и сървъри
- 19.4.4. Изисквания към апаратните възможности и базовото програмно осигуряване на клиентите и сървърите
- 20.1. Разновидности разпределеных систем
- 20.2. Разпределеная система управления базами от данни System R*
- 20.2.1. Именование обектов и организация разпределеного каталога
- 20.2.2. Разпределеная компилация заявките
- 20.2.3. Управление транзакциями и синхронизация
- 20.3. Интегрированные или федеративные системы и мультибазы от данни
СУБД в архитектурата "клиент-сървър"Лекция 19. Архитектура "клиент-сървър"Спрямо системите с бази от данни архитектурата "клиент-сървър" е интересна и актуална най-вече затова, защото осигурява просто и относително евтино решение на проблема за колективния достъп до базите от данни в локална мрежа. До известна степен системите с бази от данни, основани на архитектурата "клиент-сървър", са приближение на разпределените системи бази от данни, естествено, съществено опростено приближение, но затова пък неизискващо решаване на основния набор проблеми на истински разпределените бази от данни. 19.1. Отворени системиРеалното разпространение на архитектурата "клиент-сървър" става възможно благодарение на развитието и широкото внедрение в практиката на концепцията на отворените системи. Основният смисъл на подхода на отворените системи е опростяване на усложнените изчислителни системи за сметка на международната и националната стандартизации на апаратните и програмните интерфейси. Главната подбудителна причина за развитие на концепцията на отворените системи е повсеместният преход към използването на локалните компютърни мрежи и тези проблеми на усложняването на апаратно-програмните средства, които предизвиква този преход. Във връзка с бурното развитие на технологиите на глобалните комуникации отворените системи придобиват още по-голямо значение и мащабност. Ключовата фраза на отворените системи, насочена към потребителите, е независимост от конкретния доставчик. Ориентирайки се към продукцията на компаниите, придържащи се към стандартите на отворените системи, потребителят, който придобива произволен продукт от такава компания, не става неин роб. Той може да продължи нарастването на мощността на своята система чрез придобиване на продуктите на коя да е друга компания, спазваща стандартите. Това касае както апаратните, така и програмните средства и не е необоснована декларация. Реалната възможност за независимост от доставчика е проверена в нашите условия. Практическата опора на системните и приложните програмни средства на отворените системи стандартизирана операционна система. В днешно време такава система е UNIX. Фирмите-доставчици на различните варианти на ОС UNIX в резултат продължителна работа стигат до съглашение за основните стандарти на тази операционна система. Днес всички разпространени версии на UNIX са съвместими по отношение на интерфейсите, предоставяни на приложните (а в повечето случаи и на системните) програмисти. Независимо от появата на претендиращата за стандарт система Windows NT, именно UNIX остава основата на отворените системи в близките години. Технологиите и стандартите на отворените системи осигуряват реалната и проверена практикой възможност за производство на системни и приложни програмни средства със свойства на мобилност (portability) и интероперабелност (interoperability). Свойството мобилност означава сравнителна простота на преноса на програмната система в широк спектър апаратно-програмни средства, съответстващи на стандартите. Интероперабелност означава опростяване на комплексирането на новите програмни системи на основата на използването на готови компоненти със стандартни интерфейси. Използването на подхода на отворените системи е изгодно и за производителите, и за потребителите. Преди всичко отворените системи осигуряват естествено решение за проблема на поколенията апаратни и програмни средства. Производителите на такива средства не се принуждават да решават всички проблеми отново; те могат най-малкото временно да продължат да усложняват системите, използвайки съществуващите компоненти. При това възниква ново ниво на конкуренция. Всички производители са задължени да осигурят някаква стандартна среда, но са принудени да направят реализацията колкото се може по-добра. Разбира се, след време съществуващите стандарти ще започнат да сдържат прогреса, и тогава ще се наложи да бъдат преразгледани. Предимството за потребителите е това, че те могат постепенно да заменят компоненти на системата на по-съвършени, без да губят работоспособността на системата. В частност, в това се крие решението на проблема за постепенното натрупване на изчислителни, информационни и други мощности на компютърната система. 19.2. Клиенти и сървъри на локални мрежиВ основата на широкото разпространение локалните компютърни мрежи лежи известната идея за разделение на ресурсите. Високата пропускателна способност на локалните мрежи осигурява ефективния достъп от един възел на локалната мрежа до ресурсите, намиращи се в други възли. Развитието на тази идея води до функционалното отделянe на компонентите на мрежата: разумно да има не само достъп до ресурсите на отдалечен компютър, но също и да се получава от този компютър някакво обслужване, което е специфично за ресурси от даден вид и програмните средства за осигуряване на което не е целесъобразно да се дублират в няколко възела. Така стигаме до разделянето на работни станции и сървъри на локалната мрежа. Работната станция е предназначена за непосредствена работа на потребителя или категории потребители и притежава ресурси, съответстващи на локалните потребности на дадения потребител. Специфични особености на работната станция могат да бъдат: обема на оперативната памет (съвсем не всички категории потребители се нуждаят от голям обем оперативна памет), наличието и обема на дисковата памет (достатъчно са популярни бездисковите работни станции, използващи външната памет на дисковия сървър), характеристиките на процесора и монитора (на някои потребители е необходим мощен процесор, други повече се интересуват от разрешаващата способност на монитора, за трети са задължителни средствата за графично ускоряване и т.н.). При необходимост може да се използват ресурсите и/или услугите, предоставяни от сървъра. Сървърът на локалната мрежа трябва да притежава ресурси, съответствуващи на функционалното му предназначение и потребностите на мрежата. Във връзка с ориентацията към подхода на отворените системи, е по-правилно да се говори за логически сървъри (имайки предвид набор от ресурси и програмни средства, осигуряващи услугите над тези ресурси), които не е задължително да се разполагат на различни компютри. Особеност на логическия сървър в отворената система е тази, че ако по съображения за ефективност сървърът е целесъобразно да се премести на отделен компютър, то това може да се направи без необходимост от някакво преправяне, както на него самия, така и на използващите го приложни програми. Примери за сървър могат да бъдат:
Сървърът на локалната мрежа предоставя ресурси (услуги) на работните станции и/или други сървъри. Прието е да се нарича клиент на локалната мрежа, заявяващ услуги от някакъв сървър и сървър - компонент на локалната мрежа, оказващ услуги на някакви клиенти. 19.3. Системна архитектура "клиент-сървър"Ясно е, че в общия случай, за да може приложната програма, изпълняваща се на работната станция, да заяви услуга към някакъв сървър, като минимум е необходим интерфейсeн програмeн слой, поддържащ такъв вид взаимодействие (би било най-малкото неестествено да се иска приложната програма напряко да се възползва от примитивите на транспортния слой на локалната мрежа). От това, собствено, и произтичат основните принципи на системната архитектура "клиент-сървър". Системата се разделя на две части, които могат да се изпълняват в различни възли на мрежата, - клиентска и сървърна части. Приложната програма или крайния потребител взаимодействат с клиентската част на системата, която в най-простия случай осигурява надмрежови интерфейс. Клиентската част на системата при необходимост се обръща по мрежата към сървърната част. В развитите системи мрежовото обръщение към сървърната част може и да не потрябва, ако системата може да предусеща потребностите на потребителя, и в клиентската част се съдържат данни, способни да удовлетворят неговата следваща заявка. Интерфейсът на сървърната част е определен и фиксиран. Затова е възможно създаването на нови клиентски части на съществуваща система (пример за интероперабелност на системно ниво). Основният проблем на системите, основани на архитектурата "клиент-сървър", е това, че в съответствие с концепцията на отворените системи от тях се иска мобилност в колкото се може по-широк клас апаратно-програмни решения за отворените систем. Даже ако се ограничим с UNIX-ориентираните локални мрежи, в различните мрежи се използва различна апаратура и мрежови протоколи. Опитите за създаване на системи, поддържащи всички възможни протоколи, води до тяхното претоварване с мрежови детайли в ущърб на функционалността. Още по-сложният аспект на този проблем е свързан с възможността за използване на различни представяния на данните в различните възли на нееднородна локална мрежа. В различните компютри може да има различна адресация, представяне на числата, кодиране на символите и т.н. Това е особено съществено за сървърите от високо ниво: телекомуникационни, изчислителни, за бази от данни. Общо решение на проблема за мобилността на системите, основани на архитектурата "клиент-сървър" е опората върху програмните пакети, реализиращи протоколи за отдалечено извикване на процедури (RPC - Remote Procedure Call). При използването на такива средства обръщението към обслужването в отдалечения възел изглежда като обикновено извикване на процедура. Средствата на RPC, в които, естествено, се съдържа цялата информация за спецификата на апаратурата на локалната мрежа и мрежовите протоколи, превръща извикването в последователност от мрежови взаимодействия. Така, спецификата на мрежовата среда и протоколите е скрита от приложния програмист. При извикването на отдалечена процедура програмите RPC извършват преобразуване на форматите на данните на клиента в промеждутъчни машинно-независими формати и след това преобразуване във формати на данните на сървъра. При предаването на ответните параметри се извършват аналогични преобразувания. Ако системата е реализирана на основата на стандартен пакет RPC, тя може да бъде лесно пренесена в коя да е отворена среда. 19.4. Сървъри на бази от данниТерминът "сървър за бази от данни" обикновено се използва за обозначаване на цялата СУБД, основана на архитектурата "клиент-сървър", включително и сървърната, и клиентската част. Тези системи са предназначени за съхраняване и осигуряване на достъпа до базите от данни. Макар обикновено една база от данни изцяло да се съхранява в един възел на мрежата и да се поддържа от един сървър, сървърите за бази от данни представляват просто и евтино приближение на разпределените бази от данни, тъй като общата база от данни е достъпна за всички потребители на локалната мрежа. 19.4.1. Принципи на взаимодействието между клиентските и сървърните частиДостъпът до базата от данни от приложна програма или потребител се извършва чрез обръщение към клиентската част на системата. Като основен интерфейс между клиентската и сървърната част служи езикът за бази от данни SQL. Това всъщност е език представляващ текущия стандарт на интерфейс на СУБД в отворените системи. Събирателното название SQL-сървър се отнася до всички сървъри за бази от данни, основани на SQL. Като се спазват внимателно правилата при програмирането, може да се създават приложни информационни системи, мобилни в класа на SQL-сървърите. Сървърите за бази от данни, интерфейсът на които е основан изключително на езика SQL, имат своите предимства и своите недостатъци. Очевидното предимство е стандартност на интерфейса. В граничния случай, макар засега това да не е съвсем така, клиентските части на всяка SQL-ориентирана СУБД биха могли да работят с всеки SQL-сървър независимо от това, кой го е произвел. Недостатъкът също е очевиден. При такова високо ниво на интерфейса между клиентската и сървърната части на системата на страната на клиента работят твърде малко програми за СУБД. Това е нормално, ако на страната на клиента се използва маломощна работна станция. Но ако клиентският компютър притежава достатъчна мощност, то често въниква желанието да се възложат на него повече функции по управлението на базите от данни, разтоварвайки сървъра, който e тясното място на цялата система. Едно от перспективните направления в СУБД е гъвкавото конфигуриране на системата, при което разпределението на функциите между клиентската и потребителската части на СУБД се определя при поставяне на системата.
Перво, използването на механизма за отдалечени процедури позволява действително да се преразпределят функции между клиентската и сървърната части на системата, тъй като в текста на програмата отдалеченото извикване на процедура с нищо не се различава от отдалеченото извикване, и следователно, теоретически всеки компонент на системата може да се разполага и на страната на сървъра, и на страната на клиента. Второ, механизмът на отдалеченото извикване скрива различията между взаимодействащите си компютри. Физически нееднородната локална мрежа компютри се привежда към логически еднородна мрежа взаимодействащи си програмни компоненти. В резултат потребителите не са длъжни серьозно да се грижат за еднократното купуване на съвместими сървъри и работни станции.
В някои случаи ни се иска да включим в състава на клиентската част на системата някои функции за работа с "локалния кеш" на базата от данни, т.е. с тази нейна част, която интензивно се използва от клиентската приложна програма. В съвремената технология това може да се направи само чрез формалното създаванe на стрaнaта на клиента на локално копие на сървъра на базата от данни и разглеждане на цялата система като набор от взаимодействащи си сървъри. От друга страна, понякога ни се иска да пренесем по-голямата част от приложната система на страната на сървъра, ако разликата в мощността на клиентските работни станции и сървъра е прекалено голяма. Най-общо при използването на RPC това не е трудно да се направи. Но е необходимо, базовото програмно осигуряване на сървъра действително да го позволява. В частност, при използването на ОС UNIX проблеми практически не възникват.
Ако разделението между клиента и сървъра е достатъчно твърдо (както в повечето съвременни СУБД), то за потребителите, работещи на работни станции или персонални компютри, е абсолютно все едно, каква апаратура и операционна система работят на сървъра, само той да се справя с възникващия поток заявки. Но ако могат да възникнат потребности от преразпределение на функциите между клиента и сървъра, то вече съвсем не е все едно, какви операционни системи се използват. Разпределени бази от данни Лекция 20. Разпределени БД Основная задача систем управления разпределеными базами от данни състои в обеспечении средства интеграции локалних баз от данни, располагающихся в някоиых узлах вычислительной мрежа, с тем, чтобы потребитель, работающий в любом узле мрежа, имел достъп ко всем этим базам от данни как к единой базе от данни. При этом должны обеспечиваться:
20.1. Разновидности разпределеных системВъзможны однородные и неоднородные разпределеные базы от данни. В однородном случае каждая локальная база от данни управляется одной и той же СУБД. В неоднородной системе локалние базы от данни могут относиться даже к разным моделям от данни. Сетевая интеграция неоднородных баз от данни - это актуальная, но очень сложная проблема. Многие решения известны на теоретическом уровне, но пока не удается справиться с главной проблемой - недостатъчной эффективностью интегрированных систем. Заметим, что более успешно практически решается промежуточная задача - интеграция неоднородных SQL-ориентированных систем. Понятно, что этому в большой степени способствует стандартизация езика SQL и общее следование производителей СУБД принципам отворених систем. Мы ограничимся рассмотрением проблем однородных разпределеных СУБД на примере System R*.
За решения этих проблем было необходимо принять ряд проектных решений, касающихся декомпозиции исходного запроса, оптимального выбора способа изпълнения запроса, съгласуваного изпълнения транзакций, обеспечения синхронизации, обнаружения и разрешения разпределеных взаимоблокировков, възстановения состояния баз от данни после разного рода сбоев узлов мрежа. Легкость използования системы достигается за счет того, что потребители System R* (разработчики приложных програм и конечные потребители) остаются в среде езика SQL, т.е. могут продолжать работать в тех же внешних условиях, что и в System R (и SQL/DS и DB2). Възможность използования SQL основывается на обеспечении System R* прозрачности местоположения от данни. Система автоматически обнаруживает текущее местоположение упоминаемых в запросе потребителя обектов от данни; одна и та же приложная програма, включающая предложения SQL, може да бъде изпълнена в разных узлах мрежа. При этом в каждом узле мрежа на этапе компилации запроса выбирается наиболее оптимальный план изпълнения запроса в съответствии с расположением от данни в разпределеной системе. Обеспечению автономности узлов мрежа в System R* уделяется очень большое внимание. Каждая локальная база от данни администрируется независимо от других. Възможны автономное подключение новых потребителей, смена версии автономной части системы и т.н. Система спроектирована таким образом, что в ней не требуются централизованные службы именования обектов или обнаружения взаимоблокировков. В индивидуальных узлах не требуется наличие глобального знания об операциях, выполняющихся в других узлах мрежа; работа с достъпными базами от данни может продолжаться при выходе из строя отдельных узлов мрежа или линий связи. Высокая степень эффективности системы является одним из наиболее ключевых изискванй к разпределеным системам управления базами от данни вообще и к System R* в частности. За достижения этой цели използуются два основных приема. Во-первых, как и в System R, в System R* изпълнению запроса предшествует его компилация. В ходе этого процеса се извършва поиск употребляемых в запросе имен обектов баз от данни в разпределеном каталоге и замена имен на внутренние идентификаторы; проверка прав достъпа потребителя, от имени которого се извършва компилация, на изпълнение съответствующих операций над базами от данни и выбор наиболее оптимального глобального плана изпълнения запроса, который затем подвергается декомпозиции и по частям рассылается в съответствующие узлы мрежа, где се извършва выбор оптимальных локалних планов изпълнения компонентов запроса и происходит генерация модулей достъпа в машинных кодах. В резултате множество действий се извършва на стадии компилации до реального изпълнения запроса. Обработанная посредством прекомпилатора System R* приложная програма, включающая предложения SQL, может в дальнейшем выполняться много раз без дополнительных накладных расходов. Използование разпределеного каталога, разпределеная компилация и оптимизация заявките являются наиболее интересными и оригинальными аспектами проекта System R*. Вторым средством повышения эффективности системы является възможность перемещения отдалеченых отношений в локальную базу от данни. Диалект SQL, използуемый в System R*, включает предложение MIGRATE TABLE, при изпълнении которого указанное отношение переносится в локальную базу от данни. Это средство, находящееся в распоряжении потребителей, конечно, в ряде случаев может помочь добиться более эффективного прохождения транзакций. Естественно, как и за всех операций, операция MIGRATE по отношению к указанному отношению достъпна не любому потребителю, а лишь тем, които обладают съответствующим правом. Прежде, чем перейти к более детальному изложению наиболее интересных аспектов реализации System R*, упомянем некоито средства, които разработчики этой системы предполагали реализовать на начальной стадии проекта, но които реализованы не были (причем некоито из них, видимо, и не будут никогато реализованы). Предполагалось иметь в системе средства горизонтального и вертикального разделения отношений разпределеной базы от данни, средства дублирования отношений в нескольких узлах с поддержкой съгласуваности копий и средства поддержания мгновенных снимков состояния баз от данни в съответствии с заданным запросом. За задания горизонтального разделения отношений в SQL была введена конструкция вида DISTRIBUTE TABLE При изпълнении предложения такого типа указанное отношение разбивалось на ряд подотношений, съдържащих кортежи, удовлетворяющие съответствующему предикату из раздела WHERE, и каждое полученное таким образом подотношение посылалось в казанный узел за хранения в сегменте с указанным именем. Гарантируется съгласувано состояние разделов при изменении отношения. Вертикальное разделение производилось с помощью оператора DISTRIBUTE TABLE . . При изпълнении такого предложения также образовывался набор подотношений с помощью проекции заданного отношения на атрибуты из заданного списка. Каждое полученное подотношение затем посылалось за хранения в сегменте с указанным именем в съответствующий узел. После этого система ответственна за поддержание съгласуваного состояния образованных разделов. Горизонтальное и вертикальное разделение отношений реально не използуются в System R*, хотя очевидно, что изпълнение собственно оператора DISTRIBUTE никаких технических трудностей не вызывает. Трудности возникают при обеспечении съгласуваности разделов (смотри ниже). Кроме того, разделенные отношения очень трудно използовать. В съответствии с идеологией системы учет наличия разделов отношения в разных узлах мрежа должен производить оптимизатор, т.е. количество потенциально възможных планов изпълнения заявките, които должны оцениваться оптимизатором, еще более возрастает. При том, что в разпределеной системе число възможных планов и так очень велико, и оптимизатор работи на пределе сложности, разумным образом използовать разделенные отношения невъзможно. Разработчики оптимизатора System R* не были в состоянии учитывать разделенность отношений. Поэтому и вводить в систему разделенные отношения пока бессмысленно. За задания изискваня поддержки копий отношения в нескольких узлах мрежа предлагалось използовать новую конструкцию SQL DISTRIBUTE TABLE При изпълнении такого предложения должна была производиться рассылка копий указанного отношения за хранения в именованных сегментах указанных узлов мрежа. Система должна автоматически поддерживать съгласуваност копий. Как и в случае разделенных отношений, кроме същественых проблем поддержания съгласуваности копий, проблемой является и разумное използование копий, наличие които должно было бы учитываться оптимизатором. Създавание мгновенного снимка состояния баз от данни в съответствии с заданным запросом на выборку должно было производиться с използованием новой конструкции SQL. DEFINE SNAPSHOT При изпълнении предложения фактически се извършва изпълнение указанного в нем запроса на выборку, а результирующее отношение сохраняется под указанным в предложении именем в локальной базе от данни в том узле, в котором изпълнявася предложение. После этого мгновенный снимок периодически обновляется в съответствии с запомненным запросом. Можно обновить мгновенный снимок, не дожидаясь истечения временного интервала, указанного в определении, путем изпълнения предложения REFRESH SNAPSHOT Разумное използование мгновенных снимков более реально, чем използование разделенных отношений и копированных отношений, поскольку их можно в някоиом смысле рассматривать как материализованные представления базы от данни. Имя мгновенного снимка можно было бы използовать прямо в запросе на выборку там, где можно използовать имена базовых отношений или представлений. Большие проблемы свързаны с обновлением отношений через их мгновенные снимки, поскольку в момент обновления съдържимое мгновенного снимка может расходиться с текущим съдържимым базового отношения. По отношению к мгновенным снимкам проблем поддержания съгласуваного состояния мгновенного снимка и базовых отношений не съществует, поскольку автоматическое согласование не требуется. Что же касается разделенных отношений и раскопированных отношений, то за них эта проблема общая и достатъчно трудная. Во-первых, согласование разделов и копий вызывает същественые накладные расходы при изпълнении операций модификации хранимых отношений. За этого требуется выработка и съблюдение специалних протоколов модификации. Во-вторых, введение копированных отношений обикновено се извършва не столько за увеличения эффективности системы, сколько за увеличения достъпности от данни при нарушении связности мрежа. В системах, в които применяется этот подход, при нарушении связности мрежа работа с разпределеной базой от данни обикновено продолжается только в одной из образовавшихся подмрежи. При этом за выбора подмрежа използуются алгоритмы голосования; решение принимается на основе учета количества связных узлов мрежа. Применяются и другие подходы, но все они очень дорогостоящие, а самое главное, они плохо согласуются с базовым подходом System R* по поводу выбора способа изпълнения запроса на стадии его компилации. Поэтому, как нам кажется, в System R* никогато не будут реализованы средства, позволяющие тем или иным способом поддерживать копии отношений в нескольких узлах мрежа. Далее мы рассмотрим аспекты проекта System R*, които нашли отражение в ее реализации и являются на наш взгляд наиболее интересными: средства именования обектов и организацию разпределеного каталога баз от данни; подход к разпределеным компилации и изпълнению заявките; особенности използования представлений; средства оптимизации заявките; особенности управления транзакциями; средства синхронизации и разпределеный алгоритм обнаружения синхронизационных взаимоблокировков.
В System R* използуется развитие этого подхода. Системное имя отношения включает четыре компонента: идентификатор потребителя-создателя отношения; идентификатор узла мрежа, в котором выполнялась операция създавания отношения; локальное имя отношения, присвоенное ему при създавании; идентификатор узла, в котором отношение располагалось непосредственно после своего създавания (напомним, что отношение может перемещаться из одного узла в другой при изпълнении операции MIGRATE). В запросе на SQL можно използовать системные имена обектов, но разрешается използовать и короткие локалние имена (либо локальное имя, квалифицированное именем потребителя). При этом възможны две интерпретации локального имени. Оно может интерпретироваться как часть системного имени, и в этом случае по умолчанию дополняется до системного, исходя из идентификатора узла, в котором се извършва компилация, и идентификатора потребителя, от имени которого она се извършва (ако имя потребителя не указано явно). Вторая възможная интерпретация локального имени заключается в рассмотрении его как имени ранее определенного синонима системного имени. За определения синонимов SQL расширен оператором вида DEFINE SYNONYM При изпълнении такого предложения в локалний каталог заносится съответствующая информация. Таким образом, при компилации запроса всегда можно определить системные имена всех употребляемых в нем отношений: либо они явно указаны, либо могут быть получены на основе информации из локалних отношений-каталогов. Концепция разпределеного каталога System R* основана на наличии у каждого обекта разпределеной базы от данни уникального системного имени. Принято следующее соглашение: информация о размещении любого обекта базы от данни (идентификатор текущего узла, в котором размещен обект) сохраняется в локальном каталоге того узла, в котором обект располагался непосредственно после създавания (родового узла). Следовательно, за получения полной информации об отношении в общем случае необходимо сначала воспользоваться локалним каталогом узла, в котором происходит компилация, затем обратиться к отдалеченому каталогу родового узла данного отношения и в заключение воспользоваться каталогом текущего узла. Таким образом, за получения точной системной информации о любом отношении разпределеной базы от данни может потребоваться самое большее два отдалеченых достъпа к отношениям-каталогам. Применяется някоиая оптимизация этой процедуры. В локальном каталоге узла могут храниться копии елементов каталога других узлов (своего рода кэш-каталог). Съгласуваност копий елементов каталога не поддържася. Эта информация използуется на первой стадии компилации запроса (мы рассматриваем разпределеную компилацию в следующем подразделе), а затем, на второй стадии, ако информация, касающаяся някоиого обекта, оказалась неточной, она уточняется на основе локального каталога того узла, в котором обект хранится в настоящее время. Обнаружение некоректности копии елемента каталога се извършва за счет наличия при каждом елементе каталога номера версии. Ако учесть достаточную инерционность системной информации, эта оптимизация может оказаться същественой. 20.2.2. Разпределеная компилация заявкитеКак мы уже отмечали, заявки на езике SQL до своего реального изпълнения подвергаются компилации. Как и в случае System R компилация запроса может производиться на стадии прекомпилации приложной програмы, написанной на традиционном езике програмирования (PL/1, Cobol, ассемблер) с включением предложений SQL, или в динамике изпълнения транзакции при изпълнении предложения PREPARE. С гледна точка потребителей процес компилации в System R* приводит к тем же резултатам, что и в System R: за каждого предложения SQL образуется програма к машинных кодах (секция модуля достъпа), извикванеы которой помещаются в текст исходной приложной програмы. Однако, в действительности процес компилации запроса в System R* намного более сложен, чем в System R, что и естественно по причине гораздо более сложных мрежови взаимодействий, които потребуются при реальном изпълнении транзакции. Разпределеная компилация заявките в System R* включает множество технических ухищрений и тонкостей. Мы не будем касаться их всех в этой статье по причинам недостатка информации и ограниченности объема. Рассмотрим только общую схему разпределеной компилации. Будем называть главным узлом тот узел мрежа, в котором инициирован процес компилации предложения SQL, и дополнительными узлами - те узлы, които вовлекаются в этот процес в ходе его изпълнения. На самом грубом уровне процес компилации можно разбить на следующие фазы:
20.2.3. Управление транзакциями и синхронизацияИзпълнение транзакции в разпределеной системе управления базами от данни System R*, естественно, является разпределеным. Транзакция начинается в главном узле при обращении к какой-либо секции ранее подготовленного (на этапе компилации) модуля достъпа. Как и в System R, модуль достъпа загружается в виртуальную паметь задачи, обращение к секции модуля достъпа - это извикване подпрограмы. Однако, в отличие от System R, эта подпрограма, кроме своего локального програмного кода и извикванеов функций RSS, съдържит еще и извикванеы отдалеченых подсекций модуля достъпа. Эти извикванеы интерпретируются в духе извикванеов отдалеченых процедур. Тем самым изпълнение одной транзакции, инициированной в някоиом узле мрежа A влечет, вообще говоря, инициирование транзакций в дополнительных узлах. Основной новой по сравнению с System R проблемой является проблема съгласуваного завершения разпределеной транзакции, чтобы резултаты ее изпълнения во всех затронутых ею узлах были либо изобразены в состояние локалних баз от данни, либо напълно отсутствовали. За достижения этой цели в System R* използуется двухфазный протокол завершения разпределеной транзакции. Этот протокол является общеупотребимым в разпределеных системах баз от данни и описан во многих литературных источниках. Поэтому мы здесь опишем его очень кратко и неформально. За описания протокола използуется следующая модель. Имеется ряд независимых транзакций-участников разпределеной транзакции, выполняющихся под управлением транзакции-координатора. Решение об окончании разпределеной транзакции принимается координатором. После этого изпълнявася первая фаза завершения транзакции, когато координатор передает каждому из участников сообщение "подготовиться к завершению". Получив такое сообщение, всеки участник переходит в состояние готовности как к немедленному завершению транзакции, так и к ее откату. В терминах System R* это означает, что буфер журнала с записями об изменениях базы от данни участника выталкиваются на внешнюю паметь, но синхронизационные захваты не снимаются. После этого всеки участник, успешно выполнивший подготовительные действия, посылает координатору сообщение "готов к завершению". Ако координатор получает такие сообщения ото всех участников, то он начинает вторую фазу завершения, рассылая всем участникам сообщение "завершить транзакцию", и это считается завершением разпределеной транзакции. Ако не все участники успешно выполнили первую фазу, то координатор рассылает всем участникам сообщение "откатить транзакцию", и тогда эффект воздействия разпределеной транзакции на состояние баз от данни отсутствует. По отношению к особенностям реализации двухфазного протокола завершения транзакции в System R* заметим еще следующее. В качестве координатора выступает транзакция, выполняющаяся в главном узле, т.е. та, по инициативе которой возникли дополнительные транзакции. Тем самым, наличие центрального координирующего узла не требуется, что съответствует изискваню автономности узлов. За откатов транзакций използуется базовый механизм точек сохранения System R. Наконец, классический протокол двухфазного завершения оптимизирован, чтобы сократить число необходимых сообщений. Как и в System R, съгласуваност состояния баз от данни при паралелном изпълнении нескольких транзакций в System R* обеспечивается на основе механизма синхронизационных захватов обектов базы от данни при съблюдении двухфазного протокола захватов. Напомним, что это означает разбиение каждой транзакции с гледна точка синхронизации на две фазы - рабочую фазу, на которой захваты только устанавливаются, и фазу завершения, когато все захваты обектов базы от данни, произведенные данной транзакцией, снимаются. Синхронизация се извършва в точности так же, как и в System R: каждая транзакция-участник обращается к локальной базе от данни через RSS своего узла. Основной новой проблемой является проблема възможных разпределеных взаимоблокировков, които могут возникнуть между несколькими разпределеными транзакциями, выполняющимися паралелно. (Взаимоблокировки между транзакциями - участниками одной разпределеной транзакции невъзможны, поскольку все участники получают один общий идентификатор транзакции и не конфликтуют по синхронизации). За обнаружения разпределеных синхронизационных взаимоблокировков в System R* применяется оригинальный разпределеный алгоритм, не нарушающий изискваня автономности узлов мрежа и минимизирующий число передаваемых по мрежа сообщений и необходимую процесорную обработку. Основная идея алгоритма състои в том, что в каждом узле периодически се извършва анализ на предмет съществования взаимоблокировка с използованием информации о связях транзакций по ожиданию ресурсов, локальной в данном узле и полученной от других узлов. При проведении этого анализа обнаруживаются либо циклы ожиданий, что означает наличие взаимоблокировка, либо потенциальные циклы, които необходимо уточнить в других узлах. Эти потенциальные циклы представляются в виде специального вида строк. Строка представляет собой по сути дела список транзакций. Все транзакции упорядочены в съответствии со значениями своих идентификаторов ("номеров транзакций"). Строка передается за дальнейшего анализа в следующий узел (узел, в котором изпълнявася самая правая в строке транзакция) только в том случае, ако номер первой транзакции в строке меньше номера последней транзакции. (Это оптимизация, уменьшающая число передаваемых по мрежа сообщений). Этот процес продолжается до обнаружения взаимоблокировка. Ако обнаруживается наличие синхронизационного взаимоблокировка, он разрушается за счет унищожения (отката) одной из транзакций, входящей в цикл. В качестве жертвы выбирается транзакция, выполнившая к этому моменту наименьший объем работы. Эта информация также передается по мрежа вместе со строками, описывающими связи транзакций по ожиданию.
Основной задачей интеграции неоднородных БД является предоставление потребителям интегрированной системы глобальной схемы БД, представленной в някоиой модели от данни, и автоматическое преобразование операторов манипулирания БД глобального уровня в операторы, понятные съответствующим локалним СУБД. В теоретическом плане проблемы преобразования решены, имеются реализации. При строгой интеграции неоднородных БД локалние системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку потребители часто не соглашаются утрачивать локальную автономность, желая тем не менее иметь възможность работать со всеми локалними СУБД на одном езике и формулировать заявки с одновременным указанием разных локалних БД, развивается направление мульти-БД. В системах мульти-БД не поддържася глобальная схема интегрированной БД и применяются специалние способы именования за достъпа к обектам локалних БД. Как правило, в таких системах на глобальном уровне допускается только выборка от данни. Это позволяет сохранить автономность локалних БД. Как правило, интегрировать приходится неоднородные БД, разпределеные в вычислительной мрежа. Это в значительной степени усложняет реализацию. Дополнительно к собственным проблемам интеграции приходится решать все проблемы, присущие разпределеным СУБД: управление глобальными транзакциями, сетевую оптимизацию заявките и т.н. Очень трудно добиться эффективности. Как правило, за внешнего представления интегрированных и мульти-БД използуется (иногда расширенная) релационная модель от данни. В последнее время все чаще предлагается използовать обектно-ориентированные модели, но на практике пока основой является релационная модель. Поэтому, в частности, включение в интегрированную систему локальной релационной СУБД съществено проще и эффективнее, чем включение СУБД, основанной на другой модели от данни.
Каталог: tadmin -> upload -> storage storage -> Литература на факта. Аналитизъм. Интерпретативни стратегии. Въпроси и задачи storage -> Лекция №2 Същност на цифровите изображения Въпрос. Основни положения от теория на сигналите storage -> Лекция 5 система за вторична радиолокация storage -> Толерантност и етничност в медийния дискурс storage -> Ethnicity and tolerance in media discourse revisited Desislava St. Cheshmedzhieva-Stoycheva abstract storage -> Тест №1 Отбележете невярното твърдение за подчертаните думи storage -> Лекции по Въведение в статистиката storage -> Търсене на живот във вселената увод storage -> Еп. Константинови четения – 2010 г някои аспекти на концептуализация на богатството в руски и турски език Изтегляне 1.71 Mb. Сподели с приятели:
|