В статье кратко представлены основы разработки баз данных реального времени при создании автоматизированных систем реального времени. Такие базы данных могут быть полезны в области банковского дела, медицины, автоматизации сложных технологических процессов, научного анализа данных.
Ключевые слова: база данных, реальное время, СУБД.
СУБД реального времени является наследует основные свойства системы реального времени. Такие СУБД должны обеспечивать хранение, обработку и вывод данных в режиме реального времени. Прежде чем перейти к базам данных реального времени стоит разобраться с понятием системы реального времени. Назовем системой реального времени аппаратно-программный комплекс, реагирующий в предсказуемые времена на непредсказуемый поток внешних событий.
Это определение означает, что:
Система должна успеть отреагировать на событие, произошедшее на объекте, в течение времени, критического для этого события (meet deadline). Величина критического времени для каждого события определяется объектом и самим событием, и, естественно, может быть разной, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается ошибкой для систем реального времени.
Система должна успевать реагировать на одновременно происходящие события. Даже если два или больше внешних событий происходят одновременно, система должна успеть среагировать на каждое из них в течение интервалов времени, критического для этих событий.
Хорошим примером задачи, где требуется СРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот имеет лишь маленькое временное окно, когда он может ее взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и, следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он позиционируется раньше, то деталь еще не успеет подъехать, и робот заблокирует ей путь.
Другим примером может быть самолет, находящийся на автопилоте. Сенсорные серводатчики должны постоянно передавать в управляющий компьютер результаты измерений. Если результат какого-либо измерения будет пропущен, то это может привести к недопустимому несоответствию между реальным состоянием систем самолета и информацией о нем в управляющей программе. Различают системы реального времени двух типов — системы жесткого реального времени и системы мягкого реального времени.
Системы жесткого реального времени не допускают никаких задержек реакции системы ни при каких условиях, так как:
Результаты могут оказаться бесполезны в случае опоздания.
Может произойти катастрофа в случае задержки реакции.
Стоимость опоздания может оказаться бесконечно велика.
Примеры систем жесткого реального времени — бортовые системы управления, системы аварийной защиты, регистраторы аварийных событий.
Системы мягкого реального времени характеризуются тем, что задержка реакции не критична, хотя и может привести к увеличению стоимости результатов и снижению производительности системы в целом. Пример — работа сети. Если система не успела обработать очередной принятый пакет, это приведет к таймауту на передающей стороне и повторной посылке (в зависимости от протокола, конечно). Данные при этом не теряются, но производительность сети снижается. Основное отличие между системами жесткого и мягкого реального времени можно выразить так: система жесткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени — не должна опаздывать с реакцией на событие [1].
Таким образом СУБД реального времени — СУБД, которая использует вычисления в реальном времени, чтобы обрабатывать рабочие нагрузки, состояние которых постоянно меняется [2]. Это отличается от стандартных СУБД, хранящих постоянные данные, зачастую неменяющиеся со временем. Например, рынок ценных бумаг меняется очень быстро, и он динамичен. Вычисления в реальном времени подразумевают то, что транзакция будет обработана настолько быстро, чтобы результат можно было получить практически сразу.
 Основы
