Logo    
Деловая газета CitCity.ru citforum.ck.ua - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: citforum.ck.ua
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Tuesday, 03-Jun-2008 09:46:45 EEST

Google
WWW citforum.ck.ua
2007 г

SQL Anywhere: встраиваемая СУБД

Иван Боумэн, Питер Банбулис, Дэн Фаррар, Эйнил Гоуел, Брендан Люсье, Анисоара Ника, Г.Н. Поли, Джон Смирниос, Мэтью Янг-Лэй
Sybase iAnywhere
Пересказ: Сергей Кузнецов
Оригинал: Ivan T. Bowman, Peter Bumbulis, Dan Farrar, Anil K. Goel, Brendan Lucier, Anisoara Nica, G. N. Paulley, John Smirnios, Matthew Young-Lai. SQL Anywhere: An Embeddable DBMS. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, Volume 30, Number 3, September 2007

Оглавление

1. Введение
2. Технологии , обеспечивающие возможности встраивания
3. Технологии самоуправления
3.1. Управление динамическим буферным пулом
3.2. Самоуправляемая статистика
3.2.1. Реализация гистограмм
3.3. Обработка запросов
3.3.1. Оптимизация запросов
3.3.2. Адаптивное выполнение запросов
4. Заключение
Литература

Аннотация

В этой статье описываются средства, обеспечивающие возможность встраивания в приложения СУБД 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, графические средства администрирования и моделирования и полнофункциональный отладчик хранимых процедур.

Литература

  1. A. Aboulnaga and S. Chaudhuri. Self-tuning histograms: Building histograms without looking at data. In ACM SIGMOD International Conference on Management of Data, pages 181–192, Philadelphia, Pennsylvania, May 1999.
  2. I. T. Bowman, P. Bumbulis, D. Farrar, A. K. Goel, B. Lucier, A. Nica, G. N. Paulley, J. Smirnios, and M. Young-Lai. SQL Anywhere: A holistic approach to database self-management. In Proceedings, ICDE Workshops (Self-Managing Database Systems), pages 414–423, Istanbul, Turkey, Apr. 2007. IEEE Computer Society Press.
  3. I. T. Bowman and G. N. Paulley. Join enumeration in a memory-constrained environment. In Proceedings, Sixteenth IEEE International Conference on Data Engineering, pages 645–654, San Diego, California, Mar. 2000.
  4. A. K. Goel. Exact Positioning of Data Approach to Memory Mapped Persistent Stores: Design, Analysis and Modelling. PhD thesis, University of Waterloo, Waterloo, Ontario, 1996.
  5. M. Greenwald. Practical algorithms for self-scaling histograms or better than average data collection. Performance Evaluation, 20(2):19–40, June 1996.
  6. C. Mohan, D. Haderle, B. Lindsay, H. Pirahesh, and P. Schwarz. ARIES: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Transactions on Database Systems, 17(1):94–162, Mar. 1992.
  7. A. Nica. System and methodology for cost-based subquery optimization using a left-deep tree join enumeration algorithm. US Patent 2004/0220923, Nov. 2004.
  8. A. Nica. System and methodology for generating bushy trees using a left-deep tree join enumeration algorithm. US Patent 7,184,998, Feb. 2007.
  9. A. J. Smith. Sequentiality and prefetching in database systems. ACM Transactions on Database Systems, 3(3):223–247, Sept. 1978.
  10. M. Young-Lai. Database system with methodology for distributing query optimization effort over large search spaces. US Patent 6,807,546, Oct. 2004.
  11. H.-J. Zeller and J. Gray. An adaptive hash join algorithm for multiuser environments. In Proceedings of the 16th International Conference on Very Large Data Bases, pages 186–197, Brisbane, Australia, Aug. 1990.
  12. Q. Zhu, B. Dunkel, W. Lau, S. Chen, and B. Schiefer. Piggyback statistics collection for query optimization: Towards a self-maintaining database management system. Computer Journal, 47(2):221–244, 2004.

 

\

Подписка на новости IT-портала citforum.ck.ua
(библиотека, citforum.ck.ua, CitCity)

Новые публикации:

28 мая

