8.2.4. Смешанная стратегия

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

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

8.3. Методы проектирования распределенной бд

8.3.1. Общий подход к проектированию распределенных бд

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

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

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

• подмножество расчлененных таблиц БД (разделов);

• размер каждого раздела;

• модели и частоты использования приложений.

Рассмотрим каждый из этих классов и обсудим вопросы, связанные с ними. Первым этапом является расчленение глобальной БД на множество подфайлов {F₁,…,F_n}. При этом требуется, чтобы расчлененные подфайлы содержали ту же информацию, что и глобальная БД. Число подфайлов n должно соответствовать числу локальных баз данных в ИС. Помимо требования о целостности информации, на разделы накладывается требование совместимости ограничений. Совместимость структуры БД дает возможность проектировать составные блоки (агрегаты) из всех структурно допустимых разделов. Минимальными составными блоками в реляционных СУБД являются кортежи (экземпляры записей).

Отметим основные причины ограничений на процесс формирования разделов из составных блоков. Это допустимый размер, определяемый объемом дисковой памяти, и производительность. Оценка производительности должна определяться с учетом времени отклика и надежности системы. Целесообразно объединить в подфайл наиболее часто совместно используемые записи – в этом случае будут улучшаться характеристики отклика системы. Для получения требуемого уровня надежности следует использовать наименьшую из возможных кратностей дублирования.

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

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

1. Приложение, использующее единственный файл.

2. Приложение, использующее несколько файлов.

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

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

Следующий этап на рисунке 8.2 – этап размещения БД. Расчленение БД является неотъемлемой частью задачи размещения. На этапе расчленения используется столько ограничений, сколько необходимо при решении конкретной задачи, чтобы сузить класс допустимых расчленений. Тем не менее, в общем случае на этапе 4 выбор единственного расчленения невозможен. Для получения лучшей структуры этап размещения повторяется для каждого расчленения, полученного на этапе 4. Этот процесс длится до тех пор, пока не будет получен удовлетворительный вариант или не будут исчерпаны варианты расчленений.