E-mail:
Пароль:
Забыли пароль?

ЛИНТЕР - технология достижений

ЛИНТЕР - технология достижений

Конференция «Корпоративные базы данных '2007»

Сергей Павлович Маркин

Презентация к докладу в формате PPT (4 780 Kb)

ЛИНТЕР – технология достижений

Начну с вопросов. Это хорошо. Они сразу определят канву выступления.

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

Итак, СУБД ЛИНТЕР.

Она какая?

Что собой представляет?

Почему она?

Что ей позволяет быть? Существовать? Развиваться?..

Это вопросы, которые можно поставить к любой из известных СУБД - брендов. Почему людям недостаточно оной системы во всех отраслях деятельности? Еще каких-то два десятка лет тому назад так и случилось бы.

«Спустили» бы сверху план использовать некую СУБД MSyOrix* как единственную во всех прикладных программах и АСУ ТП тогдашнего великого и могучего Союза.

Но теперь всё иначе. Всё богаче и разнообразнее. Всё стало особенным.

И люди начинают уже извлекать выгоду из таких особенностей. Хотя вполне достаточно и «попсы», этих «общих мест» и «общих слов».

На самом деле каждая система в своём развитии видоизменяется, принимая ту или иную только ей присущую форму (или всё же содержание?).

И здесь главное – это заказчики, которых устроила наша система, и не устроил этот гипотетический MSyOrix.

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

Давайте попытаемся очертить форму и содержание СУБД ЛИНТЕР, исходя из требований заказчиков этой системы.

Начнём, пожалуй, с наших зарубежных заказчиков.

Их пока не так много, но они есть, и это тем более характеризует нашу СУБД.

Brycen, Япония

Во многом благодаря сотрудничеству РЕЛЭКС с японской компанией Brycen (работы с компанией Brycen осуществлялись через компанию RelexUS), ЛИНТЕР был выбран одним из крупнейших производителей электроники Страны восходящего солнца.

Сами по себе задачи, для которых использован ЛИНТЕР, несложные, но имеют одну особенность: СУБД должна обслуживать бытовой музыкальный центр .

Требовался поиск и выбор мелодий, добавление/удаление, изменение их порядка и прочее.

Вся сложность состояла в том, что СУБД ЛИНТЕР и приложение должны были функционировать в «суровых» условиях ограниченной памяти, ограничений на внешнюю память, непредсказуемых сбоев
питания
и ограничений на время восстановления (Слайд №2).

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

Прежде всего, её пришлось сделать вариантной. Что это значит? Это значит, что из одних и тех же исходных текстов можно было сделать как мощный сервер, так и малюсенького карлика. Причём, как карлика по оперативной памяти, так и карлика по занимаемой внешней памяти.

Мы столкнулись с такими условиями, когда не было места для файла сортировки и оперативной памяти для мощного процесса сортировки.

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

Индексы также были ограничены. Остались только одиночные индексы, от составных индексов пришлось отказаться.

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

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

То, с чем мы столкнулись – устройство, владелец которого вовсе не должен знать (да и не знает), что там внутри и как оно там внутри устроено. Он должен иметь возможность «выдернуть вилку из розетки», нажать на кнопку «Power», поставить другую батарейку, и т.д., и т.п.

Нужно было предоставить абсолютную гарантию восстановления системы, а главное – всех данных после сбоя питания. Абсолютную. Как мы говорили между собой – «база данных должна стоять насмерть».

А, кроме того, восстановление системы не должно быть очень длительным, - не боле одной –
двух секунд
.

Было создано несколько тестов, имитирующих подобные условия. То есть случайные жесткие сбои во время работы приложения, перезапуск СУБД, тёплый рестарт, снова работа того же приложения, и снова жесткий сбой всей системы (Слайд №3)…

Это так называемый Killer . Этот тест замеряет устойчивость СУБД. В идеальном варианте любая промышленная СУБД должна выдержать бесконечное число таких циклов. Но идеал – это только наши желания или, если хотите, теоретическая модель.

