Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

HTML интерпретатор анализирует документ, если встречает апплет, то браузер обращается к веб-серверу с запросом на чтение соответствующей Java программы. Эта программа загружается на рабочую станцию и интерпретируется Java машиной.

Если встречается SQL оператор, то через JDBC идёт обращение к серверу БД. Результаты выполнения запросов возвращаются в Java программу, и она выводит результаты в браузер.

Преимущества Java:

• программа выполняется на рабочей станции. Неожиданно это стало преимуществом;

• Java апплеты мобильны, язык гибок для написания сложных программ;

• JDBC интерфейс является универсальным, SQL внутри Java не зависит от СУБД;

• большое количество открытых Java программ.

Недостатки Java:

• Java программы передаются по сети, поэтому они должны быть небольшими, что накладывает ограничение на функционал;

• пользователь с подозрением относится к выполняемым на его рабочей станции прилетевшим из интернетов Java программам;

• Java программы работают медленее, чем бинарный код;

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

Как и Java апплеты, объекты ActiveX загружаются на рабочую станцию. В управляющие элементы могут быть включены SQL операторы. Но в отличие от Java, в ActiveX выполняется бинарный код (то есть, они быстрее). Недостатком является Microsoft - ActiveX работает только на платформе MS Windows.

Интероперабельные системы

Методы доступа к разнородным СУБД.

В настоящее время для этого используются:

• шлюзы;

• ODBC и его аналоги;

• XML и веб-сервисы.

Шлюзы

Схема объединения разнородных систем с помощью шлюза:

Опишем организацию доступа приложения Oracle к серверу Informix.

Если в этом приложении встречается SQL оператор, то он передаётся на сервер Oracle. Если таблицы, указанные в этом операторе, хранятся на сервере Oracle, но оператор выполняется, и результаты возвращаются на рабочую станцию. Если указаны таблицы сервера Informix, то Oracle обращается к этом серверу через шлюз и там всё как раньше.

По той же схеме осуществляется доступ приложения Informix к серверу Oracle.

ODBC

При выполнении приложения встречается SQL оператор, происходит обращение к менеджеру драйверов, тот выбирает соответствующий драйвер, и происходит обращение к серверу БД. Результаты потом обратно на рабочую станцию, как обычно.

Обращение к ODBC в Windows:

1. с помощью функции SQL_CONNECT приложение подключается к серверу БД. Несколько серверов - несколько операторов;

2. в строковой переменной подготавливается SQL оператор;

3. с помощью функции SQL_EXECUTE происходит выполнение этого SQL оператора;

4. если было возвращено несколько записей, то необходимо организовать цикл, в котором с помощью функции SQL_FETCH будет выбираться очередная запись.

Лекция №14 - Анализ и выбор архитектуры (продолжение)

Анализ и выбор архитектуры распределённой системы

Интероперабельные системы

Веб-сервисы

Пример разработок Microsoft:

Надо сказать, что ADO.NET уже считается устаревшим. На смену ему стали использоваться, например, LINQ (без языка запросов) и LINQ to SQL.

Пользователь читает из каталогов информацию о веб-сервисах и формирует XML-сообщение для доступа к нужному сервису. Результаты обращения возвращаются также в XML виде.

Тиражирование данных

Или репликации. Это автоматическое копирование изменённых данных с одного сервера на другой.

Плюсы тиражирования:

• увеличивается производительность системы - пользователям из одного города для получения котировок из другого города достаточно обратиться к своему локальному серверу, а не к удалённому в другом городе;

• надёжность - если один сервер вышел из строя, то ничего страшного, полная копия данных имеется и на другом сервере.

Зачем нужно тиражирование

Изменения котировок на московской бирже обязательно должны реплицироваться на сервера питерской биржи и наоборот.

Классификация способов тиражирования

Следующие способы:

• традиционная (снимки);

• усовершенствованная:

  • синхронная;

  • асинхронная:

    • пакетная;

    • на уровне записей:

      • без конфликтов (одна Master реплика, остальные ReadOnly);

      • с обнаружением конфликтов:

        • с ручным разрешением конфликтов;

        • с автоматическим разрешением конфликтов.

Тиражирование на основе снимков

Описание канала связи:

CREATE DATABASE LINK имя_канала

CONNECT TO имя_пользователя

IDENTIFIED пароль

USING спецификация_описание_узла_сервера_БД;

Описание снимка:

CREATE SNAPSHOT имя_снимка

REFRESH FAST|COMPLETE

-- снимок на сервере 2 будет обновляться каждые 7 дней с момента даты создания снимка

NEXT Sysdate+7

-- оператор SELECT автоматически пересылается на удалённый сервер БД при запросе обновления

SELECT * FROM имя_пользователя.таблица@имя_канала;

Синхронная и асинхронная репликация

Транзакция - совокупность изменений в БД, которая должна быть выполнена вся или ни одного. Атомарное обновление.

Действия, выполняемые системой для синхронной и асинхронной репликации разные.

Синхронная - фиксация изменений на серверах БД выполняется в две фазы:

1. опрашиваются все серверы, участвующие в транзакции, на предмет того, готовы ли они зафиксировать изменения. Если хоть один отказался, то всем рассылается ROLLBACK;

