Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Пример 2: телефонная книга. Распределённое хранение

Представим себе учреждение, которое состоит из нескольких филиалов, в том числе имеет филиалы в других городах. Примером такого учреждения является УЦВТ – Учебный центр вычислительной техники. Компьютерная связь осуществляется по стандартным телефонным линиям. На сервере, обслуживающем главный филиал, хранится файл с телефонами сотрудников (электронная таблица, простая база данных или текстовый документ). У сотрудников должна быть возможность:

• пользоваться телефонной книгой (ТК);
• вносить в неё дополнения и исправления.

Все возможные решения представляют собой компромисс между оперативностью и снижением денежно-временных затрат на связь. Абсолютно тупиковым является «бескомпромиссный» вариант, когда ТК хранится только на центральном сервере и для каждого её использования извне требуется устанавливать телефонное соединение с главной площадкой.

Если же пользователь время от времени копирует телефонную книгу к себе на компьютер (через Internet, прозванивается напрямую, приносит на дискете), его копия книги периодически устаревает и нуждается в обновлении. Он должен сам заботиться о своевременном обновлении личной копии, а также о поиске оптимального пути для такого обновления. Например, сотрудникам, работающим в другом городе, имеет смысл договориться, что ездить на главную площадку или прозваниваться по междугородней связи модемом на центральный сервер будет кто-то один из них, а остальные сотрудники, если только им не придется ехать/звонить на главную площадку по другим делам, будут забирать свежии копии у него.

Наряду с этим имеет место и встречное движение: сотрудники заносят в ТК новые сведения (например, телефоны клиентов), удаляют ненужные записи и исправляют неверные. Они изменяют свои собственные копии ТК, из которых изменения так или иначе должны попасть в центральный экземпляр ТК на главном сервере.

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

Пусть два компьютера устанавливают соединение, чтобы синхронизировать свои экземпляры ТК. В этот момент должны быть выполнены следующие действия:

• если документ был добавлен или изменён в экземпляре A,
  он должен быть скопирован в экземпляр B; и наоборот;
• если документ был удалён из экземпляра A,
  он должен быть удалён из экземпляра B; и наоборот;
• если над одним и тем же документом были совершены несовместимые действия (например, отредактирован и в базе A, и в базе B), оба изменения должны быть запомнены в обоих экземплярах ТК для последующего ручного редактирования рассогласований.

Описанный механизм синхронизации содержимого реализован в Lotus Notes. Он получил название репликация (replication). Копия, снятая с исходной базы данных, называется реплика (replica). ^[2] Процесс снятия копии называется реплицирование. СУБД, умеющую создавать, синхронизировать и использовать более одного экземпляра данных на разных компьютерах сети, принято называть распределённой.