На практике все оказывается не так гладко. Наша имярек, собирательный брэнд – СУБД MSyOrix
выдерживает такой напор сбоев в течение примерно 2 – 3-х суток. Дальнейшие циклы зачастую приводят базу данных в состояние, которое требует вмешательства человека.

То есть, база данных, в конце концов, восстанавливается, но для этого нужны специальные осмысленные действия по диагностике и лечению, без которых ядро MSyOrix на этой базе данных стартовать отказывается(!)

Такие тесты как Killer стали у нас измерителем надёжности. Думаю, подобные тесты есть у каждого производителя СУБД. Но так сложилось, что в открытых источниках информации даже об их существовании практически ничего нет. О стандартизации такого тестирования также речь не идет.

Изначально считается, что система должна быть 100%-но надёжной и измерять и сравнивать тут нечего. Но я хочу Вас заверить, что нет 100%-но надёжных систем . И есть смысл сравнивать
различные системы
не только по показателю скорости, но также и по таким показателям
(Слайд №4), как:

  • надёжность;
  • распараллеливаемость;
  • масштабируемость
  • и т.п.

Нужно признать, что наши японские заказчики заставили нас серьезно поднять планку надёжности. Ну и, кроме того, работая с японскими компаниями, мы серьёзно изменились сами. Эта работа заставила нас взглянуть на свои разработки под другим углом.

В итоге ЛИНТЕР приобрёл свойства отказоустойчивости, встраиваемости и вариантности , но, самое важное – мы приобрели огромный опыт разработки специализированных версий СУБД на технологической базе ЛИНТЕР, а также их сопровождения.

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

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

У нас получается так, что собственно сам продукт, с которым работает пользователь, очень похож на красивый ледяной айсберг. Однако 9/10 этого айсберга сокровенно, незаметно, скрыто от пользователя и находится где-то у разработчика, может быть, совсем на другой стороне света
(Слайд №5).

Министерство обороны

Теперь давайте попробуем взглянуть на то, как изменилась СУБД ЛИНТЕР благодаря одному из самых активных наших заказчиков – Министерству обороны Российской Федерации.

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

Как уже было не раз сказано, ЛИНТЕР сертифицирован на 2-й класс защиты от несанкционированного
доступа Федеральной службой по техническому и экспортному контролю
(ФСТЭК России).

Хочется остановиться на этом подробнее, т.к. большинству программистов это, к сожалению, ни о чём не говорит. Однако Президент и правительство проявляют к этим вопросам большое внимание, и ситуация понемногу меняется.

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

2-ой класс защиты – это почти вершина отечественного (да и международного тоже) стандарта защиты для информационных систем. До сих пор ни один из отечественных и зарубежных аналогов не смог достичь этой вершины для серийных СУБД.

И вся мощь популярной MSyOrix MSyOrix Trust) не позволяет ей занять место СУБД ЛИНТЕР, если речь идет о защите информации.

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

Здесь важна вариантность, то есть ведение/поддержка нескольких вариантов одной и той же системы одновременно.

Здесь важна доступность при сопровождении. Большая ответственность, ведь если пользователь настолько серьезно защищает данные, значит, эти данные для него исключительно важны.

Здесь важна предсказуемость развития продукта. Даже, может быть, и нечто большее – возможность влияния клиента на развитие продукта.

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

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

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

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

Это очень хорошо заметно как раз на примере наших «военных» заказчиков.

Ещё три года назад мы говорили об отсутствии культуры проектирования и кодирования при работе с секретностью. Клиента интересовало только то, что ЛИНТЕР обеспечивает защиту всего, что в него положили, а само управление защитой данных его практически не заботила.