Базы данных реального времени — это обычные базы данных с дополнительными мощностями, которые могут обеспечить надежные ответы. Используются постоянные времени, которые составляют определенный диапазон значений времени, для которого данные ещё актуальны. Этот диапазон можно назвать временем актуальности. Стандартная база данных не может работать в таких условиях, так как несоответствия между объектами реального мира и данными, которые его представляют слишком серьёзные. Эффективная система должна быть в состоянии обрабатывать срочные запросы, возвращать только достоверные по времени данные и поддерживать приоритетные очереди. Для ввода данных в записи, зачастую датчик или устройство ввода отслеживает состояние физической системы и обновляет базу данных новой информацией, которая отражает физическую систему более точно. При проектировании системы базы данных в режиме реального времени, следует рассмотреть, как факты будут связаны с системой реального времени. Нужно подумать, как представлять значения в базы данных так, чтобы обработка транзакций проходила правильно, и согласованность данных не имела никаких нарушений.
При разработке базы данных реального времени, которая обеспечивала бы необходимые временные ограничения для данных и транзакций, нужно рассмотреть определенное количество аспектов. Ниже представлен список некоторых из них [3]:
Данные, транзакции и системные характеристики: База данных реального времени должна поддерживать не только логическую согласованность данных и транзакций, но ещё и соответствовать временным свойствам транзакций, временной согласованности данных.
Очередность и обработка транзакций: Очередность и обработка транзакций — самая важная часть современных исследований в области баз данных реального времени
Управление потоками ввода/вывода и буферами данных: В то время как очередность обработки центральным процессором очень важна, также нужно учитывать и приоритеты транзакций при управлении вводом/выводом и буферами данных.
Параллельная обработка
Распределенность: Множество приложений, которым требуется база данных реального времени не расположены на одной ЭВМ. Вместо этого, они распределены, и может потребоваться распределение данных реального времени также.
Качество приложения и качество данных: Удовлетворять и требованиям логической согласованности базы данных, и требованиям временной согласованности данных очень сложно. Следовательно, нужно прийти к такому компромиссу, который учитывал бы что более важно.
 Структура
Система реального времени состоит из контролирующей системы и подконтрольной системы. Последняя это среда, с которой компьютер и его программное обеспечение взаимодействует. Контролирующая система взаимодействует со средой посредством чтения данных с различных датчиков, например датчиков расстояния или скорости. Это важно, чтобы отражение состояния среды в системе с высокой точностью совпадало с настоящим состоянием среды. Иначе, действия контролирующей системы могут быть разрушающими. Следовательно, своевременный мониторинг среды, а также своевременная обработка информации крайне необходимы. Во многих случая считанные данные обрабатываются для получения новых данных.
 Данные и согласованность
Нужно поддерживать согласованность между данными в базе данных и реальными данными. Это приводит к понятию темпоральная согласованность. Темпоральная согласованность состоит из двух компонентов [2]:
Абсолютная согласованность: Данные верны только между определенными моментами во времени. Это требуется для сохранения базы данных в актуальном состоянии.
Относительная согласованность: Различные объекты данных, которые используются для получения новых данных, должны быть согласованы друг с другом.
Объект данных темпорально согласован тогда и только тогда, когда он абсолютно согласован и относительно согласован. Каждая запись в базе данных реального времени состоит из текущего состояния объекта наблюдения, двух временных меток и значения интервала времени, в течении которого запись ещё актуальна. Первая определяет, когда данная запись была последний раз прочитана. Вторая определяет, когда данная запись была последний раз изменена.
 Транзакции
