Аннотация

В этой статье описываются средства, обеспечивающие возможность встраивания в приложения СУБД SQL Anywhere, полнофункциональной системы баз данных, разработанной для использования в средах с минимальным администрированием. В SQL Anywhere поддерживаются возможности, стандартные для корпоративных систем управления базами данных, такие как внутризапросный параллелизм, материализованные представления, функциональные средства OLAP, хранимые процедуры, триггеры и «горячее» резервирование. SQL Anywhere может использоваться как высокопроизводительный сервер уровня рабочих групп; как встроенная СУБД, инсталлируемая вместе с приложением; или как мобильная система, устанавливаемая в переносном устройстве и обеспечивающая полный набор сервисов базы данных при отключении устройства от корпоративной intranet, включая двухпроходную синхронизацию. Демонстрируется, что средства, обеспечивающие возможность встраивания SQL Anywhere, обеспечивают надежное решение управления данными в средах с отсутствием администрирования.

1. Введение

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

В данной статье описываются разнообразные технологии, позволяющие использовать SQL Anywhere [2] во встроенных средах и/или средах с отсутствием администрирования. В разд. 2 кратко описываются архитектурные особенности SQL Anywhere, которые являются полезными, если не необходимыми для встраивания базы данных в конкретное приложение для обеспечения сервисов управления данными. В разд. 3 обсуждаются технологии самоуправления, используемые в сервере SQL Anywhere для поддержки его функционирования в средах с отсутствием администрирования. Эти технологии поддерживаются в основных компонентах сервера, а не только в дополнительных административных компонентах, помогающих администратору конфигурировать сервер – поскольку во встроенных средах часто отсутствуют подготовленные администраторы, способные самостоятельно выполнять подобную работу. По мнению авторов статьи, невозможно добиться эффективного самоуправления, если внедрять эти технологии изолированно одна от другой.

2. Технологии, обеспечивающие возможности встраивания

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

Далее выделяются некоторые возможности СУБД SQL Anywhere, позволяющие использовать ее, как встраиваемую систему.

Автоматические запуск и останов. Экземпляр сервера СУБД SQL Anywhere может быть запущен на той же физической аппаратуре с помощью простого вызова клиентского API из приложения на основе механизма разделяемой памяти. После запуска сервера с помощью операторов SQL, посылаемых из любого приложения, могут быть запущены или остановлены дополнительные базы данных. В свою очередь, сервер или база данных могут быть сконфигурированы таким образом, чтобы завершать свою работу при разрыве последнего соединения.

Для хранения базы данных используется исконная файловая система. Базы данных SQL Anywhere сохраняются в обычных файлах ОС, и ими можно управлять с помощью файловых утилит, обеспечиваемых операционной системой. Каждая база данных состоит из основного файла базы данных, отдельного файла-журнала транзакций и до 12 дополнительных файлов, которые могут быть размещены в одной и той же файловой системе или распределены по нескольким файловым системам. Разделение таблиц по строкам не поддерживается. Преимуществом такой простой организации является гибкость установки. Для копирования образа базы данных достаточно просто скопировать все связанные с ней файлы; не требуется исполнять какую-либо утилиту копирования. Файлы баз данных можно переносить на все поддерживаемые платформы, включая устройства с Windows CE и даже машины с другими архитектурами процессоров. Эта гибкость существенно облегчает перемещение баз данных, разработку приложений и выявление проблемных ситуаций, особенно, при использовании переносных устройств и работе в удаленных местоположениях.

В журнале транзакций регистрируются логические операции. В отличие от подходов упреждающей журнализации с регистрацией физических операций (см., например, Aries [6]), в журнале транзакций SQL Anywhere содержатся записи о логических операциях. Прямой журнал транзакций не только обеспечивает основу для выполнения операций синхронизации баз данных, но также может быть оттранслирован в эквивалентные операторы SQL, которые затем можно применить к любому другому экземпляру базы данных с той же схемой. Эта архитектура обеспечивает существенную гибкость поставщикам приложений при выявлении проблемных ситуаций и реконструкции, при необходимости, баз данных в удаленных местоположениях.