Однако в последнее время положение изменилось. От пользователей стали поступать интересные вопросы уже не просто о существовании защиты, а о конкретных свойствах её. Например, такие:

  • как осуществить разное вИдение базы данных для различных категорий пользователей?
  • можно ли изменять параметры аудита в процессе работы?
  • собирается ли РЕЛЭКС развивать средства составления расписаний работы на рабочих станциях?
  • и т.п.

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

Проектировщиков сегодня интересуют вопросы создания вокруг информации не просто «высокого забора», а некоторой комплексной защитной среды. Мне даже пришлось ввести новый термин – aegisphera ** (агисфера) (Слайд №7). агисфера это все те защитные действия, программы, умные устройства, организационные мероприятия, и т.п.

Конечно, СУБД ЛИНТЕР не только становится частью агисфер ы базы данных, но также помогает создать эту самую защиту.

В этом комплексе защиты информации СУБД ЛИНТЕР становится не просто частью агисферы, но ее ядром, вокруг которого и на основе которого строится весь комплекс защиты информации.

Например, та же самая криптография. Теперь и это определяет форму и содержание СУБД ЛИНТЕР. Мы можем создавать шифрованную базу данных с использованием одного из 3-х алгоритмов –

  • ГОСТ;
  • AES (Advanced Encryption Standard);
  • DES (Data Encryption Standard) .

После этого вся база и все её архивы будут шифрованы этим алгоритмом. К сожалению, пока (только пока) нет возможности изменить ключ шифрования. Пароль задается при запуске ядра или утилиты тестирования базы. Именно он и является ключом шифрации.

Уже сейчас есть варианты шифрования отдельных таблиц. Однако эти варианты должны пройти государственную сертификацию.

РОСАТОМ

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

  • высокий уровень защиты данных;
  • высокая надёжность;
  • ответственность при сопровождении;
  • предсказуемость (Слайд № 8).

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

Конечно этот отпечаток не такой заметный, как наши изменения для японских заказчиков, которые фактически получили специальную версию ЛИНТЕР.

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

ОАО "Сургутнефтегаз"

Речь идёт о нашем большом внедрении в автоматизации нефтедобывающих технологий. И этот знаковый заказчик также внес свой вклад в изменение облика СУБД ЛИНТЕР.

Заказчик искал СУБД для операционной системы QNX ***. Однако все наши замечательные СУБД-бренды (наш любимый MSyOrix) покинули эту нишу.

Но компания РЕЛЭКС осталась здесь.

Какая короткая фраза, но за ней годы напряженного сотрудничества с «Сургутнефтегаз».

Здесь (Слайд № 9)

  • новый протокол горячего резервирования для построения отказоустойчивых кластеров;
  • перенесена в QNX поддержка LJB ( Linter Journal Backup ); LJB позволяет осуществлять непрерывное копирование файлов системного журнала;
  • добавлены значения функции и предикаты для работы с неопределенными числами с плавающей точкой ( NaN-числа FLOAT и DOUBLE );
  • низкоприоритетное тестирование таблиц;
  • возможности распределения одного индекса в нескольких индексных файлах;
  • и т.п.

Как вы видите, очень многие изменения коснулись надежности и работы в реальном масштабе времени.

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

Да, собственно, и сама эта среда была выбрана отнюдь не случайно. Приложение, разрабатываемое для Сургута, это нормальное АСУ ТП. (Слайд №10)

Уже становится очевидным направление развития СУБД ЛИНТЕР – реальное время.

И ещё сверхсекретность.

И ещё сверхнадёжность.

Эти «три кита» ЛИНТЕР (Слайд №11) стали как бы сутью системы, её формой, её содержанием, т.е. тем, чем она выделяется среди реляционных СУБД аналогичного класса.

Не нужно искать на этом слайде «центрального кита» или какого-то особенного кита. Они все необыкновенно важны, и все они – плод нашего труда над решением конкретных проблем конкретных государственных или коммерческих фирм.

Наш девиз – «никогда не отворачиваться от проблемы».