Транзакция — это набор операций чтения, записи, отмены и подтверждения. Read, write, abort, commit. Примем соответствующие аббревиатуры r, w, a, c. Также примем знак ≺i как обозначение предшествования. Следующие правила верны для транзакции Ti [3]:
- Ti ⊆ {ri [x],wi [x] | где x — это элемент данных } ∪ {ai,ci};
- ai ∈ Ti только если ci∉Ti;
- Если t это ci или ai, для любой другой операции p ∈ Ti, p ≺it;
- Если ri [x], wi [x] ∈ Ti, тогда ri [x] ≺iwi [x] или wi [x] ≺iri [x].
Транзакция в реальном времени — это транзакция с дополнительными атрибутами, характерными для реального времени. Эти атрибуты используются для составления очереди и контроля параллельного выполнения. Дополнительные атрибуты такие:
Временные константы.
Критичность — мера, оценивающая насколько важно для данной транзакции соответствовать установленным рамкам.
Ценность — определяет насколько важно вообще выполнить транзакцию.
Требования к ресурсам — определяет количество операций ввода/вывода, ожидаемое использование ЦП и т. п.
Ожидаемое время исполнения. Обычно его очень сложно предсказать, но его можно основать на экспериментальных значениях для худшего случая.
Требования к данным.
Периодичность — значения периода вызова транзакции, если транзакция периодична.
Основываясь на этих атрибутах, доступности информации и типе транзакции, транзакция в реальном времени может быть охарактеризована по следующим критериям [3]:
Тип реального времени: жесткое или мягкое.
Периодичность: периодическая, спорадическая или апериодическая
Доступ к данным: определенный (только чтение, только запись, или обновление) или случайный.
Необходимые данные: известные или неизвестные
Требование к времени выполнения: известное или неизвестное
Доступный тип данных: непрерывный, дискретный, или оба
Базы данных реального времени применяют все три типа транзакций, которые упоминаются в литературе по базам данных:
Только запись
Только чтение
Обновление
Обработка транзакций и контроль параллельного выполнения в базе данных реального времени должно быть основано на приоритетах и критичности транзакций. Традиционные методы обработки транзакций в случае базы данных реального времени могут привести к нежелаемому поведению системы. Ниже перечислены четыре типизированные проблемы очередности транзакций [3]:
Лишний перезапуск: происходит, когда транзакция высокого приоритета прерывает транзакцию низкого приоритета, и затем транзакция высокого приоритета отменяется, так как она не уложилась в сроки выполнения
Лишнее ожидание: происходит, когда транзакция низкого приоритета ожидает выполнения транзакции высокого приоритета, и затем транзакция высокого приоритета отменяется, так как она не уложилась в сроки выполнения
Лишнее выполнение: происходит, когда транзакция низкого приоритета перезапускается из–за конфликта с ещё выполняющейся транзакцией высокого приоритета
Ненужный перезапуск.
 Очередность транзакций
Цель очередности транзакций — добиться того, чтобы как можно больше транзакций были выполнены в срок. Существует множество различных политик очередности транзакций. Некоторые из них будут рассмотрены в текущей работе. Каждая транзакция в реальном времени имеет значимость, то есть ценность выполнения данной транзакции в определенный момент времени. Также каждая транзакция имеет дедлайн — предельный момент времени, после которого выполнение транзакции не имеет смысла. Алгоритм создания очереди состоит в назначении транзакциям приоритетов. Для транзакций существуют зависимости значимости от времени, относительно дедлайна. Они бывают разные, но ниже представлены основные простые функции [2]:
Жесткий дедлайн: невыполнение транзакции вовремя может привести к катастрофе
Мягкий дедлайн: имеет смысл выполнять, даже если дедлайн пропущен
Твердый дедлайн: когда срок выполнения истекает, выполнение транзакции не имеет смысла, но и не несет потерь.
Рис. 1. Зависимость значимости транзакций от времени
 Контроль параллельного выполнения
Существует множество способов классификации планировщиков. Одним из очевидных способов является классификация по типу распределения базы данных. Некоторые планировщики требуют полного воспроизведения базы данных, другие могут работать с частично воспроизведенными или разделенными базами данных. Также планировщики могут быть классифицированы согласно топологии сети. Однако, самая распространенная классификация основана на базовых методах синхронизации, т. е. методах, которые предоставляют доступ к данным и позволяют упорядочить выполнение транзакций в соответствии с набором правил. Существует две точки зрения: пессимистичная, которая предполагает, что большое количество транзакций будет конфликтовать друг с другом, и оптимистичная, которая предполагает обратное. Пессимистичные методы синхронизируют одновременное выполнение операций в начале их выполнения, а оптимистичные задерживают синхронизацию операций до их окончания.
 Заключение
Область разработки баз данных реального времени совершила огромный прогресс относительно небольшого времени своего существования. На данный момент в мире множество технологических областей переходит на более современные системы с большим количеством входных данных и высоким потоком информации, где необходимы базы данных реального времени. Предоставленная в статье информация будет полезна при проектировании и эксплуатации баз данных реального времени.
Литература:
- Зыль С. Н. Проектирование, разработка и анализ программного обеспечения систем реального времени — СПб.: БХВ-Петербург, 2010.
- Buchmann, A. Real Time Database Systems. — Idea Group, 2005.
- Lindstrom, J. Real Time Database Systems. — Helsinki, Finland, 2008.