Интегрированная безопасность. В SQL Anywhere обеспечивается полная сквозная безопасность с использованием устойчивого шифрования на основе 128-разрядных ключей таблиц базы данных, файлов и коммуникационных потоков между приложением и базой данных, а также синхронизационного потока MobiLink. Поддерживается встроенная аутентификация пользователей (включая поддержку Kerberos), и она может интегрироваться с системами аутентификации сторонних поставщиков. Клиентские приложения могут проверять подлинность сервера с использованием цифровых подписей или подписанных сертификатов. Кроме того, поставщики приложений могут аутентифицировать сервер, что предотвращает использование сервера другими (неавторизованными) приложениями или ограничивает их возможности. В качестве отдельно лицензируемой опции безопасности в SQL Anywhere обеспечивается также шифрование по алгоритмам, сертифицированным FIPS. Кроме того, в SQL Anywhere поддерживается шифрование бизнес-логики, хранимой в базе данных, для предотвращения обратной инженерии хранимых процедур, представлений, триггеров и т.д.

Профилирование приложений. Для поддержки выявления проблемных ситуаций и анализа проблем производительности приложений во время их эксплуатации в SQL Anywhere обеспечивается встроенное средство профилирования приложений, которое позволяет получить подробную трассу всей работы сервера, включая обрабатываемые операторы SQL, характеристики производительности, содержимое строк базы данных. Трассировочная информация накапливается при выполнении приложения и может передаваться по каналу TCP/IP в любую базу данных SQL Anywhere, где ее можно анализировать. Эта гибкая архитектура позволяет собирать трассу в расчете на удобство (за счет хранения трассы в той же базе данных, в которой она генерируется) или на эффективность (за счет хранения трассы в базе данных, сохраняемой в отдельной физической машине). Такая архитектура также делает возможным применение профилировщика приложений для анализа и выработки рекомендаций для баз данных, хранимых в мобильных устройствах, которые работают под управлением Windows CE, включая рекомендации относительно требуемых индексов.

Режим работы без выдачи сообщений (Quiet Mode). При использовании в персональном или сетевом режимах сервер SQL Anywhere можно сконфигурировать для работы без выдачи сообщений. В этом режиме на консоли не отображается протокол работы сервера, сервер не генерирует сообщения во время запуска и не выдает приглашения к обслуживанию. Это позволяет производителям приложений полностью контролировать пользовательский интерфейс с приложением.

Поддержка активных баз данных. В SQL Anywhere поддерживается обработка событий с использованием планирования обработчиков событий (хранимых процедур) на основе времени или событий. Это позволяет автоматически обрабатывать разнообразные ситуации, от ошибок типа «переполнение диска» до разрыва соединения с приложением. Встроенная в сервер поддержка SMTP позволяет обработчикам событий, если это требуется, производить оповещение об их возникновении через электронную почту.

Поддержка Web-сервисов. В SQL Anywhere содержится встроенный HTTP-сервер, позволяющий серверу SQL Anywhere функционировать как Web-серверу, а также допускается доступ к Web-сервисам в других базах данных SQL Anywhere и стандартным Web-сервисам, доступным в Internet. Для этих целей, вообще говоря, используется стандарт SOAP, но во встроенном HTTP-сервере в SQL Anywhere также поддерживаются стандартные HTTP- и HTTPS-запросы от клиентских приложений. В результате этого можно встроить все приложение внутрь экземпляра базы данных с использованием компонентов активных баз данных, поддерживаемых сервером, а также встроенных средств управления XML. При использовании такого подхода установка «приложения» вместе с его базой данных производится настолько же просто, как и установка самой базы данных; для поддержки пользовательского приложения требуется всего лишь Web-браузер.

