Дамы и господа!

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

С уважением, Сергей Кузнецов

Database Programming & Design, vol.11, N 1, January 1998

www.dbpd.com

Object/Relational Grows Up

Donald Frazer
Managing Principal of the consulting firm Frazer Group, Menlo Park. California

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

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

Однако, в то время как на возможности роста число реляционных баз данных в равной мере содействовало как развитие аппаратных средств, так и программного обеспечения, то ограничения ОР-баз данных в основном диктуются только софтвером. Автор статьи пытается исследовать влияние архитектурных решений, выбранных такими ведущими компаниями - разработчиками продуктов управления ОР-базами данных как IBM, Informix, NCR, Oracle, Sybase и Computer Associates для обеспечения масштабируемости сложных запросов к очень большим наборам ОР-данных. Наличие в этих продуктах мощных механизмов расширения типов данных ограничивает возможности разработчиков по поддержке того же уровня эффективности, который имел место в чисто реляционных системах. Кроме того, наличие этих механизмов накладывает дополнительную ответственность на разработчиков новых типов данных и методов, а также на разработчиков приложений и администраторов. С возрастанием размеров баз данных растет и ответственность. Наконец, автор поясняет, что параллельное выполнение операторов над базой данных является ключом к достижению нужного уровня эффективности приложений, использующих новые типы и методы, точно так же, как и в случае применения чисто реляционных баз данных. Однако в случае ОР-систем добиться параллелизма намного сложнее.

Что значит термин VLDB?

Термин VLDB (Very Large Data Bases - сверхбольшие базы данных) перегружен. Размер базы данных является лишь одним и не самым важным параметром в контексте этой статьи. К примеру сказать, практически не один из обсуждаемых далее вопросов не существенен для баз данных, используемых в приложениях OLTP (On-Line Transaction Processing), поскольку в таких приложениях запросы даже к большим базам данных являются короткими и затрагивают незначительное число элементов данных и метаданных. К тому же, базы данных OLTP часто создаются и администрируются как наборы относительно независимых небольших баз данных, разделенных в соответствии со значением ключа. Вопросы же, обсуждаемые в этой статье, касаются сверхбольших баз данных, запросы к которым затрагивают большие объемы данных и метаданных и включают массивные операции соединения, агрегации и т.п. Такие базы данных и приложения сегодня главным образом связаны со складами данных (data warehousing) и добычей данных (data mining).

Для среды VLDB характерны большое число операций ввода/вывода при выполнении одного сложного оператора языка SQL и частая потребность в генерации больших промежуточных наборов данных. Запросы часто пересекают границы установленных разделов и вовлекают данные, разбросанные по всей базе данных. Поэтому такая база данных, как правило, должна администрироваться как единое целое. Автор ориентируется на базы данных размером не менее 250 Гбт, к которым поступают сложные запросы, для которых требуется оперативное администрирование для реорганизации, архивирования и восстановления и для которых характерно регулярное выполнение массивных операций (вставки, удаления и модификации) над объемами данных не менее 25 Гбт. Для таких баз данных требуются системы MPP (Massively Parallel Processing) или очень крупные кластеры SMP (Symmetric MultiProcessor). Однако многие из обсуждаемых далее вопросов относятся и к более мелким базам данных.

Параллельное выполнение индивидуальных запросов

В чисто реляционных базах данных для успешной работы с данными объемом более 250 Гбт требуется наивысшая степень параллельности при выполнении каждого индивидуального запроса. Первейшим ключом к распараллеливанию является структура самого языка запросов SQL. Этот язык предназначен для работы со множествами и накладывает немного ограничений на порядок выполнения запроса; поэтому оптимизаторы запросов реляционных СУБД обладают такой гибкостью при выборе планов выполнения запроса. По этой же причине SQL исключительно подходит для параллельного выполнения.

Для использования этой возможности необходимо придумать стратегии выполнения, обеспечивающие оптимизированное параллельное выполнение индивидуального запроса, а не только обеспечить параллельное выполнение последовательных индивидуальных стратегий. Заметим, что и индивидуальные операции определения и манипулирования данными (а также утилиты архивирования и восстановления) должны выполняться параллельным образом. Поставщики реляционных СУБД выполнили большую часть работы для обеспечения такого распараллеливания. Более того, оказалось возможным поддерживать высокую степень прозрачности для приложений и администраторов баз данных. Этому значительно способствовали не только структура SQL, но также и то, что ядро языка и типы данных были в основном зафиксированы в 80-х и начале 90-х гг. И тем не менее, от производителей требуется 2-3 года, чтобы внедрить внутреннее распараллеливание запросов в зрелую реляционную СУБД.

Многие отмечают, что сложность внедрения параллелизма в VLDB связана с двумя аспектами. Первый аспект состоит в замене последовательных алгоритмов на параллельные. Второй аспект более тонкий. Для проектирования и разработки конкурентоспособного программного обеспечения требуется качественная перестройка образа мышления. Например, первым поползновением разработчика программы загрузки базы данных было бы использование функции INSERT. Этот метод работает для малых и средних баз данных, но не годится для больших: слишком медленно. Необходимо разработать метод, при котором происходит параллельная загрузка нескольких потоков данных, опираясь на возможность использования нескольких процессоров в архитектурах MPP или кластеры SMP. Если данные поступают из одного последовательного источника (например, устройства с магнитной лентой), первичная задача загрузки состоит в как можно более быстром помещении данных в память. После этого вся процессорная мощь должна быть использована в параллельном режиме для помещения каждого элемента данных в нужное место, поддержки индексов и т.д.

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

Гипотетическое финансовое приложение

Предположим, что простая база данных 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) <= 1 AND PRICE (Clprice) / Earnings < 15

         AND #%CHANGE (Clprice, 40) > 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 по причине составления квартального отчета о доходах. Поэтому требуется по-новому управлять журнализацией и применять новые методы восстановления для тех случаев, когда (объектные) данные не журнализуются.

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

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

Новые виды ответственности

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

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

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

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

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

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

Комбинирование архитектур

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

Намеки на будущее

Грядущий мир объектно-реляционных VLDB предлагает разработчикам и конечным пользователям приложений богатые возможности получить более мощные, интуитивно понятные и продуктивные приложения. Однако, как это часто бывает при использовании новых технологий, прежде, чем такие приложения станут обычными, потребуется период изучения. Это изучение (и некоторые существенные изменения в реализации) должно быть произведено поставщиками СУБД, которые должны обеспечить функции манипулирования данными, определения данных, администрирования и также средства обучения. Требуются также значительные усилия для обеспечения всех необходимых типов данных и методов и оптимизации данных. Эти процессы будут в полном разгаре в 1998 г. и должны начать стабилизироваться в 1999-2000 гг.