Все современные материнские платы оснащены интегрированным RAID-контроллером, а топовые модели имеют даже по нескольку интегрированных RAID-контроллеров. Насколько интегрированные RAID-контроллеры востребованы домашними пользователями - вопрос отдельный. В любом случае современная материнская плата предоставляет пользователю возможность создания RAID-массива из нескольких дисков. Однако далеко не каждый домашний пользователь знает, как создать RAID-массив, какой уровень массива выбрать, да и вообще плохо представляет себе плюсы и минусы использования RAID-массивов.
В этой статье мы дадим краткие рекомендации по созданию RAID-массивов на домашних ПК и на конкретном примере продемонстрируем, каким образом можно самостоятельно протестировать производительность RAID-массива.
История создания
Впервые термин «RAID-массив» появился в 1987 году, когда американские исследователи Паттерсон, Гибсон и Катц из Калифорнийского университета Беркли в своей статье «Избыточный массив недорогих дисков» (“A Case for Redundant Arrays of Inexpensive Discs, RAID”) описали, каким образом можно объединить несколько дешевых жестких дисков в одно логическое устройство так, чтобы в результате повышались емкость и быстродействие системы, а отказ отдельных дисков не приводил к отказу всей системы.
С момента выхода этой статьи прошло уже более 20 лет, но технология построения RAID-массивов не утратила актуальности и сегодня. Единственное, что изменилось с тех пор, - это расшифровка аббревиатуры RAID. Дело в том, что первоначально RAID-массивы строились вовсе не на дешевых дисках, поэтому слово Inexpensive (недорогие) поменяли на Independent (независимые), что больше соответствовало действительности.
Принцип действия
Итак, RAID - это избыточный массив независимых дисков (Redundant Arrays of Independent Discs), на который возлагается задача обеспечения отказоустойчивости и повышения производительности. Отказоустойчивость достигается за счет избыточности. То есть часть емкости дискового пространства отводится для служебных целей, становясь недоступной для пользователя.
Повышение производительности дисковой подсистемы обеспечивается одновременной работой нескольких дисков, и в этом смысле чем больше дисков в массиве (до определенного предела), тем лучше.
Совместную работу дисков в массиве можно организовать с помощью либо параллельного, либо независимого доступа. При параллельном доступе дисковое пространство разбивается на блоки (полоски) для записи данных. Аналогично информация, подлежащая записи на диск, разбивается на такие же блоки. При записи отдельные блоки записываются на разные диски, причем запись нескольких блоков на различные диски происходит одновременно, что и приводит к увеличению производительности в операциях записи. Нужная информация также считывается отдельными блоками одновременно с нескольких дисков, что тоже способствует росту производительности пропорционально количеству дисков в массиве.
Следует отметить, что модель с параллельным доступом реализуется только при условии, что размер запроса на запись данных больше размера самого блока. В противном случае осуществлять параллельную запись нескольких блоков практически невозможно. Представим ситуацию, когда размер отдельного блока составляет 8 Кбайт, а размер запроса на запись данных - 64 Кбайт. В этом случае исходная информация нарезается на восемь блоков по 8 Кбайт каждый. Если имеется массив из четырех дисков, то одновременно можно записать четыре блока, или 32 Кбайт, за один раз. Очевидно, что в рассмотренном примере скорость записи и скорость считывания окажутся в четыре раза выше, чем при использовании одного диска. Это справедливо лишь для идеальной ситуации, однако размер запроса далеко не всегда кратен размеру блока и количеству дисков в массиве.
Если же размер записываемых данных меньше размера блока, то реализуется принципиально иная модель - независимый доступ. Более того, эта модель может использоваться и в том случае, когда размер записываемых данных больше размера одного блока. При независимом доступе все данные отдельного запроса записываются на отдельный диск, то есть ситуация идентична работе с одним диском. Преимущество модели с независимым доступом в том, что при одновременном поступлении нескольких запросов на запись (чтение) все они будут выполняться на отдельных дисках независимо друг от друга. Подобная ситуация типична, например, для серверов.
В соответствии с различными типами доступа существуют и разные типы RAID-массивов, которые принято характеризовать уровнями RAID. Кроме типа доступа, уровни RAID различаются способом размещения и формирования избыточной информации. Избыточная информация может либо размещаться на специально выделенном диске, либо распределяться между всеми дисками. Способов формирования этой информации достаточно много. Простейший из них - это полное дублирование (100-процентная избыточность), или зеркалирование. Кроме того, используются коды с коррекцией ошибок, а также вычисление четности.
Уровни RAID-массивов
В настоящее время существует несколько RAID-уровней, которые можно считать стандартизованными, - это RAID 0, RAID 1, RAID 2, RAID 3, RAID 4, RAID 5 и RAID 6.
Применяются также различные комбинации RAID-уровней, что позволяет объединить их достоинства. Обычно это комбинация какого-либо отказоустойчивого уровня и нулевого уровня, применяемого для повышения производительности (RAID 1+0, RAID 0+1, RAID 50).
Отметим, что все современные RAID-контроллеры поддерживают функцию JBOD (Just a Bench Of Disks), которая не предназначена для создания массивов, - она обеспечивает возможность подключения к RAID-контроллеру отдельных дисков.
Нужно отметить, что интегрированные на материнские платы для домашних ПК RAID-контроллеры поддерживают далеко не все RAID-уровни. Двухпортовые RAID-контроллеры поддерживают только уровни 0 и 1, а RAID-контроллеры с большим количество портов (например, 6-портовый RAID-контроллер, интегрированный в южный мост чипсета ICH9R/ICH10R) - также уровни 10 и 5.
Кроме того, если говорить о материнских платах на чипсетах Intel, то в них тоже реализована функция Intel Matrix RAID, которая позволяет создать на нескольких жестких дисках одновременно RAID-матрицы нескольких уровней, выделив для каждой из них часть дискового пространства.
RAID 0
RAID уровня 0, строго говоря, не является избыточным массивом и соответственно не обеспечивает надежности хранения данных. Тем не менее данный уровень активно применяется в случаях, когда необходимо обеспечить высокую производительность дисковой подсистемы. При создании RAID-массива уровня 0 информация разбивается на блоки (иногда эти блоки называют страйпами (stripe)), которые записываются на отдельные диски, то есть создается система с параллельным доступом (если, конечно, это позволяет размер блока). Благодаря возможности одновременного ввода-вывода с нескольких дисков, RAID 0 обеспечивает максимальную скорость передачи данных и максимальную эффективность использования дискового пространства, поскольку не требуется места для хранения контрольных сумм. Реализация этого уровня очень проста. В основном RAID 0 применяется в тех областях, где требуется быстрая передача большого объема данных.
RAID 1 (Mirrored disk)
RAID уровня 1 - это массив двух дисков со 100-процентной избыточностью. То есть данные при этом просто полностью дублируются (зеркалируются), за счет чего достигается очень высокий уровень надежности (как, впрочем, и стоимости). Отметим, что для реализации уровня 1 не требуется предварительно разбивать диски и данные на блоки. В простейшем случае два диска содержат одинаковую информацию и являются одним логическим диском. При выходе из строя одного диска его функции выполняет другой (что абсолютно прозрачно для пользователя). Восстановление массива выполняется простым копированием. Кроме того, этот уровень удваивает скорость считывания информации, так как эта операция может выполняться одновременно с двух дисков. Подобная схема хранения информации используется в основном в тех случаях, когда цена безопасности данных гораздо выше стоимости реализации системы хранения.
RAID 5
RAID 5 - это отказоустойчивый дисковый массив с распределенным хранением контрольных сумм. При записи поток данных разбивается на блоки (страйпы) на уровне байтов и одновременно записываются на все диски массива в циклическом порядке.
Предположим, что массив содержит n дисков, а размер страйпа d . Для каждой порции из n–1 страйпов рассчитывается контрольная сумма p .
Cтрайп d 1 записывается на первый диск, страйп d 2 - на второй и так далее вплоть до страйпа d n–1 , который записывается на (n –1)-й диск. Далее на n -й диск записывается контрольная сумма p n , и процесс циклически повторяется с первого диска, на который записывается страйп d n .
Процесс записи (n–1) страйпов и их контрольной суммы производится одновременно на все n дисков.
Для вычисления контрольной суммы используется поразрядная операция «исключающего ИЛИ» (XOR), применяемая к записываемым блокам данных. Так, если имеется n жестких дисков, d - блок данных (страйп), то контрольная сумма рассчитывается по следующей формуле:
p n = d 1 d 2 ... d 1–1 .
В случае выхода из строя любого диска данные на нем можно восстановить по контрольным данным и по данным, оставшимся на исправных дисках.
В качестве иллюстрации рассмотрим блоки размером по четыре бита. Пусть имеются всего пять дисков для хранения данных и записи контрольных сумм. Если есть последовательность битов 1101 0011 1100 1011, разбитая на блоки по четыре бита, то для расчета контрольной суммы необходимо выполнить следующую поразрядную операцию:
1101 0011 1100 1011 = 1001.
Таким образом, контрольная сумма, записываемая на пятый диск, равна 1001.
Если один из дисков, например четвертый, вышел из строя, то блок d 4 = 1100 окажется недоступным при считывании. Однако его значение легко восстановить по контрольной сумме и по значениям остальных блоков с помощью все той же операции «исключающего ИЛИ»:
d 4 = d 1 d 2 d 4 p 5 .
В нашем примере получим:
d 4 = (1101) (0011) (1100) (1011) = 1001.
В случае RAID 5 все диски массива имеют одинаковый размер, однако общая емкость дисковой подсистемы, доступной для записи, становится меньше ровно на один диск. Например, если пять дисков имеют размер 100 Гбайт, то фактический размер массива составляет 400 Гбайт, поскольку 100 Гбайт отводится на контрольную информацию.
RAID 5 может быть построен на трех и более жестких дисках. С увеличением количества жестких дисков в массиве его избыточность уменьшается.
RAID 5 имеет архитектуру независимого доступа, что обеспечивает возможность одновременного выполнения нескольких операций считывания или записи.
RAID 10
Уровень RAID 10 представляет собой некое сочетание уровней 0 и 1. Минимально для этого уровня требуются четыре диска. В массиве RAID 10 из четырех дисков они попарно объединяются в массивы уровня 0, а оба этих массива как логические диски объединяются в массив уровня 1. Возможен и другой подход: первоначально диски объединяются в зеркальные массивы уровня 1, а затем логические диски на основе этих массивов - в массив уровня 0.
Intel Matrix RAID
Рассмотренные RAID-массивы уровней 5 и 1 редко используются в домашних условиях, что связано прежде всего с высокой стоимостью подобных решений. Наиболее часто для домашних ПК применяется именно массив уровня 0 на двух дисках. Как мы уже отмечали, RAID уровня 0 не обеспечивает безопасности хранения данных, а потому конечные пользователи сталкиваются с выбором: создавать быстрый, но не обеспечивающий надежности хранения данных RAID-массив уровня 0 или же, увеличивая стоимость дискового пространства в два раза, - RAID-массив уровня 1, который обеспечивает надежность хранения данных, однако не позволяет получить существенного выигрыша в производительности.
Для того чтобы разрешить эту нелегкую проблему, корпорация Intel разработала технологию Intel Matrix Storage, позволяющую объединить достоинства массивов уровней 0 и 1 всего на двух физических дисках. А для того, чтобы подчеркнуть, что речь в данном случае идет не просто о RAID-массиве, а о массиве, сочетающем в себе и физические и логические диски, в названии технологии вместо слова «массив» используется слово «матрица».
Итак, что же представляет собой RAID-матрица из двух дисков по технологии Intel Matrix Storage? Основная идея заключается в том, что при наличии в системе нескольких жестких дисков и материнской платы с чипсетом Intel, поддерживающим технологию Intel Matrix Storage, возможно разделение дискового пространства на несколько частей, каждая из которых будет функционировать как отдельный RAID-массив.
Рассмотрим простой пример RAID-матрицы из двух дисков по 120 Гбайт каждый. Любой из дисков можно разбить на два логических диска, например по 40 и 80 Гбайт. Далее два логических диска одного размера (например, по 40 Гбайт) можно объединить в RAID-матрицу уровня 1, а оставшиеся логические диски - в RAID-матрицу уровня 0.
В принципе, используя два физических диска, также можно создать всего одну или две RAID-матрицы уровня 0, но вот получить только матрицы уровня 1 невозможно. То есть если в системе имеются всего два диска, то технология Intel Matrix Storage позволяет создавать следующие типы RAID-матриц:
- одна матрица уровня 0;
- две матрицы уровня 0;
- матрица уровня 0 и матрица уровня 1.
Если в системе установлены три жестких диска, то возможно создание следующих типов RAID-матриц:
- одна матрица уровня 0;
- одна матрица уровня 5;
- две матрицы уровня 0;
- две матрицы уровня 5;
- матрица уровня 0 и матрица уровня 5.
Если в системе установлены четыре жестких диска, то дополнительно имеется возможность создать RAID-матрицу уровня 10, а также комбинации уровня 10 и уровня 0 или 5.
От теории к практике
Ели говорить о домашних компьютерах, то наиболее востребованными и популярными являются RAID-массивы уровней 0 и 1. Использование RAID-массивов из трех и более дисков в домашних ПК - скорее исключение из правила. Связано это с тем, что, с одной стороны, стоимость RAID-массивов возрастает пропорционально количеству задействованных в нем дисков, а с другой - для домашних компьютеров первоочередное значение имеет емкость дискового массива, а не его производительность и надежность.
Поэтому в дальнейшем мы рассмотрим RAID-массивы уровней 0 и 1 на основе только двух дисков. В задачу нашего исследования будет входить сравнение производительности и функциональности RAID-массивов уровней 0 и 1, созданных на базе нескольких интегрированных RAID-контроллеров, а также исследование зависимости скоростных характеристик RAID-массива от размера страйпа.
Дело в том, что хотя теоретически при использовании RAID-массива уровня 0 скорость чтения и записи должна возрастать вдвое, на практике возрастание скоростных характеристик гораздо менее скромное и для разных RAID-контроллеров оно различно. Аналогично и для RAID-массива уровня 1: несмотря на то что теоретически скорость чтения должна увеличиваться вдвое, на практике не всё так гладко.
Для нашего сравнительного тестирования RAID-контроллеров мы использовали материнскую плату Gigabyte GA-EX58A-UD7. Эта плата основана на чипсете Intel X58 Express с южным мостом ICH10R, имеющим интегрированный RAID-контроллер на шесть портов SATA II, который поддерживает организацию RAID-массивов уровней 0, 1, 10 и 5 с функцией Intel Matrix RAID. Кроме того, на плате Gigabyte GA-EX58A-UD7 интегрирован RAID-контроллер GIGABYTE SATA2, на базе которого реализованы два порта SATA II c возможностью организации RAID-массивов уровней 0, 1 и JBOD.
Также на плате GA-EX58A-UD7 интегрирован SATA III-контроллер Marvell 9128, на базе которого реализованы два порта SATA III c возможностью организации RAID-массивов уровней 0, 1 и JBOD.
Таким образом, на плате Gigabyte GA-EX58A-UD7 имеются три отдельных RAID-контроллера, на базе которых можно создать RAID-массивы уровней 0 и 1 и сравнить их друг с другом. Напомним, что стандарт SATA III обратно совместим со стандартом SATA II, поэтому на базе контроллера Marvell 9128, поддерживающего диски с интерфейсом SATA III, можно также создавать RAID-массивы с использованием дисков с интерфейсом SATA II.
Стенд для тестирования имел следующую конфигурацию:
- процессор - Intel Core i7-965 Extreme Edition;
- материнская плата - Gigabyte GA-EX58A-UD7;
- версия BIOS - F2a;
- жесткие диски - два диска Western Digital WD1002FBYS, один диск Western Digital WD3200AAKS;
- интегрированные RAID-контроллеры:
- ICH10R,
- GIGABYTE SATA2,
- Marvell 9128;
- память - DDR3-1066;
- объем памяти - 3 Гбайт (три модуля по 1024 Мбайт);
- режим работы памяти - DDR3-1333, трехканальный режим работы;
- видеокарта - Gigabyte GeForce GTS295;
- блок питания - Tagan 1300W.
Тестирование проводилось под управлением операционной системы Microsoft Windows 7 Ultimate (32-bit). Операционная система инсталлировалась на диск Western Digital WD3200AAKS, который подключался к порту контроллера SATA II, интегрированного в южный мост ICH10R. RAID-массив собирался на двух дисках WD1002FBYS с интерфейсом SATA II.
Для измерения скоростных характеристик создаваемых RAID-массивов мы использовали утилиту IOmeter, которая является отраслевым стандартом для измерения производительности дисковых систем.
Утилита IOmeter
Поскольку мы задумывали эту статью как своеобразное руководство пользователя по созданию и тестированию RAID-массивов, логично будет начать с описания утилиты IOmeter (Input/Output meter), которая, как мы уже отметили, является своеобразным отраслевым стандартом для измерения производительности дисковых систем. Данная утилита бесплатна, и ее можно скачать с ресурса http://www.iometer.org.
Утилита IOmeter является синтетическим тестом и позволяет работать с неразбитыми на логические разделы жесткими дисками, благодаря чему можно тестировать диски независимо от файловой структуры и свести к нулю влияние операционной системы.
При тестировании возможно создание специфической модели доступа, или «паттерна», которая позволяет конкретизировать выполнение жестким диском специфических операций. В случае создания конкретной модели доступа разрешается менять следующие параметры:
- размер запроса на передачу данных;
- случайное/последовательное распределение (в %);
- распределение операций чтения/записи (в %);
- количество отдельных операций ввода-вывода, работающих параллельно.
Утилита IOmeter не требует инсталляции на компьютер и состоит из двух частей: собственно IOmeter и Dynamo.
IOmeter - это контролирующая часть программы с пользовательским графическим интерфейсом, позволяющим производить все необходимые настройки. Dynamo - это генератор нагрузки, который не имеет интерфейса. Каждый раз при запуске файла IOmeter.exe автоматически запускается и генератор нагрузки Dynamo.exe.
Для того чтобы начать работу с программой IOmeter, достаточно запустить файл IOmeter.exe. При этом открывается главное окно программы IOmeter (рис. 1).
Рис. 1. Главное окно программы IOmeter
Нужно отметить, что утилита IOmeter позволяет производить тестирование не только локальных дисковых систем (DAS), но и сетевых накопителей (NAS). К примеру, с ее помощью можно протестировать производительность дисковой подсистемы сервера (файл-сервера), используя для этого несколько сетевых клиентов. Поэтому часть закладок и инструментов в окне утилиты IOmeter относится именно к сетевым настройкам программы. Понятно, что при тестировании дисков и RAID-массивов эти возможности программы нам не потребуются, а потому мы не станем объяснять назначение всех вкладок и инструментов.
Итак, при запуске программы IOmeter в левой части главного окна (в окне Topology) будет отображаться древовидная структура всех запущенных генераторов нагрузки (экземпляров Dynamo). Каждый запущенный экземпляр генератора нагрузки Dynamo называется менеджером (manager). Кроме того, программа IOmeter является многопотоковой и каждый отдельный запущенный поток экземпляра генератора нагрузки Dynamo называется Worker. Количество запущенных Worker’ов всегда соответствует количеству логических ядер процессора.
В нашем примере используется только один компьютер с четырехъядерным процессором, поддерживающим технологию Hyper-Threading, поэтому запускается лишь один менеджер (один экземпляр Dynamo) и восемь (по количеству логических ядер процессора) Worker’ов.
Собственно, для тестирования дисков в данном окне нет необходимости что-либо менять или добавлять.
Если выделить мышью название компьютера в древовидной структуре запущенных экземпляров Dynamo, то в окне Target на вкладке Disk Target отобразятся все диски, дисковые массивы и прочие накопители (включая сетевые), установленные в компьютере. Это те накопители, с которыми программа IOmeter может работать. Носители могут быть помечены желтым или голубым цветом. Желтым цветом отмечаются логические разделы носителей, а голубым - физические устройства без созданных на них логических разделов. Логический раздел может быть перечеркнут или не перечеркнут. Дело в том, что для работы программы с логическим разделом его нужно прежде подготовить, создав на нем специальный файл, равный по размеру емкости всего логического раздела. Если логический раздел перечеркнут, то это значит, что раздел еще не подготовлен для тестирования (он будет подготовлен автоматически на первом этапе тестирования), ну а если раздел не перечеркнут, то это означает, что на логическом разделе уже создан файл, полностью готовый для тестирования.
Отметим, что, несмотря на поддерживаемую возможность работы с логическими разделами, оптимально тестировать именно не разбитые на логические разделы диски. Удалить логический раздел диска можно очень просто - через оснастку Disk Management . Для доступа к ней достаточно щелкнуть правой кнопкой мыши на значке Computer на рабочем столе и в открывшемся меню выбрать пункт Manage . В открывшемся окне Computer Management в левой части необходимо выбрать пункт Storage , а в нем - Disk Management . После этого в правой части окна Computer Management отобразятся все подключенные диски. Щелкнув правой кнопкой по нужному диску и выбрав в открывшемся меню пункт Delete Volume …, можно удалить логический раздел на физическом диске. Напомним, что при удалении с диска логического раздела вся информация на нем удаляется без возможности восстановления.
Вообще, с помощью утилиты IOmeter тестировать можно только чистые диски или дисковые массивы. То есть нельзя протестировать диск или дисковый массив, на котором установлена операционная система.
Итак, вернемся к описанию утилиты IOmeter. В окне Target на вкладке Disk Target необходимо выбрать тот диск (или дисковый массив), который будет подвергаться тестированию. Далее необходимо открыть вкладку Access Specifications (рис. 2), на которой можно будет определить сценарий тестирования.
Рис. 2. Вкладка Access Specifications утилиты IOmeter
В окне Global Access Specifications имеется список предустановленных сценариев тестирования, которые можно присвоить менеджеру загрузки. Впрочем, эти сценарии нам не понадобятся, поэтому все их можно выделить и удалить (для этого предусмотрена кнопка Delete ). После этого нажмем на кнопку New , чтобы создать новый сценарий тестирования. В открывшемся окне Edit Access Specification можно определить сценарий загрузки диска или RAID-массива.
Предположим, мы хотим выяснить зависимость скорости последовательного (линейного) чтения и записи от размера блока запроса на передачу данных. Для этого нам нужно сформировать последовательность сценариев загрузки в режиме последовательного чтения при различных размерах блока, а затем последовательность сценариев загрузки в режиме последовательной записи при различных размерах блока. Обычно размеры блоков выбираются в виде ряда, каждый член которого вдвое больше предыдущего, а первый член этого ряда равен 512 байт. То есть размеры блоков составляют следующий ряд: 512 байт, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 Кбайт, 1 Мбайт. Делать размер блока больше 1 Мбайт при последовательных операциях нет смысла, поскольку при таких больших размерах блока данных скорость последовательных операций не изменяется.
Итак, сформируем сценарий загрузки в режиме последовательного чтения для блока размером 512 байт.
В поле Name окна Edit Access Specification вводим название сценария загрузки. Например, Sequential_Read_512. Далее в поле Transfer Request Size задаем размер блока данных 512 байт. Ползунок Percent Random/Sequential Distribution (процентное соотношение между последовательными и выборочными операциями) сдвигаем до упора влево, чтобы все наши операции были только последовательными. Ну а ползунок , задающий процентное соотношение между операциями чтения и записи, сдвигаем до упора вправо, чтобы все наши операции были только чтением. Остальные параметры в окне Edit Access Specification менять не нужно (рис. 3).
Рис. 3. Окно Edit Access Specification для создания сценария загрузки последовательного чтения
при размере блока данных 512 байт
Нажимаем на кнопку Ok , и первый созданный нами сценарий отобразится в окне Global Access Specifications на вкладке Access Specifications утилиты IOmeter.
Аналогично нужно создать сценарии и для остальных блоков данных, однако, чтобы облегчить себе работу, проще не создавать сценарий каждый раз заново, нажимая для этого кнопку New , а, выбрав последний созданный сценарий, нажать кнопку Edit Copy (редактировать копию). После этого опять откроется окно Edit Access Specification с настройками нашего последнего созданного сценария. В нем достаточно будет поменять лишь название и размер блока. Проделав аналогичную процедуру для всех остальных размеров блоков, можно приступить к формированию сценариев для последовательной записи, что делается совершенно аналогично, за исключением того, что ползунок Percent Read/Write Distribution , задающий процентное соотношение между операциями чтения и записи, нужно сдвинуть до упора влево.
Аналогично можно создать сценарии для выборочной записи и чтения.
После того как все сценарии будут готовы, их нужно присвоить менеджеру загрузки, то есть указать, с какими сценариями будет работать Dynamo .
Для этого еще раз проверяем, что в окне Topology выделено название компьютера (то есть менеджер нагрузки на локальном ПК), а не отдельный Worker. Это гарантирует, что сценарии нагрузки будут присваиваться сразу всем Worker’ам. Далее в окне Global Access Specifications выделяем все созданные нами сценарии нагрузки и нажимаем кнопку Add . Все выделенные сценарии нагрузки добавятся в окно (рис. 4).
Рис. 4. Присвоение созданных сценариев нагрузки менеджеру нагрузки
После этого нужно перейти к вкладке Test Setup (рис. 5), на которой можно задать время выполнения каждого созданного нами сценария. Для этого в группе Run Time задаем время выполнения сценария нагрузки. Вполне достаточно будет задать время, равное 3 мин.
Рис. 5. Задание времени выполнения сценария нагрузки
Кроме того, в поле Test Description необходимо указать название всего теста. В принципе, данная вкладка имеет массу других настроек, однако для наших задач они не нужны.
После того как все необходимые настройки произведены, рекомендуется сохранить созданный тест, нажав на панели инструментов на кнопку с изображением дискеты. Тест сохраняется с расширением *.icf. Впоследствии можно будет воспользоваться созданным сценарием нагрузки, запустив не файл IOmeter.exe, а сохраненный файл с расширением *.icf.
Теперь можно приступить непосредственно к тестированию, нажав на кнопку с изображением флажка. Вам будет предложено указать название файла с результатами тестирования и выбрать его местоположение. Результаты тестирования сохраняются в CSV-файле, который потом легко экспортировать в Excel и, установив фильтр по первому столбцу, выбрать нужные данные с результатами тестирования.
В ходе тестирования промежуточные результаты можно наблюдать на вкладке Result Display , а определить, к какому сценарию нагрузки они относятся, можно на вкладке Access Specifications . В окне Assigned Access Specification исполняемый сценарий отображается зеленым, выполненные сценарии - красным, а еще не выполненные сценарии - синим цветом.
Итак, мы рассмотрели базовые приемы работы с утилитой IOmeter, которые потребуются для тестирования отдельных дисков или RAID-массивов. Отметим, что мы рассказали далеко не обо всех возможностях утилиты IOmeter, но описание всех ее возможностей выходит за рамки данной статьи.
Создание RAID-массива на базе контроллера GIGABYTE SATA2
Итак, мы начинаем создание RAID-массива на базе двух дисков с использованием интегрированного на плате RAID-контроллера GIGABYTE SATA2. Конечно, сама компания Gigabyte не производит чипов, а потому под чипом GIGABYTE SATA2 скрывается перемаркированный чип другой фирмы. Как можно выяснить из INF-файла драйвера, речь идет о контроллере серии JMicron JMB36x.
Доступ в меню настройки контроллера возможен на этапе загрузки системы, для чего нужно нажать комбинацию клавиш Ctrl+G, когда появится соответствующая надпись на экране. Естественно, прежде в настройках BIOS нужно определить режим работы двух SATA-портов, относящихся к контроллеру GIGABYTE SATA2, как RAID (в противном случае доступ в меню конфигуратора RAID-массива будет невозможен).
Меню настройки RAID-контроллера GIGABYTE SATA2 довольно простое. Как мы уже отмечали, контроллер является двухпортовым и позволяет создавать RAID-массивы уровня 0 или 1. Через меню настройки контроллера можно удалить или создать RAID-массив. При создании RAID-массива имеется возможность указать его название, выбрать уровень массива (0 или 1), задать размер страйпа для RAID 0 (128, 84, 32, 16, 8 или 4K), а также определить размер массива.
Если массив создан, то какие-либо изменения в нем уже невозможны. То есть нельзя впоследствии для созданного массива изменить, например, его уровень или размер страйпа. Для этого прежде нужно удалить массив (с потерей данных), а потом создать его заново. Собственно, это свойственно не только контроллеру GIGABYTE SATA2. Невозможность изменения параметров созданных RAID-массивов - особенность всех контроллеров, которая вытекает из самого принципа реализации RAID-массива.
После того как массив на базе контроллера GIGABYTE SATA2 создан, текущую информацию о нем можно просмотреть, используя утилиту GIGABYTE RAID Configurer, которая устанавливается автоматически вместе с драйвером.
Создание RAID-массива на базе контроллера Marvell 9128
Конфигурирование RAID-контроллера Marvell 9128 возможно только через настройки BIOS платы Gigabyte GA-EX58A-UD7. Вообще, нужно сказать, что меню конфигуратора контроллера Marvell 9128 несколько сыровато и может ввести в заблуждение неискушенных пользователей. Впрочем, об этих незначительных недоработках мы расскажем чуть позже, а пока рассмотрим основные функциональные возможности контроллера Marvell 9128.
Итак, несмотря на то что этот контроллер поддерживает работу с дисками с интерфейсом SATA III, он также полностью совместим с дисками с интерфейсом SATA II.
Контроллер Marvell 9128 позволяет создать RAID-массив уровней 0 и 1 на базе двух дисков. Для массива уровня 0 можно задать размер страйпа 32 или 64 Кбайт, а также указать имя массива. Кроме того, имеется и такая опция, как Gigabyte Rounding, которая нуждается в пояснении. Несмотря на название, созвучное с именем компании-производителя, функция Gigabyte Rounding никакого отношения к ней не имеет. Более того, она никак не связана с RAID-массивом уровня 0, хотя в настройках контроллера ее можно определить именно для массива этого уровня. Собственно, это первая из тех недоработок конфигуратора контроллера Marvell 9128, о которых мы упоминали. Функция Gigabyte Rounding определена только для RAID-массива уровня 1. Она позволяет использовать для создания RAID-массива уровня 1 два диска (например, различных производителей или разные модели), емкость которых немного отличается друг от друга. Функция Gigabyte Rounding как раз и задает разницу в размерах двух дисков, применяемых для создания RAID-массива уровня 1. В контроллере Marvell 9128 функция Gigabyte Rounding позволяет установить разницу в размерах дисков 1 или 10 Гбайт.
Еще одна недоработка конфигуратора контроллера Marvell 9128 заключается в том, что при создании RAID-массива уровня 1 у пользователя имеется возможность выбора размера страйпа (32 или 64 Кбайт). Однако понятие страйпа вообще не определено для RAID-массива уровня 1.
Создание RAID-массива на базе контроллера, интегрированного в ICH10R
RAID-контроллер, интегрированный в южный мост ICH10R, является самым распространенным. Как уже отмечалось, данный RAID-контроллер 6-портовый и поддерживает не только создание массивов RAID 0 и RAID 1, но также RAID 5 и RAID 10.
Доступ в меню настройки контроллера возможен на этапе загрузки системы, для чего нужно нажать комбинацию клавиш Ctrl+I, когда появится соответствующая надпись на экране. Естественно, прежде в настройках BIOS следует определить режим работы этого контроллера как RAID (в противном случае доступ в меню конфигуратора RAID-массива будет невозможен).
Меню настройки RAID-контроллера достаточно простое. Через меню настройки контроллера можно удалить или создать RAID-массив. При создании RAID-массива можно указать его название, выбрать уровень массива (0, 1, 5 или 10), задать размер страйпа для RAID 0 (128, 84, 32, 16, 8 или 4K), а также определить размер массива.
Сравнение производительности RAID-массивов
Для тестирования RAID-массивов с помощью утилиты IOmeter мы создали сценарии нагрузки последовательного чтения, последовательной записи, выборочного чтения и выборочной записи. Размеры блоков данных в каждом сценарии нагрузки составляли следующую последовательность: 512 байт, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 Кбайт, 1 Мбайт.
На каждом из RAID-контроллеров создавался массив RAID 0 со всеми допустимыми размерами страйпов и массив RAID 1. Кроме того, дабы иметь возможность оценить прирост производительности, получаемый от использования RAID-массива, мы также протестировали на каждом из RAID-контроллеров одиночный диск.
Итак, обратимся к результатам нашего тестирования.
Контроллер GIGABYTE SATA2
Прежде всего рассмотрим результаты тестирования RAID-массивов на базе контроллера GIGABYTE SATA2 (рис. 6-13). В общем-то контроллер оказался в буквальном смысле загадочным, а его производительность просто разочаровала.
|
|
Рис. 6. Скорость последовательных |
Рис. 7. Скорость последовательных |
|
|
Рис. 12. Скорость последовательных |
Рис. 13. Скорость последовательных |
Если посмотреть на скоростные характеристики одного диска (без RAID-массива), то максимальная скорость последовательного чтения составляет 102 Мбайт/с, а максимальная скорость последовательной записи - 107 Мбайт/с.
При создании массива RAID 0 с размером страйпа 128 Кбайт максимальная скорость последовательного чтения и записи увеличивается до 125 Мбайт/с, то есть возрастает примерно на 22%.
При размере страйпа 64, 32 или 16 Кбайт максимальная скорость последовательного чтения составляет 130 Мбайт/с, а максимальная скорость последовательной записи - 141 Мбайт/с. То есть при указанных размерах страйпа максимальная скорость последовательного чтения возрастает на 27%, а максимальная скорость последовательной записи - на 31%.
Вообще-то это маловато для массива уровня 0, и хотелось бы, чтобы максимальная скорость последовательных операций была выше.
При размере страйпа 8 Кбайт максимальная скорость последовательных операций (чтения и записи) остается примерно такой же, как и при размере страйпа 64, 32 или 16 Кбайт, однако с выборочным чтением - явные проблемы. При увеличении размера блока данных вплоть до 128 Кбайт скорость выборочного чтения (как и должно быть) возрастает пропорционально размеру блока данных. Однако при размере блока данных более 128 Кбайт скорость выборочного чтения падает практически до нуля (примерно до 0,1 Мбайт/с).
При размере страйпа 4 Кбайт падает не только скорость выборочного чтения при размере блока более 128 Кбайт, но и скорость последовательного чтения при размере блока более 16 Кбайт.
Использование массива RAID 1 на контроллере GIGABYTE SATA2 практически не изменяет (в сравнении с одиночным диском) скорость последовательного чтения, однако максимальная скорость последовательной записи уменьшается до 75 Мбайт/с. Напомним, что для массива RAID 1 скорость чтения должна возрастать, а скорость записи не должна уменьшаться в сравнении со скоростью чтения и записи одиночного диска.
На основании результатов тестирования контроллера GIGABYTE SATA2 можно сделать только один вывод. Использовать данный контроллер для создания массивов RAID 0 и RAID 1 имеет смысл только в том случае, когда все остальные RAID-контроллеры (Marvell 9128, ICH10R) уже задействованы. Хотя представить себе подобную ситуацию довольно сложно.
Контроллер Marvell 9128
Контроллер Marvell 9128 продемонстрировал гораздо более высокие скоростные характеристики в сравнении с контроллером GIGABYTE SATA2 (рис. 14-17). Собственно, различия проявляются даже при работе контроллера с одним диском. Если для контроллера GIGABYTE SATA2 максимальная скорость последовательного чтения составляет 102 Мбайт/с и достигается при размере блока данных 128 Кбайт, то для контроллера Marvell 9128 максимальная скорость последовательного чтения составляет 107 Мбайт/с и достигается при размере блока данных 16 Кбайт.
|
|
Рис. 18. Скорость последовательных Если говорить о массиве RAID 0 на контроллере ICH10R, то максимальная скорость последовательного чтения и записи не зависит от размера страйпа и составляет 212 Мбайт/с. От размера страйпа зависит лишь размер блока данных, при котором достигается максимальное значение скорости последовательного чтения и записи. Как показывают результаты тестирования, для RAID 0 на базе контроллера ICH10R оптимально использовать страйп размером 64 Кбайт. В этом случае максимальное значение скорости последовательного чтения и записи достигается при размере блока данных всего 16 Кбайт. Итак, резюмируя, еще раз подчеркнем, что RAID-контроллер, встроенный в ICH10R, существенно превосходит по производительности все остальные интегрированные RAID-контроллеры. А учитывая, что он обладает и большей функциональностью, оптимально использовать именно этот контроллер и просто забыть о существовании всех остальных (если, конечно, в системе не применяются диски SATA III). |
Выводы
Популярные в настоящее время настольные СУБД обладают следующими основными свойствами:
· имеют визуальные средства проектирования форм, отчетов и приложений;
· предоставляют доступ к данным серверных СУБД;
· приобрели средства публикации данных в Internet и в той или иной степени поддерживают создание приложений для редактирования данных с помощью Web-браузеров;
· предоставляют возможность хранить описания правил ссылочной целостности внутри базы данных.
2. 3. Архитектура «клиент-сервер»
2.3.1. Недостатки архитектуры «файл-сервер»
Обработка данных с помощью больших и мини-ЭВМ, популярная в 70-е годы, имела свои преимущества, в определенной степени утраченные позже, в эпоху персональных компьютеров и настольных СУБД. В частности, одним из таких преимуществ была централизация хранения и обработки данных. Однако повсеместное увлечение настольными СУБД и их сетевыми версиями, вызванное доступностью и дешевизной, как самого программного обеспечения, так и его эксплуатации, заставило многих пользователей на долгие годы забыть о старой модели вычислений.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно большими - это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении. Это приводит к перегрузке сети при увеличении числа пользователей и объема данных.
Известно много случаев, когда для решения подобных проблем закупалось дорогое сетевое оборудование с целью увеличения пропускной способности сети. Нередко также применялся подход, приводящий к децентрализации хранения данных. Типичный пример подобного подхода - создание нескольких однотипных локальных баз данных, например, для различных подразделений компании или для разных временных периодов (лет, кварталов, месяцев), что облегчало работу, связанную с вводом данных, но повышало стоимость их статистической обработки и анализа - в этом случае нужно было обрабатывать данные из разных источников. Однако все эти меры позволяли лишь отложить на время решение проблемы снижения производительности, но не устраняли главного недостатка информационных систем, основанных на настольных СУБД, - обработки данных в клиентском приложении.
Радикальным решением проблемы сетевого трафика и иных проблем, возникающих при увеличении объема данных и числа пользователей, стал переход к архитектуре «клиент-сервер», позаимствовавшей многие достоинства старой модели вычислений, в частности централизацию хранения и обработки данных.
2.3.2. Состав «клиент-серверной» ИС
Принцип централизации хранения и обработки данных является базовым принципом архитектуры «клиент-сервер». Для его реализации используется так называемый сервер баз данных, который может манипулировать файлами с данными, - для клиентских приложений эти файлы абсолютно бесполезны (и, при правильной организации доступа пользователей к файлам в сети, вообще не должны быть доступны).
Сервер баз данных осуществляет целый комплекс действий по управлению данными. Основными его обязанностями являются:
· выполнение пользовательских запросов на выбор и модификацию данных, получаемых от клиентских приложений, функционирующих на персональных компьютерах локальной сети;
· хранение и резервное копирование данных;
· поддержка ссылочной целостности данных согласно определенным в базе данных правилам;
· протоколирование операций и ведение журнала транзакций.
В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды. Таким образом, простейшая клиент-серверная информационная система состоит из двух основных компонентов:
· сервера баз данных, управляющего данными и выполняющего запросы клиентских приложений;
· клиентских приложений, предоставляющих интерфейс пользователя и посылающих запросы к серверу.
2.3.3. Преимущества архитектуры «клиент-сервер»
Информационные системы, использующие архитектуру «клиент-сервер», обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД. Рассмотрим наиболее важные из них.
· Одним из важнейших преимуществ архитектуры «клиент-сервер» является снижение сетевого трафика при выполнении запросов. Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен – выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. Т. е. в клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит от числа записей в таблицах, к которым произведен запрос.
· Вторым преимуществом архитектуры «клиент-сервер» является возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Это означает, что требования к рабочим станциям могут быть не столь высоки. В конечном итоге снижается стоимость информационной системы даже при использовании дорогостоящей серверной СУБД и дорогого аппаратного обеспечения.
· Современные серверные СУБД обладают широкими возможностями управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения о ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю).
· Современные серверные СУБД обладают также широкими возможностями резервного копирования и архивации данных.
Таким образом, технология «клиент-сервер» решает многие проблемы, возникающие при использовании настольных СУБД.
На сегодняшний день известно более двух десятков серверных СУБД, однако наиболее популярными, исходя из числа продаж, следует признать Oracle, Microsoft SQL Server, Informix, Sybase.
Сведения о производителях перечисленных выше СУБД представлены в следующей таблице:
Таблица 2. Серверные СУБД
Как правило, данные СУБД обладают следующими свойствами:
Реализованы для нескольких платформ;
Обладают удобными административными утилитами;
Позволяют осуществлять резервное копирование данных;
Поддерживают параллельную обработку данных в многопроцессорных системах;
Поддерживают выполнение распределенных запросов;
Поддерживают средства разработки и генераторы отчетов;
Поддерживают публикацию данных в Internet.
Иными словами, существующие на сегодняшний день возможности наиболее популярных серверных СУБД отражают современные тенденции развития информационных систем, такие как использование многопроцессорных систем и распределенной обработки данных, создание распределенных систем, в том числе с использованием технологий Internet, применение средств быстрой разработки приложений, создание систем поддержки принятия решений с использованием аналитической обработки данных, а также все более повышающиеся требования к надежности и отказоустойчивости информационных систем.
Термин «сервер БД» используется для обозначения всей СУБД, основанной на архитектуре клиент-сервер, включая серверную и клиентскую часть. Такие системы предназначены для хранения и обеспечения доступа к БД. Обычно одна БД целиком хранится в одном узле сети и поддерживается сервером в сервере БД, представляющим собой простое и дешевое приближение к распределенным БД, так как общая БД доступна для всех пользователей локальной сети. Доступ к базам данных из прикладной программы или пользователя осуществляется с использованием клиентской части системы. В качестве основного интерфейса между клиентскими и серверными частями выступает язык SQL.
Язык SQL представляет собой текущий стандарт интерфейса СУБД в открытых системах. Соблюдая предосторожности при программировании, можно создать прикладные информационные системы мобильные в классе SQL-серверов.
Серверы БД, интерфейс которых основан на языке SQL, обладают своими преимуществами и недостатками.
Преимущества: стандартный открытый интерфейс, т. е. клиентская часть любой ориентированной СУБД может работать с любым SQL-сервером независимо от того, когда компания его разработала.
Недостатки. При высоком уровне интерфейса между клиентской и серверной частями системы со стороны клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная работающая станция. Но если клиентский компонент обладает достаточной мощностью, то часто возникает необходимость возложить на него большие функции управления БД. Разгрузить сервер, который в этом случае является узким местом этой системы. Одним из корректных направлений СУБД является гибкая конфигурированная система, при которой распределяются функции между клиентской и пользовательской системами.
Преимущества протоколов удаленного вызова процедур
Использование механизма удаленного вызова процедур позволяет перераспределить функции между клиентскими и серверными частями систем, т. к. в тексте программы RPC ничем не отличается от ее обычного вызова. Следовательно, любой компонент системы может располагаться и на стороне сервера, и на стороне клиента.
Механизм RPC, скрывает различия между взаимодействующими компьютерами, физически неоднородная локальная вычислительная сеть приводится к логически однородной сети, взаимодействующих компонентов. В результате использования нет необходимости серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.
Типичные распределения функций между клиентами и серверами
Типичным на сегодняшний день на стороне СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к БД, а обращается для этого к серверу с использование языка SQL.
В некоторых случаях необходимо включить в состав клиентской части системы некоторых функций для работы с локальной КЭШ БД, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. Используя современные технологии, это можно сделать только путем формального создания на стороне клиента локальной копии серверов БД и рассмотрения всей системы как набор взаимодействующих серверов. С другой стороны иногда хотелось бы перенести большую часть прикладной системы на стороны сервера, если разница в мощностях клиентских рабочих станций и сервера велика, то это можно сделать, используя удаленный вызов процедур при условии, что программное обеспечение сервера это позволяет.
Требования к аппаратуре и программному обеспечению клиентских и сервисных компьютеров различают в зависимости от вида использованной системы.
Если разделение между клиентской и сервисной частью достаточно жесткое, как в большинстве современных СУБД, то пользователям, работающим на станциях, все равно какая аппаратура и операционная система работает на сервере при условии, что он сравнивается с возникающим потоком запросов.
Если могут возникнуть потребности перераспределения функций между клиентом и сервером, то не все равно какие операции системы используются.
Распределенные базы данных
Основной задачей системы управления распределенной БД состоит в обеспечении средств интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети для того, чтобы пользователи, работающие на любом узле сети, имели доступ ко всем базам данных как к единой БД. При этом должны обеспечиваться:
1) простота использования системы;
2) возможности автономного функционирования, при нарушении связанности сети;
Разновидности распределенных систем
Существуют однородные и неоднородные БД. В однородной БД каждая локальная БД управляется одной и той же СУБД. В неоднородной системе локальные БД могут относиться даже к разным моделям данных.
Наиболее успешно в настоящее время решается задача интеграции неоднородных SQL ориентированных систем. Этому способствует стандартизация языка SQL и общее следование.
Основная цель проекта создания распределенной системы управления базами данных может быть сформулирована следующим образом: необходимо обеспечить средства интеграции локальных баз данных, располагающихся в узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных, так, как если бы они были централизованными, при этом должны обеспечиваться:
1) легкость использования системы;
2) возможность автономного функционирования при нарушении связности сети;
3) высокая степень эффективности.
Для решения этих проблем был принят ряд необходимых проектных решений, касающихся декомпозиции исходного запроса, оптимального выбора способа выполнения запроса, согласованного выполнения транзакций, обеспечение синхронизации, обнаружение и разрешение распределенных тупиков, восстановление состояния баз данных после разного рода сбоев в узлах сети. Легкость использования системы достигается за счет того, что пользователи остаются в среде языка SQL. Возможность использования SQL обеспечивает прозрачность местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в пользовательском запросе объектов данных. Одна и та же прикладная программа, включающая приложение SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запросов в соответствии с расположением данных в распределенной системе. Обеспечение автономности узлов сети может быть обеспечено следующим образом: каждая локальная БД администрируется независимо от других, возможно автономное подключение новых пользователей, смена версии автономной части системы и т.д. Система спроектирована таким образом, что в ней не требуются централизованных службы именования объектов или обнаружения тупиков.
В индивидуальных узлах не требуется наличия глобального знания об операциях, выполняющихся в других узлах сети. Работа с доступными базами данных может продолжаться при выходе из строя отдельных узлов сети и линий связи. Для достижения высокой степени эффективности системы используется два основных приема. Во-первых, выполнению запроса предшествует его компиляция. В ходе этого процесса производится поиск употребляемых в запросе имен объектов баз данных в распределенном каталоге и замена имен на внутренние идентификаторы; проверка прав доступа пользователя, от которого производится компиляция, на выполнение соответствующей операции над базами данных и выбор наиболее оптимального глобального плана выполнения запроса, который затем подвергается декомпозиции и про частям рассылается в соответствующие узлы сети, где производится выбор оптимальных локальных планов выполнения компонентов запроса и производится генерация модулей доступа в машинных кодах. В результате на стадии компиляции производится множество действий до реального выполнения запросов. Обработанная таким образом прикладная программа, включающая предложения SQL, может в дальнейшем выполняться много раз без дополнительных накладных расходов.
Во-вторых, средством повышения эффективности системы является возможность перемещения удаленных отношений в локальные базы данных.
Распределенная компиляция запросов
Запросы на языке SQL до своего реального выполнения могут подвергаться компиляции. Компиляция запросов может производиться на стадии предкомпиляции прикладной программы, написанной на обычном традиционном языке программирования с включением предложений SQL, или в процессе выполнения транзакций с использованием инструкции языка SQL. С точки зрения пользователя процесс компиляции приводит к следующим результатам: для каждого предложения на SQL образуется программа в машинных кодах, вызовы которой помещаются в текст исходной прикладной программы, однако в действительности процесс компиляции запроса намного более сложен из-за наличия сложных сетевых взаимодействий, которые требуются при реальном выполнении транзакции. Будем называть главным узлом сети тот узел, в котором инициирован процесс компиляции предложений SQL, и дополнительными узлами (те узлы, которые вовлекаются в этот процесс в ходе его выполнения). На самом грубом уровне процесс компиляции можно разбить на следующие стадии:
В главном узле сети производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева. На основе информации из локального каталога главного узла и удаленных каталогов дополнительных узлов производится замена имен объектов, фигурирующих в запросе, на их системные идентификаторы.
В главном узле генерируется глобальный план выполнения запроса, в котором учитывается только порядок взаимодействия узлов при реальном выполнении запроса. Глобальный план отображается в преобразованном соответствующим образом дереве запросов.
Если в глобальном плане выполнения запроса участвуют дополнительные узлы, производится его декомпозиция на части, каждую из которых можно выполнить в одном узле. Например, локальная фильтрация отношения в соответствии с заданным условием, при которой соответствующие части запроса рассылаются в соответствующие дополнительные узлы.
В каждом узле, участвующем в глобальном плане выполнения запроса, в главном или дополнительном, выполняется завершающая стадия компиляции. Эта стадия включает по существу две последние фазы процесса компиляции запроса: оптимизацию и генерацию машинных кодов, производится проверка прав пользователя, от имени которого выполняется компиляция, на выполнение соответствующих действий. Происходит обработка представлений БД, осуществляется локальная оптимизация обрабатываемой части запроса в соответствии с имеющимися индексами и производится генерация кода.
Oracle была первой коммерческой реляционной СУБД, поддерживающей ставший ныне индустриальным стандартом язык SQL; ее первая версия появилась в 1979 году. Фактически все это время Oracle является бессменным лидером на рынке производителей коммерческих СУБД и второй (после Microsoft) по величине компанией, производящей программное обеспечение.
Ранние версии этой СУБД были предназначены для мэйнфреймов, а в качестве рабочих мест использовались «неинтеллектуальные» терминалы. Однако со временем появились версии Oracle, предназначенные для использования в архитектуре «клиент-сервер» (первой такой версией была Oracle 5, выпущенная в 1985 году). Первоначально эти версии были предназначены для различных серверных платформ - различных версий UNIX, VMS и др. Позже были выпущены версии сервера Oracle для Novell NetWare. Первые версии этого сервера для персональных компьютеров появились в середине 90-х (Personal Oracle 7 for Windows 3.1, Personal Oracle 7 for Windows 95, Personal Oracle Lite, Oracle Workgroup Server 7 for Windows NT). До появления этих версий персональные компьютеры могли использоваться исключительно в качестве клиентских рабочих станций - в состав Oracle для серверных платформ обычно входила клиентская часть для DOS.
Отметим, что Oracle была первой компанией, создавшей СУБД, использовавшую предоставляемые некоторыми серверными платформами средства параллельных вычислений - Oracle Parallel Server (до его появления параллельные вычисления использовались только для решения научных задач). При использовании параллельных вычислений Oracle Parallel Server дает возможность нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций, а более поздние его версии дают возможность осуществить декомпозицию операций с большими объемами данных с целью параллельного выполнения их на нескольких процессорах.
На сегодняшний день последней версией Oracle является версия Oracle 8i, отличительными свойствами которой являются:
- наличие объектных расширений и соответствующих типов данных, таких как вложенные таблицы, массивы, объекты и др. Иными словами, Oracle 8 и Oracle 8i являются объектно-ориентированными СУБД;
- наличие функций аналитической обработки данных (например, вычисления процентных соотношений, ранжирования, сравнения временных периодов);
- возможность создания таблиц, содержащих агрегатные данные (materialized views) и возможность частичного их обновления при изменении данных, на основании которых они вычислены;
- поддержка Java, в частности JDK 1.2 и JDBC 2.0;
- поддержка XML, в частности в Oracle 8i включены XML Parser for Java, C/C++, PL/SQL, превращающие XML-данные в вид, пригодный для использования в Oracle 8;
- поддержка HTML- и XML-страниц с включенным в них кодом PL/SQL (для их выполнения требуются дополнительные продукты, например WebDB PL/SQL Gateway или Oracle Application Server PL/SQL Cartridge);
- поддержка хранения мультимедиа-данных с возможностью индексации, построения контекстных запросов, поддержки разных языков для хранимых документов;
- набор процедур и функций для обработки пространственной информации (Oracle Spatial);
- дополнительные возможности обеспечения безопасности, например шифрование данных, поддержка SSL, использование ролей уровня базы данных и уровня предприятия;
- возможность создания систем, устойчивых к сбоям, с использованием нескольких параллельных процессов;
- поддержка Microsoft Cluster Server;
- наличие OLE DB-провайдера для доступа к данным.
Oracle 8i существует в трех редакциях: Oracle 8i, Oracle 8i Enterprise Edition, Oracle 8i Personal Edition.
Для создания многомерных хранилищ данных существует и отдельный продукт - Oracle Express OLAP.
Помимо различных версий сервера баз данных среди продуктов Oracle имеется также Designer/2000 - ориентированное на эту СУБД CASE-средство для анализа бизнес-процессов и проектирования данных, а также средства разработки клиентских приложений. Одно из них - Developer/2000 (называвшееся ранее Oracle*Forms) - весьма популярно среди пользователей Oracle; были и другие средства разработки (например, Oracle Power Objects). Отметим, что приложения, созданные с помощью Developer/2000, могут выполняться на различных платформах. Язык PL/SQL, используемый в этом средстве разработки, является интерпретируемым и представляет собой тот же самый язык, что используется в Oracle для написания серверного кода. Это позволяет отлаживать с помощью Developer/2000 серверный код.
Производя собственные средства разработки, Oracle предоставляет своим пользователям возможность создавать клиентские приложения с помощью других средств. В частности, помимо стандартного в таких случаях клиентского API (Oracle Call Interface) клиентская часть Oracle содержит также объектную модель (Oracle Objects for OLE), позволяющую использовать клиентскую часть Oracle как набор COM-объектов для доступа к данным. Кроме того, обычно клиентская часть Oracle содержит также ODBC-драйвер для доступа к данным этой СУБД.
Отметим, что и многие другие компании производят ODBC-драйверы и OLE DB-провайдеры для доступа к Oracle (в частности, Microsoft). Компании, производящие средства разработки, использующие собственные библиотеки доступа к данным (такие как Inprise или Gupta/Centura), также включают библиотеки доступа к Oracle в состав наиболее дорогих версий своих продуктов.
Из готовых информационных систем на базе Oracle следует особо отметить несколько крупных систем управления предприятием, в частности SAP/R3. На Западе также нередко используются готовые решения от самой Oracle Corporation, объединенные под общим названием Oracle Applications, такие как Oracle Financials, Oracle Human Resources, Oracle Market Management, Oracle Project Systems и др.
Microsoft SQL Server
Первая версия Microsoft SQL Server, совместно разработанная в 1988 году компаниями Microsoft и Sybase, предназначалась для платформы OS/2. Последующие версии этого сервера баз данных предназначались для платформы Windows NT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускались и не выпускаются.
Удобный пользовательский интерфейс утилит администрирования в сочетании с достаточно высокой производительностью и относительно невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по популярности - после Oracle. Наибольший рост популярности этой СУБД пришелся на конец 90-х годов, когда были выпущены Microsoft SQL Server 6.0 (1995 год), обладавший централизованными функциями администрирования и встроенными возможностями репликации данных, Microsoft SQL Server 6.5 (1996 год) и Microsoft SQL Server 6.5 Enterprise Edition, поддерживающий параллельные вычисления в многопроцессорных системах.
На сегодняшний день наиболее широко используемой является выпущенная в 1998 году версия Microsoft SQL Server 7.0. Эта версия отличается от предыдущих тем, что была полностью переписана фирмой Microsoft исключительно под платформу Windows NT. В состав Microsoft SQL Server 7.0 входят еще более простые утилиты администрирования (Enterprise Manager), сервисы преобразования данных (Data Transformation Services), облегчающие перенос данных в SQL Server из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД), расширенная поддержкой функций для создания Web-приложений.
Помимо собственно Microsoft SQL Server 7.0 в качестве встроенной СУБД для настольных приложений и приложений для небольших рабочих групп можно также использовать Microsoft Data Engine (MSDE) - настольный сервер баз данных, совместимый с Microsoft SQL Server и предназначенный для использования в настольных системах или в сетевых приложениях с небольшим (до 2 Гбайт) объемом данных и небольшим количеством пользователей. Базы данных MSDE полностью совместимы с базами данных Microsoft SQL Server и могут при необходимости управляться этим сервером. Подробнее об MSDE и правилах его лицензирования можно прочесть в предыдущей статье данного цикла.
Клиентские приложения для Microsoft SQL Server и MSDE можно создавать как с помощью средств разработки Microsoft - Visual Basic, Visual C++, Access и Visual FoxPro, так и с помощью средств разработки других производителей. Для этой цели имеются ODBC-драйвер и OLE DB-провайдер, а также содержащий их набор библиотек Microsoft Data Access Components (MDAC), позволяющий использовать в средствах разработки объекты ActiveX Data Objects (ADO) - COM-объекты для доступа к данным. MDAC является составной частью Windows 2000, а для пользователей других Windows-платформ доступен отдельно на Web-сайте Microsoft.
В отличие от Oracle, Microsoft не производит средств разработки, использующих тот же самый язык программирования, что и язык для создания кода триггеров и хранимых процедур, однако производит средства отладки серверного кода (например, SQL Server Debugger входит в состав Visual Basic и Visual C++).
Sybase
Серверные продукты компании Sybase происходят от двух «предков». Первым из них является одна из ранних версий Microsoft SQL Server, созданная совместно Microsoft и Sybase. Начиная с 1994 года Microsoft и Sybase разрабатывают свои серверные продукты независимо друг от друга, и результатом деятельности компании Sybase в этом направлении является продукт под названием Adaptive Server Enterprise (в настоящее время используются его версии 11 и 12). Этот продукт существует для Windows NT и некоторых версий UNIX (включая Linux) и предназначен для обслуживания крупных предприятий. В настоящее время этот сервер поддерживает:
- упреждающее асинхронное чтение, что повышает скорость выполнения сложных запросов;
- использование кластерных систем;
- распределенную обработку запросов, в том числе к базам данных других производителей;
- расширенные хранимые процедуры, позволяющие осуществить легкий доступ к не-SQL функциям (Java, 3GL-системы, функции операционной системы и т.д.);
- параллельную обработку запросов в многопроцессорных системах;
- параллельную работу утилит администрирования;
- интеграцию с популярными системами безопасности, такими как Kerberos.
Еще одна линия серверных продуктов Sybase ведет свое начало от сервера баз данных Watcom SQL Anywhere, отличавшегося компактностью и простотой администрирования. Последняя версия этого продукта называется Adaptive Server Anywhere 6.0.3. Этот сервер предназначен для обслуживания небольших рабочих групп, для применения в портативных компьютерах в качестве персонального сервера с периодической репликацией, а также в мобильных устройствах - существуют версии этого сервера для Windows CE 2.1 и версия UltraLite для разнообразных мобильных устройств (исключая разве что тамагочи).
Для управления распределенными транзакциями Sybase выпускает монитор транзакций - Jaguar CTS.
Для создания многомерных хранилищ данных у Sybase существует еще один серверный продукт - Adaptive Server IQ, позволяющий создавать хранилища на основе данных не только из СУБД производства Sybase, но и из СУБД других производителей. Отметим также, что существует ряд продуктов под общим названием Sybase Industry Warehouse Studio, ориентированных на обслуживание конкретных предметных областей: торговли (Retail Warehouse Studio), здравоохранения (Healthcare Warehouse Studio), страхования (Life Insurance Warehouse Studio) и др.
Помимо серверных продуктов Sybase производит средства разработки, ориентированные на создание клиентских приложений для них (PowerBuilder, PowerJ, PowerSite; последнее предназначено для создания Web-приложений), и средства проектирования данных и генерации кода приложений. Последние можно отнести к универсальным средствам - CASE-средство DataArchitect поддерживает широкий спектр СУБД различных производителей, а генератор приложений AppModeler способен генерировать код не только для PowerBuilder и Optima++, но и для Delphi, Visual Basic, Web-приложений с использованием ASP.
Informix
Ведущий продукт фирмы Informix - Informix Dynamic Server, последняя версия которого называется Informix Dynamic Server.2000 (выпущена в сентябре 1999 года). Данный продукт поддерживает платформы UNIX и Microsoft Windows NT и обеспечивает эффективную работу как на одно-, так и на многопроцессорных системах, а также в кластерах. Сервер построен по архитектуре Dynamic Scalable Architecture (DSA), обеспечивающей мощные средства для параллельной обработки данных. В числе основных характеристик Informix Dynamic Server следует отметить:
- использование для управления дисковым пространством как средств операционной системы (UNIX или Microsoft Windows NT), так и собственных функций, позволяющих обойти ограничения операционной системы и добиться более высокой производительности, - такое управление дисковым пространством называется Raw Disk Management;
- управление разделением памяти - поддержку одновременного доступа к данным, находящимся в памяти, несколькими приложениями;
- динамическое управление потоками;
- поддержку фрагментации таблиц и индексов на нескольких дисках;
- распараллеливание запросов (parallel database query, PDQ);
- зеркалирование данных.
Сервер поддерживает двухфазное завершение транзакций, гетерогенные транзакции (в этом случае в транзакциях может принимать участие и не-Informix сервер, доступный через Informix Enterprise Gateway).
Расширения функциональности сервера реализуются на базе DataBlade - коллекций объектов баз данных и подпрограмм на языке С, подключаемых к базе данных. Для разработки DataBlades необходимо использовать DataBlade Developer’s Kit. Фирма Informix и целый ряд независимых производителей выпускают модули DataBlade, такие, например, как Excalibur Text DataBlade Module, Informix Geodetic DataBlade Module, Informix TimeSeries DataBlade Module, Excalibur Image DataBlade Module, Informix Web DataBlade Module и ряд других.
Входящие в состав Informix Dynamic Server клиентские утилиты предназначены для подключения к серверу и обработки информации (DB-Access) и для выполнения функций администрирования (DB/Cockpit).
Клиентские приложения могут создаваться с использованием языков Informix ESQL (средство для разработки на языке С, позволяющее включать в приложения запросы к данным на языке SQL), а также С, С++, Java, Visual Basic и Delphi. Помимо этого существует собственное средство разработки - Informix-4GL и Informix Client Software Developer’s Kit.
Фирма Informix выпускает Informix ODBC Driver, OLE DB Provider для Informix Dynamic Server и Informix JDBC Driver.
В состав продукта входят собственно сервер, а также Informix Connect 2.30, DataBlade Developer’s Kit 4.0 и Informix Server Administrator 1.0.
Для генерации отчетов предлагается Informix-ViewPoint - визуальное средство, рассчитанное на пользователей. Версия Pro также содержит средства администрирования.
Говоря о сервере фирмы Informix, следует упомянуть и поддержку OLAP: продукт под названием Informix MetaCube поставляется как часть Informix Decision Frontier - комплексного решения для создания хранилищ данных.
Среди других продуктов фирмы Informix следует отметить:
- Informix Internet Foundation.2000 - специально разработанный для Internet вариант Informix Dynamic Server;
- i.Reach - корпоративный репозитарий для хранения данных различного типа, интеллектуального управления информацией и извлечения данных. Основное назначение данного продукта - поддержка включения в содержимое корпоративных сайтов электронных документов и их последующее обслуживание;
- i.Sell - комплексное решение для электронной коммерции на базе Informix Dynamic Server.
DB2
Семейство серверных СУБД фирмы IBM, известное под названием DB2 Universal Database, представляет собой стратегию IBM по объединению продуктов DB2 для различных платформ в единую линию. Впервые появившееся в 1996 году семейство DB2 Universal Database объединяло в себе функциональные возможности таких продуктов фирмы, как DB2 Common Server, DB2 Parallel Edition (DB2 PE), Net.Data, Data Propagator и технологии DataHub, и предназначалось для платформ UNIX, OS/2 и Microsoft Windows NT.
Отметим, что при переносе DB2 на не-IBM-платформы фирма старается максимально использовать уникальные функциональные возможности конкретной платформы. Например, в DB2 for Windows 2000 для обеспечения безопасности используется Windows NT LAN Manager, полностью поддерживается Windows Performance Monitor, Systems Management Server, интеграция с Active Directory для каталогизации баз данных, а также такие интерфейсы доступа к данным, как ODBC, ADO и OLE DB. Помимо этого DB2 for Windows 2000 поддерживает Microsoft Transaction Services (MTS) в качестве координатора при создании приложений, использующих распределенные транзакции.
Для разработчиков, использующих Microsoft Visual Studio, становятся доступными дополнительные модули, например Stored ProcedureBuilder, включаемый непосредственно в среду Visual Studio. IBM также предлагает собственные средства разработки, например IBM VisualAge for Java, позволяющие создавать приложения, работающие с данными в DB2. Продукт также поддерживает создание хранимых процедур на языке Java (Java Stored Procedure Builder).
Помимо этого IBM предлагает бесплатное средство для миграции данных из Microsoft Access в DB2, а также средства для миграции данных из Oracle, Microsoft, Sybase и Informix.
К основным характеристикам СУБД можно отнести поддержку реляционных и комплексных данных через объектные расширения, возможность работы на мультипроцессорных платформах, поддержку кластеров, 64-битную архитектуру памяти и распараллеливание запросов, возможность создания Web-приложений (поддерживаются такие технологии, как Java, JDBC, SQLJ, XML) и наличие средства для гетерогенного администрирования и обработки данных.
Семейство DB2 функционионирует на системах AS/400 и RISC System/6000, мэйнфреймах IBM, машинах от Hewlett-Packard и Sun Microsystems и на таких операционных системах, как Windows NT и Windows 95/98, OS/2, AIX, HP-UX, SCO UnixWare, Linux, NUMA-Q и Sun Solaris, и сейчас поддерживает портативные устройства под управлением Windows CE и Palm OS.
DB2 Universal Database выпускается в редакциях DB2 Universal Database Enterprise - Extended Edition (платформы AIX, Solaris и Windows NT), DB2 Universal Database Enterprise Edition (платформы AIX, HP-UX, Linux, OS/2, Solaris и Windows NT), DB2 Universal Database Workgroup Edition (платформы Linux, OS/2 и Windows NT) и DB2 Universal Database Personal Edition (платформы OS/2, Linux, Windows 9x и Windows NT).
К дополнительным продуктам можно отнести:
- DB2 OLAP Server - средство для онлайновой аналитической обработки данных и реализации хранилищ данных, интегрирующее ядро Hyperion Essbase с семейством DB2 Universal Database. Работает с Hyperion Integration Server (Hyperion), Hyperion Wired for OLAP (Hyperion), Brio.Insight (Brio Technology), BUSINESSOBJECTS (Business Objects), PowerPlay (Cognos), Lotus 1-2-3 (Lotus), Excel, Internet Explorer, Visual Basic (Microsoft) и Crystal Info (Seagate);
- DB2 Connect - средство для управления соединениями различных клиентов с DB2 на AS/400;
- DB2 Universal Developer’s Edition - рассчитанное на разработчиков средство для создания и тестирования приложений в архитектуре «клиент-сервер», работающих с данными DB2;
- DB2 DataJoiner - средство для доступа к реляционным и нереляционным данным, расположенным на различных платформах как к единому «образу» данных;
- DB2 Data Links Manager - средство для управления дополнительными файлами, подключаемыми к СУБД;
- DB2 Query Patroller - набор средств для создания запросов и управления ресурсами для систем принятия решений. DB2 Query Patroller получает ODBC-запросы от клиента, анализирует их и динамически распределяет запросы по различным узлам DB2 UDB Enterprise - Extended Edition;
- DB2 Net.Data - приложение, позволяющее Web-разработчикам создавать динамические Internet-приложения, используя Web Macros;
- DB2 Universal Database Satellite Edition - средство для внедрения масштабируемых мобильных решений, для управления удаленными пользователями. Поддерживает функции репликации, централизованное администрирование и средства управления через Web - DB2 Web Control Center;
- DB2 Everywhere - СУБД для Palm OS и Windows CE, обеспечивающее SQL-функции и синхронизацию данных с другими реляционными базами данных, с данными Lotus Notes/Domino и PIMs.
Заключение
В данной статье мы рассмотрели преимущества архитектуры «клиент-сервер». Мы узнали, что по сравнению с информационными системами, основанными на настольных СУБД, системы, использующие серверные СУБД, обладают более высокой производительностью, меньшим сетевым трафиком, более совершенными средствами обеспечения безопасности, а также возможностями перенести на сервер баз данных часть кода, связанную с реализацией бизнес-правил и обработкой данных. Кроме того, мы обсудили возможные проблемы, которые могут возникнуть в процессе перехода от настольной СУБД к серверной, а также задачи, стоящие перед разработчиками, осуществляющими такой переход.
Мы также рассмотрели наиболее популярные на сегодняшний день серверные СУБД и признаки, которыми они характеризуются. Как правило, все или почти все данные СУБД:
- реализованы для нескольких платформ;
- обладают удобными административными утилитами;
- позволяют осуществлять резервное копирование данных;
- поддерживают несколько сценариев репликаций;
- поддерживают параллельную обработку данных в многопроцессорных системах;
- поддерживают OLAP и создание хранилищ данных;
- поддерживают выполнение распределенных запросов и транзакций;
- позволяют использовать различные средства проектирования данных для создания своих объектов;
- поддерживают средства разработки и генераторы отчетов как собственного производства, так и других производителей;
- поддерживают как минимум публикацию данных в Internet.
Иными словами, существующие на сегодняшний день возможности наиболее популярных серверных СУБД отражают современные тенденции развития информационных систем, такие как использование многопроцессорных систем и распределенной обработки данных, создание распределенных систем, в том числе с использованием технологий Internet, применение средств быстрой разработки приложений, создание систем поддержки принятия решений с использованием аналитической обработки данных, а также все более повышающиеся требования к надежности и отказоустойчивости информационных систем.
Следующая статья данного цикла будет посвящена различным механизмам доступа к данным, используемым в приложениях.
КомпьютерПресс 5"2000
В этом подразделе приводится классификация СУБД, и рассматриваются основные их функции. В качестве основных классификационных признаков можно использовать следующие: вид программы, характер использования, модель данных. Названные признаки существенно влияют на целевой выбор СУБД и эффективность использования разрабатываемой информационной системы.
Система управления базами данных (СУБД) - это важнейший компонент АИС , основанной на базе данных. СУБД необходима для создания и поддержки базы данных информационной системы в той же степени, как для разработки программы на алгоритмическом языке - транслятор. Программные составляющие СУБД включают в себя ядро и сервисные средства (утилиты).
Ядро СУБД - это набор программных модулей, необходимый и достаточный для создания и поддержания БД, то есть универсальная часть, решающая стандартные задачи по информационному обслуживанию пользователей. Сервисные программы предоставляют пользователям ряд дополнительных возможностей и услуг, зависящих от описываемой предметной области и потребностей конкретного пользователя.
Классификация СУБД .
В общем случае под СУБД можно понимать любой программный продукт, поддерживающий процессы создания, ведения и использования БД. Рассмотрим какие из имеющихся на рынке программ имеют отношение к БД и в какой мере они связаны с базами данных.
К СУБД относятся следующие основные виды программ:
Полнофункциональные СУБД;
Серверы БД;
Клиенты БД;
Средства разработки программ работы с БД.
Полнофункциональные СУБД (ПФСУБД) представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Из числа всех СУБД современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям. К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R: BASE.
Обычно ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example - формулировки запросов по образцу, см. подраздел 3.8). Многие ПФСУБД включают средства программирования для профессиональных разработчиков.
Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы . Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.
Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Эта группа БД в настоящее время менее многочисленна, но их количество постепенно растет. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL.
Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).
В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары "клиент - сервер" могут принадлежать одному или разным производителям программного обеспечения.
В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным "любой ценой". Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) - роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Biyth Software, Paradox, DataEase, Focus, 1-2-3, MDBS III, Revelation и другие.
Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:
Клиентских программ;
Серверов БД и их отдельных компонентов;
Пользовательских приложений.
Программы первого и второго вида довольно малочисленны, так как предназначены, главным образом, для системных программистов. Пакетов третьего вида гораздо больше, но меньше, чем полнофункциональных СУБД.
К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft) и ERwin (LogicWorks).
Кроме перечисленных средств, для управления данными и организации обслуживания БД используются различные дополнительные средства, к примеру, мониторы транзакций
По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУ БД
обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др
Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.
По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
С точки зрения пользователя, СУБД реализует функции хранения, изменения (пополнения, редактирования и удаления) и обработки информации, а также разработки и получения различных выходных документов.
Для работы с хранящейся в базе данных информацией СУБД предоставляет программам и пользователям следующие два типа языков :
Язык описания данных - высокоуровневый непроцедурный язык декларативного типа, предназначенный для описания логической структуры данных;
Язык манипулирования данными - совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам.
Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE (Query By Example) - язык запросов по образцу и SQL (Structured Query Language) - структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов - описания и манипулирования данными.
Перечисленные выше функции СУБД, в свою очередь, используют следующие основные функции более низкого уровня, которые назовем низкоуровневыми :
Управление данными во внешней памяти;
Управление буферами оперативной памяти;
Управление транзакциями;
Ведение журнала изменений в БД;
Обеспечение целостности и безопасности БД. Дадим краткую характеристику необходимости и особенностям реализации перечисленных функций в современных СУБД.
Реализация функции управления данными во внешней памяти в разных системах может различаться и на уровне управления ресурсами (используя файловые системы ОС или непосредственное управление устройствами ПЭВМ), и по логике самих алгоритмов управления данными. В основном методы и алгоритмы управления данными являются "внутренним делом" СУБД и прямого отношения к пользователю не имеют. Качество реализации этой функции наиболее сильно влияет на эффективность работы специфических ИС, например, с огромными БД, со сложными запросами, большим объемом обработки данных.
Необходимость буферизации данных и как следствие реализации функции управления буферами оперативной памяти обусловлено тем, что объем оперативной памяти меньше объема внешней памяти.
Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу после обработки. Механизм транзакций используется в СУБД для поддержания целостности данных в базе.
Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обеспечении, включая приложение) транзакция остается незавершенной, то она отменяется.
Говорят, что транзакции присущи три основных свойства:
Атомарность (выполняются все входящие в транзакцию операции или ни одна);
Сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);
Долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции).
Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Здесь необходим, по крайней мере, двухшаговый процесс. Сначала снимают деньги с одного счета, затем добавляют их к другому счету. Если хотя бы одно из действий не выполнится успешно, результат операции окажется неверным и будет нарушен баланс между счетами.
Контроль транзакций важен в однопользовательских и в многопользовательских СУБД, где транзакции могут быть запущены параллельно. В последнем случае говорят о сериализуемости транзакций. Под сериализацией параллельно выполняемых транзакций понимается составление такого плана их выполнения (сериального плана), при котором суммарный эффект реализации транзакций эквивалентен эффекту их последовательного выполнения.
При параллельном выполнении смеси транзакций возможно возникновение конфликтов (блокировок), разрешение которых является функцией СУБД. При обнаружении таких случаев обычно производится "откат" путем отмены изменений, произведенных одной или несколькими транзакциями.
Ведение журнала изменений в БД (журнализация изменений) выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных сбоев и отказов, а также ошибок в программном обеспечении.
Журнал СУБД - это особая БД или часть основной БД, непосредственно недоступная пользователю к используемая для записи информации обо всех изменениях базы данных. В различных СУБД в журнал могут заноситься записи, соответствующие изменениям в СУБД на разных уровнях: от минимальной внутренней операции модификации страницы внешней памяти до логической операции модификации БД (например, вставки записи, удаления столбца, изменения значения в поле) и даже транзакции.
Для эффективной реализации функции ведения журнала изменений в БД необходимо обеспечить повышенную надежность хранения и поддержания в рабочем состоянии самого журнала. Иногда для этого в системе хранят несколько копий журнала.
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно для случая использования БД в сетях. Целостность БД , есть свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация.
Поддержание целостности БД включает проверку целостности и ее восстановление в случае обнаружения противоречий в базе данных. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные. Примером таких условий может служить ограничение диапазонов возможных значений атрибутов объектов, сведения о которых хранятся в БД, или отсутствие повторяющихся записей в таблицах реляционных БД.
Обеспечение безопасности достигается в СУБД шифрованием прикладных программ, данных, защиты паролем, поддержкой уровней доступа к базе данных и к отдельным ее элементам (таблицам, формам, отчетам и т. д.).