Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
оящими конфигурациями аппаратуры. Отчасти это было связано с реальными потребностями рынка, а отчасти с тем фактом, что поддержка кластерного режима работы требует весьма значительных системных ресурсов. Одним из первых пожирателей ресурсов является менеджер распределенных блокировок (Distributed Locks Manager - DLM). Это программный компонент (реализованный обычно в виде набора процессов), обычно поставляемый фирмой-разработчиком ОС, задача которого - управление доступом к разделяемым ресурсам на уровне системы в целом. Именно с помощью DLM Oracle реализует блокировки параллельного кэша и вообще синхронизацию работы узлов. Универсальность DLM в сочетании с тем, что он является "внешней составляющей" OPS, приводит к тому, что общее количество блокировок параллельного кэша становится критичным ресурсом. Чтобы снизить потребность в нем, в Oracle 7.3 введен ряд усовершенствований в управлении выделением этих блокировок, но для радикального решения проблемы безусловно требовался другой подход к реализации DLM. В частности, по этой причине уже в версии 7.3 Oracle постепенно переходит к реализации DLM собственными средствами в составе ядра сервера - окончательно этот процесс завершен в Oracle 8. Как бы то ни было, уже в релизе Oracle 7.3.3 существует параллельный сервер для кластеров, функционирующих под управлением таких "легковесных" ОС, как SCO UnixWare и Windows NT (последняя - как для платформы Intel, так и для DEC Alpha).
При параллелизме, в задачах типа DSS, при выполнении отдельных операций оптимизатор выбирает один из возможных алгоритмов выполнения запросов (при этом важно, что в Oracle он с самого начала при оценке стоимости того или иного решения учитывает заданную для данного запроса степень параллелизма), затем каждый шаг алгоритма разбивается на несколько параллельных потоков. Координатор выполнения запроса запускает нужное число процессов (при этом используются все наличные процессоры - включая различные узлы кластера или MPP-системы) и обеспечивает как внутриоперационный (параллельные потоки внутри шага алгоритма), так и межоперационный параллелизм. В список операций, подлежащих распараллеливанию, помимо просмотра таблиц включены также все алгоритмы соединения (и "антисоединения") таблиц, сортировки, операции агрегирования, вложенные подзапросы, объединения и некоторые другие. Кроме того, возможно параллельное выполнение таких операций, как создание таблицы по результатам запроса, загрузка данных, сброс и восстановление БД, выполнение операций тиражирования данных. В Oracle8 к этому списку добавятся операции INSERT, UPDATE и DELETE.
Одним из наиболее фундаментальных вопросов, которые приходится решать при реализации параллельного выполнения запросов, является выбор метода распределения данных между параллельными потоками при выполнении таких операций, как полный просмотр таблиц. Самым простым (и исторически реализованным первым - фирмой Tandem) методом является "привязка" параллелизма к статическому разбиению нужных таблиц на разделы, проводимому по правилу, заданному администратором системы. Этот метод и до сих пор является краеугольным камнем параллелизма в ряде СУБД.
В идее разбиения таблиц на разделы безусловно есть серьезные положительные стороны, особенно когда это разбиение осуществляется на основе диапазонов значений содержательных параметров либо функций от них. Тогда, во-первых, может быть облегчена работа администратора БД в случае, когда таблица содержит большой объем данных (например, если разбить таблицу фактических продаж по месяцам, то можно выполнять сбросы только последнего раздела таблицы), во-вторых, становится возможным исключение разделов при выполнении запросов, содержащих условие на параметр разбиения. Однако когда параллелизм в выполнении запросов ставится в зависимость от статичного разбиения таблиц, это приводит к ряду проблем. Дело в том, что для достижения оптимального параллелизма в этом случае требуется (по очевидным причинам), чтобы данные были распределены по разделам равномерно. В принципе этого нетрудно добиться, если помещать каждую новую запись в новый раздел по циклическому алгоритму (round-robin). Но в этом случае, как нетрудно заметить, полностью теряются указанные выше два преимущества. И наоборот, если выполнять разбиение по содержательному критерию, то весьма часто получается, что данные распределяются по разделам неравномерно, что неизбежно приводит к тому, что, закончив свою работу, параллельные процессы ждут "отстающего товарища", которому не повезло с разделом. Если речь идет об устоявшихся (т. е. фактически не обновляемых) данных и о конкретном запросе с небольшими вариациями, то практически всегда можно найти некий компромиссный вариант разбиения, но в реальных системах типа DSS запросы как правило носят нерегламентированный характер (ad-hoc), а данные - опять-таки как правило - периодически обновляются. Все это как минимум приводит к серьезной административной работе, связанной с перестройкой разделов (что становится попросту обязательным, если требуется сменить степень параллелизма), но даже это не гарантирует оптимального параллельного выполнения запросов.
Такие соображения побудили разработчиков Oracle7 отказаться от принципа "статичного" параллелизма и реализовать алгоритм динамического разбиения таблиц при параллельном выполнении запросов. Упрощенно его суть в том, что таблица логически "разбивается" непосредственно при выполнении запроса в соответствии с заданной степенью параллелизма. Это не означает, вп