Так несколько лет назад мы не отступили от проблемы СУБД реального времени, и теперь это приносит свои дивиденды.

ВНИИРА

ВНИИРА ОВД специализируется на разработке систем управления воздушным движением. Мы благодарны этому заказчику за терпеливую работу с нами.

ВНИИРА получил необходимый инструмент для решения задачи реального времени, мы получили работающую систему с новыми свойствами.

Так что же получили мы?

Тогда не очень много:

  • обработку запросов по приоритетам;
  • события;
  • асинхронность работы приложения и СУБД.

Но этого не было ни у кого. Ни у кого из полноценных реляционных систем. Разве что, где-то в узкоспециализированных системах. Думаю, этого и сейчас в полном объеме нет ни у кого.

Мы стремились сделать наш аппарат приоритетов как можно более гибким и универсальным.

Я намерено хочу остановиться на аппарате приоритетов и показать его значимость в приложениях реального времени (Слайд №12).

В этом аппарате есть практически всё от группы планирования с форой до r eal-time запросов, которые монопольно захватывают все ресурсы ядра системы, безжалостно оттесняя от них запросы с более низкими приоритетами (Слайд №13-14).

На каждом очередном кванте ядро СУБД ЛИНТЕР осуществляет выбор запроса (канала) для обработки. При этом действуют следующие общие правила:

  • для обработки всегда выбирается запрос с наивысшим (наибольшим) приоритетом ;
  • при обработке запроса в более приоритетной группе запросы во всех низкоприоритетных группах

При этом в ЛИНТЕР есть соответствующие SQL-запросы для изменения приоритета уже обрабатываемого запроса. Приоритет можно сделать нулевым, и тогда запрос на некоторое время уйдёт в паузу.

Но этот же приоритет можно повысить до предельного значения, и тогда запросу с этим приоритетом будут отданы все ресурсы, тогда как все другие запросы «уйдут в паузу».

Для предотвращения бесконтрольного эгоизма для какой-либо одной задачи, каждому пользователю администратор присваивает не только некий приоритет (Слайд №15), но также и границы, в которых пользователь может изменять приоритет своих запросов.

Как мы видим, в ЛИНТЕР получился достаточно стройный и законченный аппарат приоритетов. И впоследствии этот аппарат оказался востребован не только в задачах ВНИИРА.

Естественно, встают вопросы о конфликтах различного рода:

  • конфликты на доступ к данным;
  • конфликты уникальности.

К сожалению не все эти конфликты разрешаются в пользу более приоритетной транзакции.

Особенно это касается оптимистических транзакций ЛИНТЕР. Дело в том, что в ЛИНТЕР реализован протокол backward validation , или «обратной проверки».

По этому протоколу для завершающейся транзакции A производится проверка конфликтов только с транзакциями, которые к этому моменту нормально завершились.

Поэтому , несмотря на то, что наша транзакция A имеет более высокий приоритет, она всё равно откатится, если низкоприоритетный конкурент завершился быстрее.

По идее должно быть другое положение вещей, когда при завершении транзакции мы должны проверить – не конкурируем ли мы с более приоритетным приложением. Если такое более приоритетное приложение есть, то наша транзакция должна откатиться, пропустив вперёд более необходимый запрос.

Поэтому для реального времени более подойдёт протокол forward validation или «прямой
проверки
». По этому протоколу для завершающейся транзакции A производится проверка конфликтов только с теми транзакциями, которые к этому моменту ещё не завершились.

При этом у СУБД есть выбор, какую из транзакций откатить. Либо транзакцию A , либо всех её конкурентов. Здесь на выбор того, какие транзакции откатываются, вполне может повлиять приоритет – A откатывается, если ее приоритет ниже, чем у всех её конкурентов, в противном случае откатываются все (подчёркиваю, все!) конкуренты (Слайд №16).

При равных приоритетах на выбор может влиять время (или объём) работы транзакции и т.п.

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