3. Технологии самоуправления

3.1. Управление динамическим буферным пулом

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

Рис. 1. Управление размером кэша с использованием обратной связи

Поэтому в SQL Anywhere используется следующий подход к управлению буферным пулом. Вместо того чтобы пытаться «настроить» буферный пул изолированно, сервер производит эту настройку с учетом всех системных требований. Это делается на основе механизма управления с обратной связью с использованием в качестве входных данных размера рабочего набора ОС, объема свободной физической памяти и коэффициента «непопадания» требуемых блоков внешней памяти в буферы пула (см. рис. 1). Размер рабочего набора ОС, опрашиваемый каждую минуту, – это объем реальной основной памяти, используемой процессами операционной системы. При использовании этого цикла управления с обратной связью буферный пул сервера увеличивается и сокращается в зависимости от общесистемного использования ресурсов и политики управления памятью операционной системы. Эта регулировка может очень эффективно производиться в некоторых операционных системах, в которых допускается выделение процессам адресного пространства независимо от предоставления физической памяти. Изменчивость размера буферного пула влияет на обработку запросов. Время выполнения запросов может изменяться в зависимости от объема доступной физической памяти (см. подраздел 3.3).

Кучи. Новой особенностью SQL Anywhere является то, что буферный пул является единым неоднородным пулом страниц всех типов: страниц таблиц, индексов, журналов отката и повторного выполнения (undo и redo), побитовых отображений, свободных страниц и страниц куч. Для поддержки эффективного управления буферным пулом у всех страниц поддерживается один и тот же размер.

Структуры данных, создаваемые и используемые для обработки запросов, включая хэш-таблицы, подготавливаемые операторы, курсоры и т.д., размещаются в страницах кучи. Когда куча не используется – например, когда сервер ожидает следующего запроса FETCH от приложения – куча «разблокируется». Страницы разблокированной кучи могут заниматься менеджером пула буферов и использоваться им для других целей, таких как кэширование страниц или индексов, если это требуется. Когда это происходит, занимаемые страницы откачиваются во временный файл. При поступлении следующего запроса куча снова блокируется с фиксацией ее страниц в физической памяти. Для коррекции указателей в страницах, положение которых в буферном пуле изменилось по причине повторной блокировки, используется метод настройки указателей по адресам (swizzling, cм. [4]).

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

В SQL Anywhere используется модифицированный обобщенный алгоритм «clock» [9]. Кроме того, реализованы методы, позволившие сократить накладных расходов этого алгоритма, хотя по-прежнему быстро распознаются страницы, для которых велика вероятность повторного использования.

3.2. Самоуправляемая статистика

С 1992 г. в SQL Anywhere используются методы обратной связи для автоматического сбора статистики в течение обработки запросов. Вместо того чтобы требовать явной генерации статистических данных путем просмотра или взятия образцов постоянно хранимых данных, сервер автоматически собирает статистику при выполнении запросов. Позднее этот подход к сбору статистики как к побочному результату обработки запросов использовался и другими исследователями [1, 12].

В ранних версиях SQL Anywhere при вычислении предикатов сравнения по равенству и Is Null подсчитывалась частота появления значений в столбцах таблиц, и эти статистические данные постоянно сохранялись в базе данных и использовались для оптимизации последующих запросов. Впоследствии была добавлена поддержка других предикатов сравнения и предиката LIKE. Эта модель опирается на предположение о скошенности распределения данных; предполагается, что значения, не попавшие в статистику о частоте появления значений, относятся к «хвосту» распределения.

В настоящее время в SQL Anywhere используются разнообразные методы сбора статистики и ее автоматической поддержки. Они включают индексную статистику, зондирование индексов, анализ ограничений ссылочной целостности, три типа одностолбцевых самоуправляемых гистограмм и гистограммы соединений.

3.2.1. Реализация гистограмм

