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

Горизонтальная репликация таблиц

Распределить таблицу по сети можно следующим образом: разделить таблицу горизонтально, помещая полученные блоки записей в разные системы. На рис. 22.5 изображен простой пример, когда требуется горизонтальное разделение таблицы. Здесь компания имеет три дистрибьюторских центра, в каждом из которых предлагаются свои группы товаров, выполняется собственная обработка заказов и имеется база данных товарных запасов.

Чикаго

Нью-Йорк

Таблица PRODUCTS

Рис. 22.5. Горизонтальная реплякация

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

Большинство обновлений таблицы products выполняется в дистрибьюторских Ценграх в процессе обработки заказов. Поскольку реплики таблицы products в каждом центре независимы друг от друга (любая строка таблицы может входить только в одну реплику), конфликты обновлений невозможны. Все изменения реплик могут периодически пересылаться в центральную базу данных, чтобы в ней была представлена актуальная информация.

Вертикальная репликация таблиц

Другой способ распределения таблицы по сети состоит в вертикальном разделении таблицы и размещении ее столбцов в разных системах. На рис. 22.6 приведен Простой пример вертикального разделения таблицы. Таблица Salesreps была расширена новыми столбцами с информацией о служащих (номер телефона, семейное

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

Вычислительная система отдела кадров

Вычислительная система отдела обработки заказов

Таблица SALESBEPS

Рис. 22.6. Вертикальная рефикафя * <,

Для реализации этой схемы таблица salesreps целиком реплицируется в обе системы, но логически считается разделенной вертикально на две части. Столбцы таблицы, содержащие личные данные (name, age, hire date, phone, married), принадлежат базе данных отдела кадров. Любые конфликты, связанные с обновлением этих столбцов, решаются в пользу отдела кадров. Остальные столбцы (empl NUM, quota, sales, REP 0FFICE) принадлежат базе данных отдела обработки заказов. В его пользу решаются и конфликты в отношении этих столбцов. Поскольку в обеих базах данных имеется полная копия таблицы, можно создавать по ней отчеты и обращаться к ней с запросами, причем вся обработка будет производиться локально. Только при обновлениях задействуется механизм репликации, возникает сетевой трафик и возможно возникновение конфликтов.

Зеркальная репликация таблиц

Когда репликация необходима для обеспечения высокой отказоустойчивости системы (чтобы система могла продолжать свою работу в случае аппаратных сбоев или сбоев в базе данных), создается зеркальная копия всей таблицы (рис. 22.7). В простейшей конфигурации одна база данных становится активной , а другая - резервной . Все запросы направляются к активной базе данных (система А), которая посылает реплики всех изменений резервной базе данных (система Б). В случае сбоя запросы перенаправляются в резервную систему, которая содержит свежие данные. Недостатком такого подхода является то, что при нормальной работе без сбоев ресурсы резервной системы тратятся впустую. Эту систему необходимо обслуживать и оплачивать, хотя она не участвует в обработке данных.

Система А

Копии таблицы X

Система В

Таблица X

Рис. 22.7. Зеркальная ретикация

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

Добавление/обновление/выборка

Сервер приложений

Программа распределения нагрузки

Сервер J данных

СУБД

к

СУБД

Сервер баз данных

Реплицированная таблица

Многоуровневая репликация

Реплицированная таблица

Рис. 22.8. Репликация с регуляцией нагрузки