5. Построение Систем реального времени в классическом понимании, система реального времени это прикладная система, работа которой каким-либо образом должна быть согласована с реальным временем



Скачать 111.24 Kb.
Дата24.04.2016
Размер111.24 Kb.
5. Построение Систем реального времени

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

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

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

Зачастую в системах реального времени необходимо манипулировать большими объемами разделяемых данных, и это естественным образом приводит к необходимо­сти использования СУБД. Однако, классические системы управления базами данных не очень пригодны для применения в системах реального времени, поскольку к СУБД в таких системах предъявляется ряд новых требований, и многие из методов, приме­няемых в классических СУБД, их совершенно не учитывают.

Типичными системами реального времени, в которых используются системы управле­ния базами данных, являются информационные системы управления и системы упра­вления процессами в реальном времени.

Наибольшую потребность в высокопроизводительных системах реального времени испытывает отрасль телекоммуникаций, где множество сервисов осуществляется в реальном времени. Здесь бывает необходимо обрабатывать тысячи вызовов в секун­ду, каждый из которых сопровождается тремя - пятью обращениями к БД. Традицион­но такие функции реализовывались в специализированном коммутирующем оборудо­вании, что ограничивало возможности усовершенствования и масштабирования си­стем. Сегодня эти функции все чаще возлагаются на универсальные компьютеры со стандартным программным обеспечением. Среди них - преобразование телефонных номеров, начинающихся на 800, запись номеров абонентов, пользующихся переадре­сацией звонков, и т. д. Еще одна задача, требующая очень высокой производительно­сти, - поддержание реестра местоположения абонентов (Home Location Register, HLR) в системах сотовой связи. При перемещении мобильного телефонного аппарата для реализации полноценного роуминга с сохранением всех полномочий пользователя необходимо очень быстрое обновление БД, а для определения специфического набо­ра сервисов, доступных тому или иному абоненту, необходимо выполнять операции реляционного соединения таблиц (join-tables), которые очень эффективно реализуют­ся в оперативной памяти.

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

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

Эти примеры иллюстрируют две наиболее распространенных особенности, присущие СУБД в системах реального времени:



  • задачи должны быть завершены к определенным моментам времени;

  • данные в базе всегда должны оставаться относительно свежими.

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

Одним из наиболее ярких представителей систем управления базами данных реаль­ного времени является Oracle TimesTen In- Memory Database.

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

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

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

Архитектура баз данных реального времени

Основное отличие архитектуры баз данных реального времени от классических СУБД заключается в размещении базы данных в оперативной памяти.

Идея размещения базы данных в оперативной памяти достаточно очевидна, а основ­ные усилия по оптимизации производительности промышленных РСУБД и так неред­ко сводятся к копированию довольно большого фрагмента БД с диска в память (так

называемый кэш) и дальнейшей его обработки, минуя обращение к медленным опе­рациям дискового ввода-вывода.

Действительно, объем ОЗУ мощных серверов уже достигает десятков гигабайт, а 64-разрядные архитектуры постепенно добираются и до настольных ПК. И если сегодня есть сомнения относительно востребованности 64-разрядных вычислений в тех или иных областях, то только не в области РСУБД. Как известно, 32-разрядные процессо­ры позволяют непосредственно обращаться к 4-Гб оперативной памяти, а 64-разряд­ные способны адресовать 16 млн. терабайт, что фактически снимает какие-либо огра­ничения на размер базы данных, целиком размещаемой в ОЗУ.

Сначала такие СУБД было принято относить к категории MMDM (Main Memory Data Manager), но в последние годы в обиход вошла аббревиатура IMDB (In-Memory Da­tabase). Скорость обработки информации инструментами IMDB в 10-20 раз превы­шает показатели традиционных "дисковых" РСУБД. Если вспомнить, что обращение к данным в ОЗУ осуществляется на несколько порядков быстрее, чем к тем, что на­ходятся на диске, указанный выше выигрыш кажется весьма скромным. Дело, од­нако, в том, что сегодня традиционные РСУБД фактически тоже манипулируют большими наборами данных {например, теми, что запрашиваются чаще всего), предварительно извлеченными из дисковой подсистемы и помещенными в ОЗУ. Более того, если размер ОЗУ позволяет разместить там всю БД, то многие тради­ционные РСУБД так и делают. Что же нового в технологическом плане предлагают базы данных реального времени?

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

В IMDB, кроме того, совершенно другая структура хранения данных в ОЗУ. Обычные РСУБД копируют данные с диска целыми страницами. При этом структура их остает­ся такой же, какой она была на диске, что, естественно, негативно отражается на ал­горитмах обработки данных. Благодаря более рациональной схеме хранения наклад­ные расходы (дополнительная память для временных данных) в IMDB не превышает 20% (в обычных РСУБД - до 50%).