В SQL Anywhere используются самонастраиваемые гистограммы, у которых пул бакетов динамически расширяется и сокращается при обнаружении изменений в распределении значений. Границы бакетов со временем сдвигаются для минимизации ошибок и для обеспечения большего разрешения, если это требуется. Как принято, при интерполяции внутри бакета используется предположение о равномерном распределении. В гистограммах SQL Anywhere традиционные бакеты комбинируются со статистическими данными о частоте появления значений, называемыми «одноэлементными бакетами» (singleton buckets, «одиночка»). «Одиночки» реализуются как бакеты, диапазон значений которых состоит из одного значения, и в структуре гистограммы они чередуются с традиционными бакетами. В одноэлементных бакетах сохраняются данные о значениях, которые появляются не менее чем в 1% строк данной таблицы или входят в число N наиболее часто встречаемых значений. Число «одиночек», сохраняемых в любой гистограмме, зависит от размера таблицы и распределения соответствующего столбца, но ограничено диапазоном [0,100].

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

Сбор статистики при обработке запросов. Гистограммы автоматически создаются и обновляются при загрузке данных в базу данных с использованием оператора LOAD TABLE, при обновлении данных с использованием операторов INSERT, UPDATE и DELETE, при создании индексов и при выполнении явного оператора CREATE STATISTICS.

Для создания интегральной функции распределения для каждого столбца применяется модифицированный вариант алгоритма Гринвальда (Greenwald, [5]). Внесенные в алгоритм изменения позволяют существенно сократить накладные расходы на сбор статистики при минимальном ухудшении качества результатов. Гистограммы автоматически обновляются не только при обновлении данных, но при обработке запросов. Вычисление (почти) любого предиката над столбцом базовой таблицы приводит к обновлению гистограммы для этого столбца.

Гистограммы соединений вычисляются «на лету» в процессе оптимизации запросов для определения мощности и распределения промежуточных результатов. Гистограммы соединений создаются на одиночных атрибутах. Если условие соединения задается на нескольких столбцах, то для вычисления и/или ограничения оценок селективности соединения используется комбинация существующих ограничений ссылочной целостности, индексная статистика и показатели плотности данных.

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

3.3. Обработка запросов

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

3.3.1. Оптимизация запросов

В SQL Anywhere оптимизация операторов выборки и обновления данных производится при каждом вызове, хотя имеются два вида исключений. Первый вид исключений составляют простые операторы манипулирования данными, адресуемые к одной таблице, когда расходы на оптимизацию приближаются к расходам на выполнение оператора. В таких случаях операторы не обрабатываются оценочным оптимизатором, а оптимизируются эвристически. Ко второму виду исключений относятся хранимые процедуры и триггеры. Для этих операторов планы доступа кэшируются по принципу LRU для каждого соединения с сервером. Однако план оператора кэшируется только в том случае, когда планы доступа, полученные путем успешной оптимизации этого оператора в течение «периода обучения» являются идентичными. После завершения периода обучения кэшированный план сохраняется для последующего использования. Однако для проверки «свежести» плана оператор периодически верифицируется через интервалы времени, берущиеся по затухающей логарифмической шкале.

Повторная оптимизация каждого оператора означает, что стоимость оптимизации невозможно амортизировать за счет многочисленных исполнений полученного плана. Поэтому оптимизация должна быть дешевой. Одним из нескольких методов, используемых для сокращения стоимости оптимизации, является ограничение размеров пространства поиска оптимизатора. В оптимизаторе SQL Anywhere используется собственный алгоритм перебора, основанный на методе ветвей и границ, с поиском в глубину [8] на «левоглубоких» деревьях обработки (left-deep processing tree)*. Преимуществом поиска в глубину является использование очень небольшого объема памяти; в действительности, большая часть информации, требуемой алгоритмом, может сохраняться в стеке. При использовании этого подхода перебор и оценка стоимости плана чередуются.

