2.1.1. Принцип горизонтальной фрагментации данных

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

Рисунок 1. Горизонтальная фрагментация

2.1.2. Пример горизонтальной фрагментации данных

На рисунке 2 приведен пример горизонтальной фрагментации.

Рисунок 2. Пример горизонтальной фрагментации

2.1.3. Принцип вертикальной фрагментации данных

При вертикальной фрагментации отношение делится на разделы при помощи операции проекции. Например, один раздел отношения Employee может содержать поля:

Номер_сотрудника (emp_id),

ФИО_сотрудника (emp_name),

Адрес_сотрудника (emp_adress),

а другой – поля Номер_сотрудника (emp_id),

Оклад (salary),

Руководитель (emp_chief).

Тогда запрос «получить информацию о заработной плате сотрудников компании» будет выглядеть следующим образом:

SELECT employee.emp_id,

emp_name,

salary

FROM employee@donetsk,

employee@kiev

ORDER BY emp_id

2.1.4. Пример вертикальной фрагментации данных

На рисунках 3 и 4 изображены сущность и пример вертикальной фрагментации.

Рисунок 3. Вертикальная фрагментация

Рисунок 4. Пример вертикальной фрагментации

2.1.5. Преимущества и недостатки

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

2.2. Репликация данных

Второй способ распределения данных – репликация (рис.5). Репликация (или тиражирование) означает создание дубликатов данных.

Репликаты – это множество различных физических копий некоторого объекта базы данных (обычно таблицы), для которых поддерживается синхронизация (идентичность) с некоторой "главной" копией.

Рисунок 5. Репликация

2.2.1 Тиражирование

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

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

2.2.2 Модели тиражирования

На рисунках 7, 8, 9 показаны различные модели тиражирования.

Рисунок 7. Одновременное обновление (с управлением параллелизмом)

Рисунок 8. Распространенные обновления

Рисунок 9. Запланированная синхронизация дубликатов только для чтения

2.2.3 Модели тиражирования

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

В современных СУБД функции репликации выполняет, как правило, специальный модуль – сервер тиражирования данных, называемый репликатором (так устроены СУБД CA – OpenIngress и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle для использования репликации необходимо приобрести дополнительную опцию Replication Option.

Спецификация механизмов репликации зависит от используемой СУБД. Простейший вариант – использование «моментальных снимков» (snapshot).