Сравнение TimesTen и обычной дисковой СУБД

За счет чего же достигается такое уменьшение времени отклика при использовании InMemory Database? На рисунке 1 приведены архитектуры традиционной дисковой СУБД и СУБД TimesTen.

Из рисунка видно, что во-первых приложения TimesTen осуществляют прямой доступ к БД. При этом экономится время на передачу SQL запроса от приложения к СУБД и на возврат результата (IPC).

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




оперативной памяти. ImMemory Database не использует буферный кэш и не несет на­кладных расходов по управлению буферным кэшем и по загрузке/выгрузке данных между диском и кэшем. Потери на операциях ввода- вывода сведены к минимуму.



Индексные структуры

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



В- деревья

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

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

На Рис. 1 приведена структура индекса на основе В-дерева. Каждая вершина ин­декса на основе Т-дерева содержит несколько указателей на записи таблицы ба­зы данных на диске.

В Oracle TimesTen, в отличие от традиционных систем управления базами данных, используются индексы на основе Т-деревьев. Т-дерево оптимизировано для до­ступа к оперативной памяти и имеет гораздо более экономичную структуру, чем В-дерево. В отличие от В-деревьев, в каждом узле Т-дерева хранится 64 значения ключа индекса, каждое из которых имеет прямую ссылку на адрес в памяти, где хранится индексируемая запись базы данных. Для навигации по дереву использу­ются указатели "меныше-или-равно" и "больше", представляющие собой непо­средственные ссылки на адрес в памяти, а не на дисковую страницу. Всего за две

операции сравнения алгоритм поиска Т-дерева "узнает": находится ли искомое значение в текущем узле или где-либо еще в памяти. И с каждым переходом по указателю узла индекса область поиска сокращается вдвое.

В Oracle TimesTen, в отличие от традиционных систем управления базами данных, используются индексы на основе Т-деревьев. Т-дерево оптимизировано для до­ступа к оперативной памяти и имеет гораздо более экономичную структуру, чем В-дерево, В отличие от В-деревьев, в каждом узле Т-дерева хранится 64 значения ключа индекса, каждое из которых имеет прямую ссылку на адрес в памяти, где хранится индексируемая запись базы данных. Для навигации по дереву использу­ются указатели "меньше-или-равно" и "больше", представляющие собой непосред­ственные ссылки на адрес в памяти, а не на дисковую страницу. Всего за две опе­рации сравнения алгоритм поиска Т-дерева "узнает"; находится ли искомое значе­ние в текущем узле или где-либо еще в памяти. И с каждым переходом по указа­телю узла индекса область поиска сокращается вдвое.

Использование индексов на основе Т-дерева помогает решить задачу управления данными в TimesTen - уменьшить требования к памяти, отказаться от дисковых операций ввода/вывода и упростить программу поиска.

Управление транзакциями

Как и в большинстве обычных РСУБД, в Oracle TimesTen реализованы механизмы транзакций и управление блокировками на уровне БД, таблицы или одной записи. Имеются средства тиражирования, которые позволяют поддерживать "горячее" ре­зервирование БД (схема "главный - подчиненный") или балансировку нагрузки (од­норанговая схема). Все это способствует повышению уровня надежности и готов­ности БД, но возникает вполне закономерный вопрос: нужен ли здесь вообще жест­кий диск и что будет с данными в случае аварийного отключения питания сервера ?

Конечно, без диска обойтись не удастся, но роль его в данном случае совершенно иная. Ведь основной средой хранения теперь является оперативная память, а диск нужен либо для первоначальной загрузки, либо для восстановления БД после сбоя.

В Oracle TimesTen используются механизм контрольных точек и журнал регистра­ции транзакций. Оба эти средства позволяют восстановить состояние БД на мо­мент отказа и отменить незафиксированные транзакции.

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

Заключение

Сбор и анализ производственных данных в режиме реального времени играет ре­шающую роль в удовлетворении потребностей рынка в качественном продукте и в сокращении времени прохождения продукта от производителя к рынку. Передавая производственные данные в систему управления, Oracle TimesTen по существу яв­ляется "системой поддержки принятия решений" на предприятии. Многие клиенты используют управляющую обратную связь в режиме реального времени, чтобы обеспечить замкнутый цикл контроля качества.



Если обычная коммерческая СУБД может обеспечить время отклика в несколько миллисекунд, то СУБД реального времени работают на порядок быстрее. Их мож­но использовать не только как самостоятельные СУБД в памяти, но и как быстрый кэш к традиционным СУБД (например, Oracle 10g). При этом на время работы кэ-шируются только те данные, к которым нужен быстрый доступ, а все остальные данные хранятся в дисковой СУБД.


База данных защищена авторским правом ©bezogr.ru 2016
обратиться к администрации

    Главная страница