АкушерствоАнатомияАнестезиологияВакцинопрофилактикаВалеологияВетеринарияГигиенаЗаболеванияИммунологияКардиологияНеврологияНефрологияОнкологияОториноларингологияОфтальмологияПаразитологияПедиатрияПервая помощьПсихиатрияПульмонологияРеанимацияРевматологияСтоматологияТерапияТоксикологияТравматологияУрологияФармакологияФармацевтикаФизиотерапияФтизиатрияХирургияЭндокринологияЭпидемиология

Примеры распределённых систем

Прочитайте:
  1. A. система сбора, обработки и хранения и выдачи информации о техническом состоянии недвижимого имущества
  2. B) Вторичная капиллярная сеть портальной системы гипоталамо-аденогипофизарного кровообращения,
  3. B) Вторичная капиллярная сеть портальной системы гипоталамо-аденогипофизарного кровообращения,
  4. E. четырьмя буферными системами плазмы крови
  5. Fl-адренергическая система
  6. Fl-адренергическая система
  7. I. Компоненты систем
  8. I. НЕЙРОЭНДОКРИННЫЕ КЛЕТКИ НЕРВНОЙ СИСТЕМЫ
  9. I. Средства, уменьшающие стимулирующее влияние адренергической иннервации на сердечно-сосудистую систему (нейротропные средства)
  10. I. Схема кровотока в кортикальной системе

В конце 70-х – начале 80-х годов была создана система SDD-1.
UCB –- начало 80-х: DistributedINGRES
Oracle
DB2

Замечание: все перечисленные примеры – реляционные СУБД.

Ряд причин, обуславливающих это обстоятельство.

Фундаментальный принцип построения распределённой БД:

Для пользователя распределённая система должна выглядеть в точности как нераспределённая. Изложенный фундаментальный принцип приводит к следующим требованиям:
1) Локальная автономия
2) Независимость от центрального узла
3) Непрерывное функционирование
4) Независимость от расположения
5) Независимость от фрагментации
6) Независимость от репликации
7) Обработка распределённых запросов
8) Управление распределёнными транзакциями
9) Независимость от аппаратного обеспечения
10) Независимость от ОС
11) Независимость от сети
12) Независимость от СУБД

Эти 12 принципов не являются независимыми друг от друга, не все они равнозначны. Ими не исчерпывается перечень всех возможных целей, которые могут стоять при создании распределённой БД.

Можно разделить просто системы с удалённым доступом данных, в которой пользователь может работать с данными, полученными из различных удалённых источников, но при этом видны все соединения; и "истинные" распределённые СУБД: все соединения скрыты.

1) Локальная автономия – операции на данном узле управляются этим узлом. Функционирование узла не зависят от успешного выполнения некоторых операций на любом другом узле. Владение и управление данными осуществляются локально, с локальным ведением учёта. Безопасность, целостность и структура хранения локальных данных остаётся под юрисдикцией данного локального узла.
Абсолютное следование данному принципу невозможно: в некоторых ситуациях необходимо вмешательство главного узла. Но всё равно следует стремиться к максимально возможной реализации локальной автономии.

2) Независимость от центрального узла – все узлы рассматриваются как равные (главного центра управления нет). В случае полной реализации локальной автономии следует независимость. Но даже в случае неполной реализации локальной автономии независимость от центра возможна.

3) Непрерывное функционирование – обеспечение надёжности и доступности. Работа системы продолжается, пусть и на более низком уровне даже в случае падения узла.
Доступность возрастает частично по этой причине, частично из-за репликации данных.

4) Независимость от расположения позволяет осуществлять миграцию данных от узла к узлу.

5) Независимость от фрагментации. В системе поддерживается фрагментация данных, если некоторое хранимое отношение физически хранится частично на одном узле, частично на другом (или других). Эти части называются фрагментами. Фрагментация полезна с точки зрения производительности. Данные могут храниться там, где они чаще используются.

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

В истинно распределённой СУБД легко осуществить перераспределение, в случае изменения и падения производительности.

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

7) Обработка распределённых запросов.
Две важные проблемы
1. Проблема количества пересылаемых данных
2. Проблема оптимизации маршрута доставки данных.

При выполнении охватываются несколько узлов запроса, существует несколько способов пересылки данных по сети.

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


Дата добавления: 2015-09-18 | Просмотры: 523 | Нарушение авторских прав



1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 |



При использовании материала ссылка на сайт medlec.org обязательна! (0.004 сек.)