Тем более, по общему мнению научного и практического мира, протокол прямой проверки более эффективен, а кроме того, реализован в подавляющем числе систем реального времени.

Теперь о событиях .

Ещё раз скажем, что они были разработаны для нашего заказчика ВНИИРА, который делал real-time систему управления самолётами для аэропортов. Сегодня эта система используется в Пулково, Хабаровском и Минском международном аэропортах.

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

Для иллюстрации представим себе нескольких диспетчеров аэропорта, ведущих один и тот же самолёт (Слайд №17).

Если первый из них изменил некие параметры самолёта, например, скорость, то второй диспетчер должен как-то узнать об этом. На слайде совсем не случайно самолёт расположен на пересечении двух секторов.

Самолёт передаётся как эстафетная палочка из зоны работы одного диспетчера в зону ответственности другого.

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

Конечно же, он может перезапрашивать эти данные с определённой частотой, скажем, раз в секунду, но это только нагрузит систему, увеличит трафик и т.п.

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

Как только кем-то будут изменены данные, возникнет установленное событие, и СУБД ЛИНТЕР пошлёт ответ всем задачам, которые запросили оповестить о нём.

Очень удобный аппарат, правда, он становится эффективен по-настоящему, только если в системе реализована настоящая асинхронность.

Действительно в идеале задача «знает», что ситуация, скорее всего штатная, что данные, скорее всего, не изменятся, поэтому, получив данные о самолёте, она сразу начинает их обрабатывать.

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

Таким образом, для работы в реальном масштабе времени необходимо не только изменить ядро, но также необходимо сделать CALL-интерфейс системы более гибким, включив туда возможности асинхронной работы.

И нужно признать, что все эти функции действительно реально используются на практике.

Однако пока все наши приложения реального времени сами отслеживают время исполнения поданных ими запросов.

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

Это, конечно, не есть полное решение проблемы. Было бы гораздо более интересным, если бы в ЛИНТЕР была возможна директивная установка срока выполнения запроса. Собственно, это и есть признак настоящей СУБД РВ.

Пока же, как это уже было сказано выше, эту функцию отслеживания обработки запроса взяли на себя приложения.

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

  • СУБД с жесткими директивными сроками (невыполнения в срок не может быть, это катастрофа!);
  • СУБД с крепкими директивными сроками (выход за рамки срока приводит к снятию запроса с исполнения – просто выкидывается из системы);
  • СУБД с мягкими директивными сроками («просроченный» запрос становится менее значимым, например, у него уменьшается приоритет) (Слайд №18).

Для тех, кто интересуется, – мы сталкивались с приложениями только третьего типа, т.е. с приложениями, которым требуется СУБД с мягкими директивными сроками.

Ну и ещё с неким промежуточным звеном – можно было использовать условно мягкие директивные
сроки
. При этом если обработка запроса просрочена, запрос делается менее значимым, но СУБД при необходимости (пик нагрузки, большая очередь запросов и т.п.) может и снять его с выполнения.

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

Хороший пример – локатор. Он вращается (покачивается). На каждом повороте в базу посылается информация. Но пропуск нескольких таких добавлений – не есть большая неприятность, т.к. их можно будет достроить (аппроксимировать), исходя из уже существующих данных.

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

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

Собственно, никакого секрета тут нет, а есть нормальные и достаточно оправданные требования, которые и обсудим.

Во-первых , интересны требования к этапу загрузки базы данных. Зачастую в базах данных
приложений реального времени имеется до 90% статичных данных
. Такие данные, как расположение взлетно-посадочных полос, запасных аэродромов, карты местности и т.д. – меняются достаточно редко.

Работа по загрузке (Слайд №19) такой статической информации не имеет никакого отношения к тому, что называется реальным масштабом времени.

Так что эту работу можно считать неограниченной по времени (по сравнению с работой СУБД при обслуживании приложения).

