Оптимизация под конкретную систему

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

Один из примеров использования этой идеи – деление транзакций на классы сенсорных, порожденных и пользовательских и назначение более высокого приоритета пользовательским транзакциям, как наиболее важным.

Классификация пользовательских транзакций

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

· время прихода в систему;

· период;

· временные ограничения;

· приоритет;

· примерное время выполнения;

· необходимые данные;

· функция полезности.

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

· типу директивного срока (мягкие, жесткие или крепкие);

· типу поступления в систему (периодические, апериодические);

· типу доступа к данным − предопределенный (только чтение/только запись/обновление) или произвольный (т.е. заранее неизвестный);

· известны ли необходимые данные?

· известно ли примерное время выполнения?

· типу используемых данных: непрерывные, дискретные, оба.

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

 

СУБД реального времени в оперативной памяти

Посмотрим, как идею оптимизации для отдельных классов транзакций можно применить к одной из специализированных СУБД реального времени.

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

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

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

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

 

Использование сложных моделей транзакций

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

Для примера мы рассмотрим применение активных баз данных в системах реального времени [79].

 

Активные базы данных

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

Примерами событий могут быть COMMIT или ABORT транзакции, операции доступа к данным или внешние события. Условие обычно представляет собой некоторый предикат от текущего состояние базы данных. Действие − это транзакция, которая выполняется в ответ на определенную ситуацию, где ситуация − это комбинация события и условия.

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

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