Алгоритм перебора, прежде всего, эвристически определяет порядок таблиц при выполнении их соединения. Кроме таблиц и табличных функций, алгоритм перебирает также материализованные представления, соответствующие частям запроса, и сложные подзапросы, преобразуя их в соединения на основе оценок [7]. При генерации стратегии соединения перебираются также физические операции соединения и индексирования, что позволяет оценивать планы с внутризапросным параллелизмом. За счет упорядочивания таблиц алгоритм перебора с самого начала (и автоматически) откладывает потенциальное выполнение операций декартова умножения на как можно более отдаленную фазу. Следовательно, вероятно, что первая сгенерированная стратегия соединения, хотя и необязательно будет оптимальной, будет обладать «разумной» общей стоимостью относительно всего пространства поиска. Алгоритм относится к области алгоритмов и методов «ветвей и границ» в том смысле, что стратегия частичного соединения оставляется для дальнейшего рассмотрения только в том случае, когда ее стоимость, вероятно, меньше стоимости наилучшей полной стратегии, полученной к этому моменту. Интересной особенностью алгоритма перебора, основанного на методе ветвей и границ, является подход, на основе которого пространство поиска сокращается в процессе генерации стратегии соединения. Алгоритм инкрементно оценивает префикс стратегии соединения и прекращает дальнейшие попытки сгенерировать эту стратегию, если стоимость построения промежуточного результата превышает стоимость наиболее дешевого плана, построенного к этому моменту. Поскольку дополнительные квантификаторы могут только увеличить стоимость плана, никакая стратегия соединения с этим префиксом квантификаторов не может быть более дешевой, и весь набор таких стратегий может быть сразу отброшен. Эта отбраковка является сутью парадигмы ветвей и границ. Подробно это описано в [3].

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

Еще одной заслуживающей внимания характеристикой алгоритма перебора стратегий соединений является управляющая стратегия, используемая при поиске [8]. Проблемой перебора стратегий соединений на основе подхода ветвей и границ с ранним прекращением поиска по данной ветви является то, что поиск не является правильно распределенным по всему пространству поиска. Если поиск производится в малой части пространства поиска, то большинство перебранных планов будет очень похоже. В SQL Anywhere эта проблема решается за счет применения регулятора оптимизации (optimizer governor, [10]) для управления поиском. Регулятор динамически выделяет квоту на поиск в разных секторах пространства поиска для повышения вероятности нахождения эффективного плана. Эта квота неравным образом распределяются между схожими стратегиями соединения, так что большая часть работы тратится на сравнение в большей степени разнящихся стратегий. Начальная квота при желании может указываться в приложении, что дает возможность мелкоструктурной настройки усилий по оптимизации каждого оператора.

Рис. 2. Модели DTT

Модель времени обмена с диском. В SQL Anywhere используется модель времени обмена с диском (Disk Transfer Time, DTT, [4]) для оценки ожидаемых расходов на ввод-вывод при выполнении запроса. По умолчанию используется «обобщенная» модель. Она может проверяться с использованием систематической тестовой инфраструктуры над различными архитектурами машин и дисковыми подсистемами. Хотя модель DTT, используемая по умолчанию, хорошо работает для различных аппаратных устройств, в SQL Anywhere обеспечивается механизм ее калибровки с использованием конкретного аппаратного устройства. Калиброванную модель можно сохранить в файле и впоследствии загрузить в несколько других баз данных. Этот подход является очень полезным при кросс-платформенной разработке, когда платформа разработки существенно отличается от целевых платформ.

