Фрагментация. Основные концепции фрагментации данных. Виды фрагментации.

Фрагментация – процесс, посредством которого объекты базы данных разбиваются на части и распределяются по отдельным узлам.

Объект может представлять собой плз. БД, системную БД или таблицу.

В распределенной системе возможны три вида фрагментации:

1. горизонтальная

2. вертикальная

3. смешанная

Горизонтальная фрагментация

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

· Каждый фрагмент хранится на отдельном узле.

· Каждый фрагмент имеет уникальные строки.

· Все уникальные строки имеют одинаковые атрибуты (столбцы).

· Каждый фрагмент эквивалентен оператору SELECT с модифицирующим выражением WHERE по единственному атрибуту.

Вертикальная фрагментация

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

· Каждый фрагмент хранится на отдельном узле.

· Каждый фрагмент имеет уникальные столбцы – за исключением ключевого столбца, который имеется во всех фрагментах.

· Это эквивалентно применению оператора PROJECT.

Смешанная фрагментация

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

Пример.

Предположим, что имеется таблица EMP (сотрудники), в которой есть следующие атрибуты:

EMP_NUM

EMP_SURNAME

EMP_DATA

EMP_ADDRESS

EMP_DEPARTMENT

EMP_SALARY

Горизонтальная фрагментация

Руководству компании необходима информация о сотрудниках по каждому подразделению (DEPARTMENT) компании: Минск, Киев, Москва. Но каждому подразделению компании необходима информация только по своим локальным сотрудникам.

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

Вертикальная фрагментация

У компании есть два отдела: отдел обслуживания и отдел приема платежей. Каждый отдел расположен в отдельном здании и каждому отделу необходима информация только по нескольким атрибутам таблицы.

Отделу обслуживания – по атрибутам EMP_SURNAME, EMP_DATA, EMP_ADDRESS, EMP_DEPARTMENT

Отделу приема платежей – по атрибуту EMP_SALARY.

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

 

Репликация. Понятие согласованного распределенного набора данных. Варианты репликации. Протокол репликации ROWA.

Репликация (тиражирование) данных (Data Replication – DR) – это хранение одних и тех же данных (копий) в нескольких узлах.

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

Функции репликации выполняет специальный модуль СУБД – сервер тиражирования данных, называемый репликатором (replicator). Его задача – поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД.

Основное понятие – понятие согласованного распределенного набора данных (consistent distributed data set – CDDS). Это набор данных, идентичность которого поддерживается репликатором во всех узлах, вовлеченных в процесс тиражирования.

§ CDDS должен подчиняться правилу взаимной непротиворечивости, которое требует, чтобы все копии фрагментов данных были идентичны

Возможны три варианта репликации БД. БД может быть:

1. полностью реплицированной – если копии одного и того же фрагмента данных располагаются на всех узлах сети; все фрагменты реплицированы.

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

3. нереплицированной – каждый фрагмент хранится на отдельном узле. Дублированные фрагменты отсутствуют.

На репликацию влияет несколько факторов:

1. размер БД;

2. частота использования БД;

3. затраты, связанные с синхронизацией транзакций и их частей.

Тиражировать можно:

1. всю БД;

2. избранные объекты БД: таблицы или представления;

3. вертикальные проекции объектов БД: избранные столбцы таблиц и/или представлений;

4. горизонтальные проекции объектов БД: избранные строки таблиц и/или представлений;

5. сочетания наборов 2-4.

Где тиражируют? Основные схемы тиражирования:

· "Центр – филиалы", изменения в базах данных филиалов переносятся в центральную БД, и/или наоборот;

· равноправное, несколько БД разделяют общий набор изменяемых и тиражируемых данных;

· каскадное, изменения в одной БД переносятся в другую БД, откуда в свою очередь в третью БД и т.д.;

· через шлюзы изменения в БД могут переноситься в БД другой СУБД (неоднородная БД);

· различные комбинации всех вышеперечисленных схем.

Протоколы репликации

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

Типичный протокол тиражирования, обеспечивающий сериализуемость по критерию полной эквивалентности копий, известен под названием ROWA (Read-Once/Write-All – одно чтение, запись во все копии).

Задача протокола тиражирования – отобразить операции доступа к некоторому элементу х на множества операций над физическими копиями x (x1, x2,..., xn).

Протокол ROWA отображает чтение x Read(x) на операцию чтения какой-либо из копий x Read(xi). Из какой именно копии будет производиться чтение, неважно – этот вопрос может решаться из соображений эффективности. Каждая операция записи в логический элемент данных x отображается на множество операций записи во все физические копии x.

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