citforum.ck.ua:

  • Еще о SmoothWall и немного идеологии (В. Попов)
  • Linux в школе: дистрибутивы пилотного проекта (С. Голубев)
  • Новые Блогометки:

  • Frets on Fire: игра на гитаре с клавиатуры
  • GNU Units: преобразование величин между различными шкалами
  • QEMU: простой и быстрый эмулятор процессора
  • Проверка контрольных сумм, закачка клипов с youtube и менеджер Grub для редактирования меню
  • GConf-cleaner - знакомая игрушка для эмигрантов
  • Wbar - заманчивый dockbar. И никакого compiz'a!
  • BluePad - GNOME-марионетка под управлением телефон
  • 21 мая

    citforum.ck.ua:

  • Методические рекомендации к использованию Линукса в учебном компьютерном кабинете школы
  • Все Linux'ы под одной крышей (репортаж с семинара R-Style)
  • Новые Блогометки:

  • Заливаем музыку на плеер
  • Накопительный вклад в "прокачку" системы
  • GMail + оповещение о приходе корреспонденции
  • code2html - публикация кода или гармония содержания и формы
  • GTK клиенты для MPD
  • Zimbra. Первые впечатления
  • Ubuntu. Как установить mysql-server без exim4
  • Ubuntu и GPRS
  • 14 мая

    CitCity:

  • Интервью с Дональдом Кнутом (Перевод: С. Кузнецов)
  • citforum.ck.ua:

  • Linux в школе: подготовка к миграции (С. Голубев)
  • О Microsoft Windows, Линуксе и бесплатном сыре. Профессор Выбегалло наносит ответный удар
  • Дело Ханса Рейзера. Версия Uncle_Theodore
  • Новые Блогометки:

  • MOC: музыка в консоли - музыкальный проигрыватель, основанный на ncurses
  • Hugin: создавайте потрясающие панорамы из ваших фотографий
  • HTTP сервер в одну строку: версия 2.0
  • HTTP сервер размером в 222 байта
  • hint [9] swiss army knife
  • 6 мая

    citforum.ck.ua:

  • Linux в школе: в чем же выгода? (С. Голубев)
  • Дело Ханса Рейзера
  • 28 апреля

  • Возможности эффективного использования языка SQL без нарушения основных принципов реляционной модели данных
  • Материалы конференции "Корпоративные базы данных-2008" (тезисы докладов и презентации)
  • CitCity:

  • Очередной снэпшот технологии баз данных (С. Кузнецов)
  • citforum.ck.ua:

  • Linux в школе: мифы про школу и информатику (С. Голубев)
  • "Крикливое меньшинство" мешает распространению открытого ПО
  • 22 апреля

  • Один из подходов к организации объектной системы на основе реляционной СУБД
  • Обзор журнала Computer:

  • Тинэйджеры и музыкальная коммерция
  • citforum.ck.ua:

  • Диски, разделы, буквы... (В. Попов)
  • Новые Блогометки:

  • ingimp: повышение удобства интерфейса GIMP на основании статистики использования
  • Screen-message: используйте экран для передачи сообщений
  • knetworkmanager: победа над кошмарами WiFi-WLan-WEP-WPA
  • revelation: менеджер паролей Gnome
  • 17 апреля

    citforum.ck.ua:

  • Изучаем Linux:
    • Подготовка к миграции
    • Критерии выбора
    • Дистрибутив ALTLinux
    • ASPLinux
    • Debian
    • Linux XP Desktop
    • Mandriva
    • MOPSLinux
    • openSUSE
    • Ubuntu

    CitCity:

  • Рынок BI-платформ. Мнение аналитиков
  • Требования к инструментам интеграции данных
  • Матрица. Эволюция (технология цифровой фотографии)
  • 10 апреля

  • Принципы организации иерархии атомарных литеральных типов объектной системы на основе РСУБД Microsoft SQL Server 2005
  • citforum.ck.ua:

  • Експресс полярный, он же - "галантный медведь"
  • Новые Блогометки:

  • Liquidsoap: гибкий клиент потокового аудиовещания для сервера Icecast и многое другое…
  • KRename: мощное средство переименования
  • apt-listbugs: узнавайте о критических ошибках перед каждой установкой с APT
  • Несколько слов о ГИС...
  • OpenOffice и все-все-все...
  • Цифровые фотографии. Наводим порядок
  • Фотоальбомы
  • 2 апреля

  • NULL, трехзначная логика и неопределенность в SQL: критика критики Дейта
  • Критика критики критики Дейта
  • Сервис-ориентированный подход в бизнес-аналитике от Oracle
  • Хранение данных на клиенте. DOM Storage и его аналоги
  • citforum.ck.ua:

  • Conky - системный монитор
  • Звук в Linux
  • Linux swap space
  • Описание пакетов KDE
  • 27 марта

    Обзоры журнала Computer:

  • Мечты Дэвида Харела
  • О вреде избыточного питания компьютеров
  • SOA: просто для большинства, сложно для меньшинства
  • CitCity:

  • 12 дюймов и меньше - а стоит ли "овчинка" выделки?
  • Сравнение электронных автомобильных карт и автонавигаторов
  • BI-технологии, что нас ждет в ближайшие годы
  • citforum.ck.ua:

  • И снова Старый Оскол: второй семинар по свободному софту
  • Новые Блогометки:

  • Xdiskusage: где место?!
  • TTF-Inconsolata: открытый шрифт для вашего терминала и красивых распечаток кода
  • Jed: карманный EMACS
  • Ipcalc: полезная информация об IP и маске сети
  • IPTraf: монитор локальной сети с интерфейсом ncurses
  • Burgerspace: свободный клон классической аркады «Burgertime»
  • 19 марта

  • Технология проектирования модели предприятия на основе универсальной модели данных
  • CitCity:

  • Гимн героям Microsoft
  • citforum.ck.ua:

  • Колонки Алексея Федорчука из журнала Linuxformat
  • Завершение цикла Сергея Голубева "Linux для начинающих":
    • Работа в сети
    • Пользовательские приложения

    Новые Блогометки:

  • И вечный бой... со шрифтами
  • Введение в API для карт Google
  • Conky: хорошо настраиваемый системный монитор для X
  • Newsbeuter: чтение RSS из консоли
  • Katapult: ускоренный и упрощенный доступ к приложениям, закладкам и файлам
  • GPRename: пакетное переименование с интерфейсом GTK2-Perl
  • Duplicity: шифрованное и экономное для трафика резервное копирование на основе алгоритма rsync
  • Listadmin: консольное управление очередью модерации Mailman
  • 12 марта

  • Восход и закат High Performance Fortran: наглядный урок истории (пересказ: С.Кузнецов)
  • citforum.ck.ua:

    Новые Блогометки:

  • Ccze: хорошее модульное средство подсветки логов
  • PWSafe - кроссплатформенное средство для работы с паролями
  • colordiff - подсветка для diff
  • psmisc: рассмотрим ближе стандартный пакет
  • Работа с сетью
  • xkb, узелок на память
  • ffmpeg-php
  • debiannotes:desktop:prettyfonts
  • 5 марта

    citforum.ck.ua:

  • Ричард Столлман в Москве
  • О мудром доценте замолвите слово... (Интенсификация Малаховна)
  • Новые Блогометки:

  • "Десктопизация" OpenBSD
  • weather: проверяйте сводку и прогноз погоды из командной строки
  • hpodder: клиент подкастов, который просто работает
  • bc: язык численных расчетов с произвольной точностью
  • Decibel: аудиоплеер для людей
  • GNU Wget: загрузите весь понравившийся сетевой контент на локальный компьютер
  • Deborphan: найдите ненужные пакеты
  • Kivio: мощный и простой в использовании редактор блок-схем
  • Cowsay: настраиваемая говорящая и думающая корова
  • Thoggen: основанная на GTK+ программа для извлечения видео с DVD
  • 28 февраля

  • Подбор и развитие команд
    Глава из книги «Руководство командой разработчиков программного обеспечения. Прикладные мысли» (С.Архипенков)
  • citforum.ck.ua:

    Дискуссия об анонимусах:

  • К комментаторам
  • Windows против Linux - психологический портрет участников форумов
  • Новые Блогометки:

  • Nokia N810 - Linux Inside
  • LiMo - стандарты Linux для сотовых телефонов
  • timer-applet: таймер для панели GNOME
  • Debfoster: удалите пакет и все его зависимости
  • GPW: генератор произносимых паролей
  • AMOR: общество для рабочего стола
  • 20 февраля

    citforum.ck.ua:

    Новые Блогометки:

  • Кое-что о приложениях KDE 4
  • Инструкция по установке KDE 4 в Ubuntu
  • Настоящие мужчины ставят KDE из SVN!
  • Начат переход Amarok на Qt 4.4
  • Marble
  • Dillo - сверхбыстрый браузер
  • Создаем резервные копии настроек программ и важных файлов в Ubuntu LInux
  • NTP: всегда вовремя
  • VYM - простое средство зарисовки мыслей и планирования
  • KBibTeX: простой и гибкий редактор библиографий для KDE
  • Дискуссия Windows vs Linux:

  • Жил-был Мальчик, или Сказочка о Том, Откуда Берутся "КУЛХАЦКЕРЫ", ненавидящие Линукс и Юникс
  • 13 февраля

  • Терминологический словарь Wi-Fi
  • Задача проектирования базы данных методом нормализации
  • CitCity:

  • Лучшие смартфоны начала 2008 года
  • citforum.ck.ua:

  • Первый взгляд на Firefox 3.0
  • Open Source на Белгородщине: семинар в Старом Осколе
  • Что такое KDE?
  • Цикл о Slackware:

  • Русский в консоли
  • Быстрая настройка Иксов
  • xorgconfig - консольный подход
  • 6 февраля

    citforum.ck.ua:

  • Мобильный Linux – вчера, сегодня, завтра
  • Чем записать диски в Linux? Попробуй Brasero!
  • Консольные команды
  • Рецепты. Кое-что о программе mplayer
  • Slackware:
    • Что такое Slackware?
    • Установка Slackware - Загрузка
    • Категории программного обеспечения
    • Структура файловой системы
    • Система инициализации Slackware Linux
    • Скрипты инициализации уровня запуска

    30 января

  • Обзор алгоритмов MOLAP
  • CitCity:

  • BI-технологии 2007. Итоги года
  • Рынок СУБД для Хранилищ данных 2007. Итоги года, тенденции
  • Обзор рынка BI (по результатам исследований IDC, OLAP Report, Gartner)
  • Модель зрелости BI
  • citforum.ck.ua:

  • Владимир Попов: За что я люблю Linux
  • Священные войны
  • 23 января

  • Data Mining от Oracle: настоящее и будущее
  • Комментарии к статье Ч.Бергера «Data Mining от Oracle: настоящее и будущее»
  • Байесовский классификатор и регрессионная модель в ORTD: практический пример
  • citforum.ck.ua:

    Дискуссия Windows vs Linux:

  • Программисты и фирмы: кто кого
  • О "чистых пользователях"
  • Новые Блогометки:

    • Почему Jabber, а не ICQ?
    • Archlinux install quick
    • Arch на IBM Z60m
    • Arch + IBM R50e
    • OpenBSD - сборка E17-cvs (или ещe одна маленькая победа разума)
    • OpenBSD - всe для Человека и ради Человека...
    • PekWM
    • E17 и "прозрачность"
    • E17 - приятные мелочи (multimedia)
    • SuSE + Enlightenment = угробил целый день

    16 января

  • Вьетнам компьютерной науки (пересказ - С.Кузнецов)
  • Пример построения автоматизированного управления дисками (ASM) (В. Пржиялковский)
  • CitCity:

  • 2008 год: антипрогноз
  • citforum.ck.ua:

    Новые Блогометки:

    Сети и Интернет:

    • Mozilla firefox. Шрифты в меню
    • Screen tips
    • Liferea: программа чтения RSS для GNOME
    • HTTrack: скачивание и зеркалирование сайтов
    • Clusterssh: работа с несколькими сеансами SSH через общий интерфейс

    Десктопы:

    • Fluxbox & xinitrc. Some new tips
    • Как я конфигурировал xdm

    Системы:

    • SuSE 10.2: zypper - еще один способ установки пакетов
    • cpipe: определите пропускную способность конвейера команд
    • gddrescue: средство восстановления данных с поврежденных носителей
    • VirtualBox: ваш виртуальный ПК

    Приложения:

    • MyTop: top для MySQL

    10 января

    citforum.ck.ua:

    Дискуссионный клуб:

  • Краткое руководство по общению с никсофилами (Интенсификация Малаховна Сергина-Гейтс)
  • О троллях
  • Пещера горного короля: заметки о троллинге
  • Новые Блогометки:

    Сети и Интернет:

    • Делаем блог на Drupal
    • Использование lftp
    • Устанавливаем FTP сервер ProFTPd с TLS шифрованием
    • Управляем файлами на FTP сервере с помощью FileZilla

    Десктопы:

    • fluxbox.autorun
    • 15 человек на сундук мертвеца! (или песнь о зарытых сокровищах)

    Системы:

    • Живой Debian или рабочее место в кармане
    • Разбивка hdd

    Приложения:

    • Cat Excel files
    • Vim: меню выбора кодировок

    26 декабря

    citforum.ck.ua:

  • В Блогометках открыты разделы:
    • Софт для Windows
    • Сети и Интернет
  • dwm. От статики к динамике
  • Установил Solaris
  • Новая Дискуссия:
    • Нужен ли русский Linux?

    19 декабря

  • SQL Anywhere: встраиваемая СУБД
  • citforum.ck.ua:

  • В разделе Блогометки появились рубрики:
    • Десктопы
    • Приложения
    • Системы
  • Подробно о разделе: Блоги и блогометки: открываем сезон промывки
  • 13 декабря

    CitCity:

  • Microsoft и Барселона: сюрреализм?
  • citforum.ck.ua:

  • Открыт новый раздел Блогометки
  • ZFS в подробностях. 1. Былое и ныне
  • 5 декабря

  • Архитектура предприятия: основные определения
  • Архитектуры для государственных ведомств. Примеры
  • Обзор журнала Computer:

  • Высокопроизводительные встроенные системы
  • citforum.ck.ua:

  • Продолжение цикла Linux для начинающих:
    • Пользовательские интерфейсы
    • Файлы
    • Системы настройки

    Все публикации >>>




IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей Пресс-релизы -
Послать комментарий
Информация для авторов
Rambler's Top100 This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...