DTT позволяет обобщить поведение дисковой подсистемы по отношению к приложению (в данном случае, серверу SQL Anywhere). DTT позволяет моделировать амортизированную стоимость чтения одной страницы случайным образом с соседних цилиндров магнитного диска. Если группа цилиндров состоит всего из одного цилиндра, ввод-вывод является последовательным, иначе – случайным. Чем больше цилиндров в группе, тем больше стоимость каждого обмена с диском, поскольку повышается вероятность затрат на подвод головок к нужному цилиндру диска. На рис. 2 проиллюстрированы DTT, используемая по умолчанию, и DTT, калиброванная на основе двух аппаратных конфигураций.

3.3.2. Адаптивное выполнение запросов

Оптимизатор запросов SQL Anywhere может автоматически аннотировать выбранную стратегию выполнения запроса альтернативными операциями планов, которые могут обеспечить более дешевое выполнение, если вариант, выбранный оптимизатором, оказывается не оптимальным во время выполнения, или если для данной операции требуется стратегия с меньшими затратами памяти по распоряжению регулятора памяти (см. ниже). Например, оптимизатор может для стратегии с соединениями с хэшированием построить альтернативную стратегию со вложенными циклами с использованием индексов, которая будет применена, если размер операндов окажется существенно меньше, чем ожидалось во время оптимизации. Соединение на основе хэширования, устранение дубликатов на основе хэширования и сортировка являются примерами операций, для которых имеются альтернативы с меньшими затратами памяти. Для выполнения операции RECURSIVE UNION имеется специальная операция, позволяющая переключаться между несколькими альтернативными стратегиями, причем можно использовать разные стратегии для каждой итерации рекурсии.

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

Каждой задаче, или единице работы внутри сервера SQL Anywhere регулятором памяти сервера выдается некоторая квота доступной памяти. Для каждой задачи вычисляются две квоты:

• жесткое ограничение памяти: если оно превышается, оператор завершается с выдачей сообщения об ошибке;
• мягкое ограничение памяти, которое не должно превышаться алгоритмами обработки запросов, используемыми для данного оператора, если это возможно; при приближении к этому ограничению регулятор памяти может запросить у операций выполнения запроса по возможности освободить память.

Регулятор памяти управляет выполнением запросов путем ограничения потребления памяти при обработке данного оператора. Например, в SQL Anywhere операции, основанные на хэш-методах, выбирают число бакетов на основе ожидаемого числа различных хэш-ключей; цель состоит в том, чтобы в каждом бакете содержалось небольшое число различных значений ключа. В свою очередь, бакеты равномерно делятся на небольшое и фиксированное число разделов. Число разделов выбирается с целью обеспечения баланса между поведением ввода-вывода и коэффициентом разветвления. При обработке хэш-операций регулятор обнаруживает, когда плану запроса нужно перестать выделять дополнительную память – т.е. ситуации превышения мягкого ограничения. Когда это случается, раздел с наибольшим числом строк удаляется из основной памяти. Находившиеся в нем строки записываются во временный файл, и новые строки, попадающие в данный раздел, также записываются на диск.

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

Адаптивный внутризапросный параллелизм. В SQL Anywhere для одного запроса может назначаться несколько нитей выполнения, за счет чего достигается внутризапросный параллелизм. Между нитями, приписанными к одному запросу, отсутствует статическое разделение работы. Параллельный план выполнения запроса организуется таким образом, что любая активная нить может подхватить и выполнить любую небольшую часть работы из дерева потока данных. Единица работы обычно происходит на уровне странице, содержащей строки. Неважно, какая нить выполняет данную единицу работы; весь запрос может быть выполнен в одной нити, если дополнительные нити недоступны. Это означает, что параллельные запросы адаптируются к загрузке сервера.

4. Заключение

Практически все новые возможности, реализованные в SQL Anywhere, служат адаптивности или самоуправляемости. В дополнение к технологиям встраивания и самоуправления, описанным выше, в состав SQL Anywhere входят разнообразные инструментальные средства и технологии, полезные при разработке приложений баз данных, включая утилиту выбора индексов Index Consultant, графические средства администрирования и моделирования и полнофункциональный отладчик хранимых процедур.