На этом этапе можно и нужно максимально оптимально расположить данные, сделав доступ к ним наиболее эффективным – сделать более плотными (а значит более «низкими») деревья (B -деревья, R -деревья и т.п.). Это уменьшит операции ввода-вывода и ускорит доступ.

На этом этапе можно и нужно посчитать некие «полуфабрикатные» данные, которые чаще всего могут потребоваться, например: некие частичные суммы и даже целые линии расчетов по наиболее вероятным направлениям.

На этом этапе можно и нужно отсортировать информацию в соответствии с индексом ее потребности. Всё должно быть ориентировано на то, чтобы как можно быстрее получать ответы с высоким уровнем потребности.

По возможности, объединить в кластеры данные, которые при запросах приложения будут соединяться друг с другом и т.п.

По возможности, получить некоторое множество временных (может быть, и некоторых других) оценок по обработке запросов к статичным данным и т.п.

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

Но понятно, что от качества заготовки зависит успех всей задачи уже на этапе её реальной работы.

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

Однако у этих двух систем (у СУБД этапа загрузки и СУБД времени выполнения) общая база данных и совместимые методы доступа, некоторые оценочные функции и т.п.

Речь идёт о том, что обе эти СУБД должны быть вариантами одной системы. То есть такая система должна развиваться как единое целое, но из этого целого можно получить различные стороны одной медали – СУБД для загрузки/подготовки и ru n ?time СУБД.

В-третьих , ещё одно очевидное замечание. Ошибки приложения реального времени очень дороги и очень болезненны. Это естественно. Иначе не было бы и речи о реальном масштабе времени.

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

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

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

Это всё к тому, что в подобных задачах СУБД (Слайд №20) реального времени должна быть максимально масштабируемой, должна иметь в себе потенциал для использования десятков,
а иногда и сотен процессоров
.

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

Такой системе нужно уметь вовремя диагностировать отказы оборудования и изолировать это отказавшее оборудование.

Уменьшение количества процессоров или их добавление не должны останавливать систему, и в частности – СУБД.

Здесь важная способность СУБД РВ – адаптивность. Адаптивность, как говорится, «на лету».

Балансировка нагрузки – ещё одна важная способность СУБД РВ. Нельзя допускать простаивания вычислительных ресурсов, если другие напряженно работают.

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

Наверное, научные разработки «ушли», скорее всего, на национальный или корпоративный уровень без активного выхода в мировое internet-сообщество.

Поэтому зачастую все наши инновации – следствие плотной работы с нашими заказчиками. Именно они определяют многие свойства и особенности нашей СУБД ЛИНТЕР.

Нас очень радует, что в последнее время заказчиков в этой области становится больше.

Массовое использование дешевой flash-памяти ставит перед СУБД ещё и задачу минимизации
операций вывода
.

В последнее время всё более и более сближаются задачи реального времени и задачи,
включающие пространственные данные
, как-то: ГИСы, трехмерные задачи, задачи на трехмерных поверхностях, и т.п. (Слайд №21)

Конечно же, это в первую очередь относится к системам типа ГЛОНАСС, системам ориентации спутников, задачам аналитики и поиска на поверхности Земли, как на геоиде/эллипсоиде. Здесь характерны быстрые переходы от плоских координат к эллиптическим и обратно.

Компания РЕЛЭКС ведёт работы над новыми технологиями индексирования и быстрой обработки
пространственных данных на трёхмерных поверхностях первого и второго порядков
.

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

Мы рады такому положению вещей.

Эта тема нас интересует как с профессиональной, так и с коммерческой точки зрения. А, кроме того, это радует нас ещё и тем, что мы работаем на благо нашей Родины.

* Некое сокращение от известных брендов СУБД

**Aegisphere – здесь два латинских слова aegis – эгида, щит или панцирь Юпитера и Миневры; защита, покров, прикрытие … а еще слово sphere – сфера

***QNX Real-Time Platform v.6.2.1


Возврат к списку

ѕрокрутить вверх