Гипотетическое финансовое приложение
Предположим, что простая база данных Stockinfo содержит
информацию о разных биржах. База данных содержит информацию о
ценах закрытия каждой биржи для каждого торгового дня. Каждая
строка таблицы соответствует отдельной бирже, и информация о
ценах закрытия P1, P2, ..., Pm содержится в одном столбце
Clprice как временная серия - новый тип данных. Запрос,
направленный на поиск привлекательных для инвестиций бирж, мог бы
иметь следующую форму: "Найти все биржи из списка OTC с текущей
ценой закрытия, меньшей $30, с отношением цена/доход, меньшим 15,
с бета (мерой устойчивости) за последний год, меньшей или равной
единице, и такие, у которых цена возрастала более чем на 10
процентов в течение последних двух месяцев".
SELECT FROM Stockinfo Candidate AS
Symbol, Industry, #PRICE (Clprice), Earnings,
#BETA (Clprice, 240), #%CHANGE (Clprice, 40)
WHERE Exchange = NASDAQ AND #PRICE (Clprice) < 30 AND
#BETA (Clprice, 240) 10%
Здесь #BETA (S,n), #PRICE (S) и #%CHANGE (S,n) - новые методы,
применимые к временным рядам S и вычисляемые для последних n
элементов; для PRICE (S) n=1.
Поскольку база данных бирж очень велика, требуется выполнить этот
запрос наиболее эффективным способом. В идеале, все вычисления
нужно было бы выполнить параллельно для каждой строки. Однако на
практике степень параллельности будет ограничена числом доступных
процессоров и возможностями программного обеспечения.
Заметим, что столбец Clprice меняется в каждый торговый день и
содержит гораздо больше данных, чем другие столбцы (Symbol, Name,
Address, Exchange, Industry и т.д.). Поэтому может оказаться
разумным хранить элементы столбца Clprice отдельно от строк, в
которые они входят; стратегии буферизации данных в реляционных
СУБД не работают с большими элементами столбцов так же хорошо,
как с малыми, и обычно их плохо удается обрабатывать единообразно
совместно. В разделе WHERE содержится смесь стандартных и
нестандартных операторов SQL. Если это является обычной ситуацией
для приложения, работающего с базой данных, то локальное хранение
столбца Clprice повысит эффективность ввода/вывода.
Понятно, что даже в этом простом случае разработчики ОР СУБД не
могут сами справиться с отмеченными проблемами. Отсутствуют
стандартные определения типов данных и операторов, для хранения
элементов столбцов может потребоваться память объемом более одной
страницы, отсутствует информация о размерах и степени
устойчивости данных. Поэтому, в отличие от чисто реляционных
систем, за оптимизацию и распараллеливание в ОР-системах
совместно отвечают поставщик ОР СУБД, разработчики расширенных
типов данных и операторов, разработчики приложения и
администратор базы данных.
Как же на это реагируют разработчики ОР СУБД? Имеются два разных
архитектурных подхода, применяемых производителями для внедрения
объектно-реляционных свойств в реляционные продукты: федеративный
и интегрированный.
Федеративный подход является более простым и легче реализуемым. В
этом случае работающая реляционная СУБД существует отдельно от
объектной базы данных с расширенными возможностями типизации
данных. Этот факт скрывается от прикладной программы общим
внешним программным обеспечением. Кроме поддержки интерфейса
прикладной программы, это программное обеспечение отвечает за
выполнение операций внешнего уровня и восстановление, за создание
планов выполнения запросов, а также производит интеграцию
результатов от баз данных, генерируемых в ответ на частичные
запросы, которые возникают при поступлении от приложения полных
запросов.
Эта архитектура дает возможность полезно использовать доступную
технологию объектных СУБД и пригодна для работы с распределенными
данными. Архитектура может быть расширены путем добавления других
типов баз данных, например, текстовых или геопространственных.
Привлекает также то, что изменения, которые необходимо внести в
базы данных для включения их в федеративную организацию, могут
быть минимизированы до такой степени, что их можно производить
независимо от других баз данных.
К сожалению, чем меньше делается таких изменений, тем большая
нагрузка ложится на программное обеспечение верхнего уровня и тем
более сомнительны перспективы оптимального выполнения. Часто
требуется производить обмен промежуточными результатами между
объектной и реляционной базами данных. Рассмотрим, как будет
выполняться в этих условиях приведенный выше запрос по поводу
бирж. Проверки, относящиеся к столбцам Exchange, Industry,
Earnings можно было бы выполнить в реляционной базе данных.
Вычисления же BETA и %CHANGE в большей степени подходят для
объектной базы данных. Поэтому программное обеспечение верхнего
уровня должно согласовать два набора частичных результатов. В
результате вместо применения простого просмотра файла (возможно,
с использованием индекса) придется использовать соединение.
Предполагается, что внешнее программное обеспечение отвечает за
слияние двух промежуточных наборов результатов и создание общего
результирующего набора данных, возвращаемого прикладной
программе. Очевидно лучшим решением для этого простого случая
было бы заставить реляционную СУБД как можно тщательнее отобрать
подходящие строки, а затем передать эти строки объектной СУБД для
формирования окончательного результата. Дополнительные накладные
расходы этого решения связаны с потребностью сериализации этих
двух операций, включая необходимость передачи сообщений между
двумя СУБД.
А как обстоят дела со столь важным для VLDB распараллеливанием?
Для обеспечения конкурентоспособности федеративной архитектуры
каждая из баз данных должна быть оптимизирована для параллельного
выполнения запросов. Технология распараллеливания в настоящее
время больше развита в области чисто реляционных баз данных, чем
в области чисто объектных баз данных. Многое можно заимствовать,
если объектная модель данных ограничена таблицами, состоящими из
строк и столбцов, как это делается в объектно-реляционных
системах. Однако подобное изменение работающей объектной базы
данных, по всей видимости, потребует больших усилий. К тому же,
для успешного применения всей архитектуры общее программное
обеспечение верхнего уровня должно быть в состоянии параллельно
обрабатывать большие наборы промежуточных результатов.
Не будучи невыполнимой задачей, разработка подобного общего
параллельного программного обеспечения требует значительных
усилий. В историческом плане эта архитектура близка к архитектуре
Sybase/NCR Navigation Server для параллельных реляционных СУБД.
По указанным выше причинам позже в продукте Sybase MPP стали
использовать механизм тесной связи реляционных баз данных.
При использовании интегрированного подхода в программном
обеспечении баз данных интегрируются объектная и реляционная
функциональность. В результате тесной связи двух парадигм
обеспечиваются потенциальная возможность разработки более мощных
приложений, администрирование одного хранилища данных, требуемое
для VLDB распараллеливание, глобальная оптимизация
производительности, доступность объектной функциональности
применительно к унаследованным данным. Ценой этого является
потребность в разработке системы, которую намного сложнее
реализовать и в которой для сохранения эффективности приложений
реляционных баз данных и поддержания целостности данных
требуется тщательное управление при реализации и использовании.
Для успешной реализации интегрированной ОР-архитектуры требуется
выполнение нескольких базовых требований, включающих применение
новых подходов к управлению памятью, возможность добавления новых
методов к старым и новым операторам (перегрузка), возможность
добавления новых методов доступа и индексации, применение новых
подходов к восстановлению и (по крайней мере, в будущем)
возможность распараллеливать выполнение индивидуальных методов
объектов. Чтобы оценить влияние этих требований, достаточно
рассмотреть как изменяется путь выполнения запроса, типичный для
реляционных СУБД.
На этапе грамматического разбора необходимо распознавать новые
типы данных (временная серия в нашем примере) и новые операторы
над этими типами (например, #BETA и #%CHANGE). Нужно быть в
состоянии разобраться с перегрузкой стандартных операторов, таких
как =, > и Оптимизатор должен находить и вычислять оценочные функции для
различных операций, обнаруженных грамматическим анализатором. В
среде ОР VLDB такие оценочные функции часто должны быть более
сложными, чем соответствующие функции для операций SQL2.
Например, стоимость вычисления функции BETA для биржы за 1000
торговых дней существенно отличается от стоимости вычисления этой
функции за 30 дней. В общем случае оптимизатор должен учитывать и
размер объекта, и число объектов. Необходимо принимать во
внимание стратегию хэширования. Очень большие объекты зачастую
быстро "пролетают" сквозь память в то время как традиционные
реляционные данные можно придержать в буфере, пока он не
потребуется для других целей, в расчете на возможное повторное
использование страницы данных.
Другим аспектом является то, что последовательности действий при
выполнении операторов SQL2 хорошо понятны, а для новых методов
это не так. Например, применимые к данным в качестве методов
сжатие и шифрование должны выполняться именно в таком порядке;
эти операции не являются "коммутативными" в математическом
смысле. Если не используется совсем плохой алгоритм шифрования,
зашифрованные данные не удастся существенно сжать. Наконец,
оптимизатор должен учитывать тот факт, что выполнение некоторых
методов некоторых объектов может происходить вне сервера баз
данных, в сервере приложений или даже на стороне клиента.
В интегрированной архитектуре должно допускаться полностью
параллельное выполнение реляционных и расширенных операторов,
операций индексирования и методов доступа к данным. В зависимости
от особенностей реляционной СУБД внедрение этой возможности может
привести к существенным изменениям в реализации. Журнализация
объектных данных - эта еще одна область, в которой часто
требуются отличия от методов, применяемых для традиционных
реляционных данных. Например, глупо каждый день записывать в
журнал полные временные ряды при добавлении к Clprice нового
элемента или писать в журнал всю строку (включая Clprice) при
обновлении столбца Earnings по причине составления квартального
отчета о доходах. Поэтому требуется по-новому управлять
журнализацией и применять новые методы восстановления для тех
случаев, когда (объектные) данные не журнализуются.
Компоненты управления памятью и буферами в интегрированной
ОР-архитектуре должны допускать параллельный доступ от процессов
и нитей ОР-СУБД. Эти компоненты должны отслеживать физическое
местоположение данных в тех случаях, когда большие объекты могут
храниться отдельно (или даже на отдельном носителе) от других
данных строки. При возникновении потребности должно быть возможно
материализовать в памяти большие объекты для обработки "когда это
точно нужно" и возвращать их во внешнюю память после обновлений.
Наконец (хотя это и не относится непосредственно к пути
выполнения запросов), средства администратора интегрированной
архитектуры должны обеспечивать интерфейсы для предоставления и
каталогизации новых определений типов данных, методов, средств
индексации и методов доступа. В некоторых случаях должна
существовать возможность выбора методов или средств индексации
для данного объектного типа данных в зависимости от характеристик
конкретных объектных данных в каждой базе данных, например,
длинные или короткие временные серии. Администратор должен быть
также обеспечен набором средств для управления средой выполнения
и журнализацией и кэшированием объектов. Как и в случае
реляционных СУБД, требуется возможность параллельного выполнения
административных функций.