2. если все серверы дали положительный ответ, то им высылается COMMIT.

Асинхронная - изменения передаются на серверы БД по мере их готовности. Если какой-либо сервер не готов принять изменения, то они сохраняются в глобальном координаторе, которые затем будут ему переданы, когда он будет готов.

Асинхронная на уровне записей без конфликтов

UPDATE котировка

SET продажа = 31, покупка = 30

WHERE код_ценной_бумаги = 0;

Перед обновлением на клиенте выполняется команда "начать транзакцию". Все изменения в БД отражаются в журнале изменений - записи до и после обновления. По оператору "конец транзакции" выполняются следующие действия:

1. запускается менеджер журнала изменений, который читает записи транзакции после обновления и передаёт их репликационному серверу;

2. репликационный сервер для каждой записи транзакции по имени таблицы, имени ключевого атрибута а также по диапазону ключей ищет соответствующую строчку в таблице публикаций. Для нашего примера будет найдена первая строчка;

3. из таблицы Подписка определяются серверы, которые подписались на эту публикацию (у нас это сервер 2);

4. соответствующая запись тиражируется на подписавшиеся серверы.

Лекция №15 - Анализ и выбор архитектуры (продолжение)

Анализ и выбор архитектуры распределённой системы

Интероперабельные системы

Асинхронная на уровне записей без конфликтов

В рамках технологии существуют различные методы (не способы):

1. тиражирование из первичного (где разрешается изменять данные) сервера во вторичные (где только ReadOnly);

2. тиражирование из первичного сервера и его резервов;

3. поточная модель тиражирования данных;

4. иерархическая модель.

Из первичного во вторичный

Все изменения тиражируются с первичного на вторичные серверы в соответствии с подпиской.

Преимущества:

• позволяет избежать дублирования и зацикливания. В принципе, все реплики можно сделать первичными, если снабдить каждое обновление временной меткой;

• обеспечивает целостность БД, так как первичный сервер выполняет распространение изменение всей транзакции.

Данный метод реализован практически во всех СУБД.

Из первичного сервера или его резервов

Резервный сервер работает в режиме "горячей" замены первичного. Он отслеживает его состояние, опращивая его по специальному кабелю.

И первичный, и резервный сервер имеют одинаковый MAC-адрес сетевого адаптера, и этот адаптер работает на приём. Но передавать данные может только один.

Преимущество:

• повышается надёжность системы при аппаратном сбое первичного сервера.

Недостаток:

• не спасает от программных сбоев, так как ошибки на первичном сервере дублируются на резервный.

Поточная модель тиражирования данных

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

Предположим, что основной поток изменений связан с сервером из Питера. Очевидно, что для снижения нагрузки на сеть лучше сделать его первичным.

Обновление таблицы клиентами на вторичном сервере

На рабочей станции инициируется выполнение хранимой процедуры с некоторыми параметрами. Процедура запускается на вторичном сервере (1). Она имеет пустое тело: вход и выход.

Но на вторичном сервере выполнена подписка сервера БД 1 на эту процедуру обновления. В соответствии с этой подпиской автоматически запускается процедура обновления на первичном сервере (2). Эта процедура уже имеет непустое тело.

Процедура выполняется, происходит обновление данных в таблице (3). Но на эти обновления подписан сервере БД 2. В соответствии с этой подпиской, данные пересылаются из master-реплики в ReadOnly-реплику (4).

Иерархическая модель

Промежуточный репликационный сервер позволяет снизить нагрузку на низкоскоростную телекоммуникационную сеть.

Асинхронная пакетная репликация

Несколько шагов:

1. на удалённом первичном сервере администратор создаёт скрипты с описанием снимков;

2. скрипты рассылаются на серверы-подписчики;

3. эти же скрипты автоматически запускаются на серверах-подписчиках и выполняют обновление снимков.

Теорема CAP

Согласно её, можно создать распределённую систему, которая будет:

1. согласованной (consistent) - все операции, записи в реплике являются атомарными, и все последующие операции чтения из этой реплики видят новое значение;

2. доступной (avaible) - БД возвращает значение из реплик;

3. устойчивой к потере связанности (partition tolerant) - система может функционировать, если связи между группами узлов временно отсутствуют.

Но одновременно система может гарантировать только два из этих трёх свойств.

CA

Система, во всех узлах которой данные согласованы и обеспечена доступность, жертвует устойчивостью к распаду на секции. Примерами таких систем могут быть решения на основе кластерных систем управления базами данных или распределённая служба каталогов LDAP.

CP

Распределённая система, в каждый момент обеспечивающая целостный результат и способная функционировать в условиях распада, в ущерб доступности может не выдавать отклик. Устойчивость к распаду на секции требует обеспечения дублирования изменений во всех узлах системы.

AP

Распределённая система, отказывающаяся от целостности результата. Хотя системы такого рода известны задолго до формулировки принципа CAP (например, распределённые веб-кэши или DNS), рост популярности систем с этим набором свойств связывается именно с распространением теоремы CAP. Так, большинство NoSQL-систем принципиально не гарантируют целостности данных. Задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных.

64

Характеристики

Список файлов лекций