=Paper=
{{Paper
|id=None
|storemode=property
|title=На пути к новой теории информационных систем
(On the way to new information systems theory)
|pdfUrl=https://ceur-ws.org/Vol-934/paper41.pdf
|volume=Vol-934
|dblpUrl=https://dblp.org/rec/conf/rcdl/Znamenskij12
}}
==На пути к новой теории информационных систем
(On the way to new information systems theory)
==
https://ceur-ws.org/Vol-934/paper41.pdf
На пути к новой теории информационных систем
○
c С. В. Знаменский
Институт программных систем имени А.К. Айламазяна РАН
Переславль-Залесский
svz@latex.pereslavl.ru
Аннотация Длительно существующая компьютерная си-
стема сталкивается с новыми видами или
Эволюционирующая информационная си- разновидностями опаснейших угроз, которые не
стема, способная адаптироваться к изме- были предусмотрены при её создании. Нереально
няющимся требованиям и противостоять в деталях предусмотреть все возможные угрозы:
непредвиденным угрозам, должна соче- хакерское вторжение, диверсию или террори-
тать высокие корректность и быстроту стический акт, грубую критическую ошибку
реакции даже при структурных пере- персонала, смену технических политик, сдвиг
стройках, задержках и временных потерях потребностей пользователей, смену ориентиров
связи. Известная теорема CAP Брювера руководства, стихийное бедствие, технократиче-
отрицает возможность построения таких скую катастрофу, всплеск популярности.
систем. Технологии защиты информации и преду-
Новые основания теории информа- преждения угроз здесь не обсуждаются. Речь
ционных систем позволяют построить идёт исключительно о способности программного
содержательный контрпример к теореме обеспечения компьютерной системы обеспечить
CAP Брювера. Для модельной зада- службе сопровождения возможности исследовать
чи приведённое построение теоретически происходящее, встраивать защитные механизмы,
доказывает возможность практической устранять последствия поломок, по необходи-
реализации информационной системы с мости восстанавливать разрушенное, добавлять
расчётными показатели качества в сто непредусмотренную функциональность и расши-
и более раз лучшими, чем у лю- рять востребованные сервисы.
бой возможной реализации стандартными Служба сопровождения здесь понимается в
методами. общем смысле, от системных сервисов мони-
Приводится грубый набросок архитек- торинга и самовосстановления до технических
туры информационной системы общего администраторов и разработчиков разного уров-
назначения с неограниченно изменяемы- ня.
ми функциональностью концептуальной Похожие свойства являются объектом широ-
моделью и физической реализацией. кого фронта исследований (см., например, [2, 3]),
оставляющих комплексную реализацию на
крайне отдалённую перспективу.
Введение Принципиальным препятствием к построению
устойчивой отзывчивой системы видится теорема
«Dubito ergo cogito, cogito ergo sum» CAP Брювeра [4], утверждающая невозможность
Рене Декарт сочетания трёх свойств:
Примерами систем, ориентированных на дли- Consistency (Согласованность — ответы на
тельное существование, являются интернет в запросы к системе логически непротиво-
целом, социальные сети, Google Scholar, Вики- речивы).
педия, Sourceforge, инфраструктура разработки Availability (Доступность — ответ на любой
ядра ОС Linux и её дистрибутивов и многие запрос может быть получен незамедли-
другие. Ориентация на длительное существова- тельно).
ние приобретает растущую популярность (см.,
Partition-tolerance (Устойчивость к разделе-
например, [1])
нию — при восстановлении потерянной
Труды 14-й Всероссийской научной конференции
на время связи функциональность и внут-
«Электронные библиотеки: перспективные методы и ренняя целостность восстанавливаются).
технологии, электронные коллекции» — RCDL-2012,
Переславль-Залесский, Россия, 15-18 октября 2012 г. Не секрет [5], что формулировка теоремы CAP
провоцирует на сомнительные популяризации.
265
Формальное доказательство этой теоремы в [6] истинности формулы.. Одновременно профессор
основано на прозрачной идее: В так же поступает с другим местом той же
формулы. Оба считают ошибку исправленной,
(︁ появление )︁ (︁ их )︁ (︁ противо- )︁
& ⇒ обе части формулы изменены, . . . — но формула
различий доступность речие!!!
вновь неверна!
Практику очевидно, что после обрыва связи
Рассмотренные примеры показывают, что
с филиалом компании работа должна быть
даже безупречно формально обоснованно инфор-
продолжена с адекватными ситуации ограниче-
мационные технологии не позволяют избежать
ниями и после восстановления связи система
конфликтов доступа. Такие конфликты приводит
должна полностью восстановиться без потерь
к иногда невосполнимым потерям пользователь-
информации, то есть логика доказательства
ских данных.
противоречит потребностям практики.
Этим конфликт напоминает дуэль.
Неприемлемость строго доказанного резуль-
тата в науке встречается. Достаточно вспомнить
классические безупречные доказательства невоз- 1.1.1 Принцип Байрона-Галуа
можности рационального корня из числа 2,
Дуэли категорически недопустимы.
корней из отрицательных чисел и недифферен-
цируемости функции Хевисайда. Их неприем- Побочным эффектом дуэлей стали невосполни-
лемость привела в своё время к развитию и мые для человечества потери.
широкому применению новых теорий, ставших Не улей и не муравейник должны стать
основой современной математики — теории ве- образцом адаптивной системы, поскольку чело-
щественного числа, теории комплексных чисел и веческий опыт организации общества обеспечил
теории обобщённых функций. более чем тысячекратное ускорение эволюции по
сравнению с биологической.
1 Адекватное разделение ИС Сложившиеся нормы и принципы организа-
ции цивилизованного общества нуждаются в
Начнём с простейшей ситуации, в которой все переосмыслении применительно к эволюциони-
отмеченные качества критичны — с организации рующим компьютерным системам.
совместного доступа к редактированию файла. Для конфликтов это может быть сделано так:
1. Логически обоснованные алгоритмы разре-
1.1 Неизбежность противоречий шения конфликтов должны использовать-
Классические блокировки доступа к файлу ощу- ся везде, где они корректно применимы.
тимо задерживают работу и делают документ 2. Конфликт не нашедший конструктивного
недоступным при поломке или потере связи. По- решения, должен разрешаться на более
пытки этого избежать (например, предоставление высоком уровне организации.
пользователю возможности снимать блокировку 3. Вердикт должен быть вынесен на ос-
другого пользователя) создают реальную угрозу нове рассмотрения всех обстоятельств
потери введённых данных. и может предусматривать предупреди-
Выход казалось бы найден в декомпозиции тельные меры — поиск или разработку
редактирования документа на коммутирующие подходящего конструктивного решения.
изменения (OT-operational transformations). Это
дало эффектную иллюзию одновременной ра- 4. Если вердикт не разрешает конфликт
боты и стало общепринятым [7] современным содержательно, то правило действует
средством организации совместной деятельности. рекурсивно до высшего уровня управления.
Однако такое редактирование исходного кода 5. Сопутствующая информация обязатель-
программы двумя пользователями затрудняет но должна сохраняться для будущих
работу и повышает риск ошибки [8]. Например, рассмотрений.
пока открывающая скобка одним пользователем
уже набрана, а закрывающая ещё нет, второй Для информационных систем это означает
лишён возможности тестировать код и подсветка особую заботу о сохранности всех входных
синтаксиса у него испорчена. данных и корректности их обработки, стара-
Есть и другая опасность: тельное исключение любых возможностей отката
транзакций.
Пример: Вычитывая совместную статью на В ситуации совместно редактируемого файла
удалённом сервере, профессора А и В замечают отсюда вытекает важность сохранения документа
ошибку в ключевой математической формуле. таким, каким его видел пользователь и всей
Профессор А исправляет формулу и закрывает сопутствующей информации для возможного
окно с чувством полной уверенности в
266
пересмотра принятого решения и использованной подтверждается общепринятостью доказанности
логики. теоремы CAP.
Взяв на заметку, что доступность пол- Рассмотрим возможность и целесообразность
ной неподдельной истории происходившего су- построения системы, сочетающей ретроспектив-
щественно помогает правильному разрешению ность с адекватностью — безупречностью
конфликтов, вернёмся к разделению информаци- реакции на запросы и соразмерностью послед-
онной системы на части 𝐴 и 𝐵 . ствий временных поломок и сбоев.
Под устойчивостью информационной системы
к разделению на части будем понимать сле- 1.2 Пробная задача
дующее: Части 𝐴 и 𝐵 изменяются и связаны
с потерями и задержками. Тогда о текущем Банк имеет тысячу клиентов в двух городах 𝐴
значении данного, доступного из частей 𝐴 и и 𝐵 . Расчётное максимальное время задержки
𝐵 говорить бессмысленно. Что действительно передачи данных между городами 𝑇 = 0.25
можно требовать от функционирующей при секунды.
непредсказуемых задержках информационной си- Города расположены так, что устранить эту
стемы, так это определить последние моменты задержки технически невозможно1
прошлого, на который в системе в целом или Для поддержки переводов денег со счёта
локально было установлено последнее корректно на счёт банк нуждается в качественной
обоснованное значение этого данного и выдать информационной системе с по возможности
эти значения и моменты. быстрым временем отклика 𝜏 , рассчитанную на
Использование старых данных опасно не обработку не более десяти запросов в секунду с
потерей актуальности. В самом деле: если одновременной поддержкой ста сессий:
система работает быстро, то разница во времени
ничтожна, а если время обработки значительно, 1. Результаты любых запросов гарантированно
то пока ответ по данным на момент запроса должны быть корректны и согласованы.
будет получен, момент запроса устареет на такое 2. При любом обращении к сервису задержка
же время обработки. обработки не должна превосходить 𝜏 для
Опасность в том, что обрабатывать старые любого из следующих запросов:
данные можно лишь по их состоянию на (a) Просмотр состояния счёта и истории
фиксированный момент времени. Изменившееся его изменений.
значение противоречит прежнему.
Мы приходим к требованию ретроспектив- (b) Перевод имеющейся суммы на другой
ной согласованности данных информационной счёт.
системы: (c) Получение отчётов.
∙ В любой момент времени 𝑡 в системе Для предельного упрощения задачи полагаем,
доступен прошедший момент истины что банк с наличностью не работает, кредито-
𝜇(𝑡) < 𝑡, которым завершилась доступная ванием не занимается, вне городов никого не
история согласованных изменений данных обслуживает, пользователи заведены с неизмен-
системы. ными личными данными и для простоты не
переезжают, а потерями и задержками внутри
∙ Для любого предыдущего момента 𝜏 < 𝜇(𝑡)
городов можно пренебречь.
система возвращает согласованные реплики.
Разность 𝑡 − 𝜇(𝑡) назовём длительностью 1.3 Последовательный подход
согласования. При удачном разделении дли-
тельность согласования для части системы Информация о текущем состоянии каждого счёта
оказывается меньше, чем для целой системы. должна где-то храниться. Запрос о переводе на
Ретроспективная информационная система этот счёт из другого города, должен дойти и
может не всегда иметь единую концептуаль- после этого ответ должен вернуться обратно,
ную модель. Более того, её концептуальная чтобы пользователь смог знать, что запрос
модель может изменяться не мгновенно и принят. Поэтому реакция системы не может
не одновременно во всех частях. Этим она быть гарантирована быстрее, чем в течение
принципиально отличается от последователь- 𝜏 = 2𝑇 = 0.5 секунды.
ных информационных систем, основанных на
1 При передаче со скоростью света через геостационарный
моделировании последовательности изменений
спутник сигнал задерживается на 1/4 секунды. При недо-
глобального согласованного состояния системы. ступности геостационарного решения неизбежны задержки
Практически все существующие информаци- при переключениях на очередной спутник.
онные системы последовательные. Это косвенно
267
1.4 Ретроспективный подход и сравнение ожидающее изменения состояния счёта для по-
вторения запроса, отвергнутого из-за недостатка
В мегаполисах размещаются идентичные серверы. денег на счету.
Каждый из них ведёт счета пользователей из Разумеется, при переводе денег упомянутая
своего мегаполиса. секунда задержки не составляет проблемы для
Сервер отказывается выполнить перевод если клиента. Сюжет задачи выбран для ясности
денег на счету отправителя недостаточно. Если рассмотрения, а ничем не компенсированные
на счету достаточно денег, то сервер немедленно задержки в других ситуациях могут быть
изменяет состояние локальных счетов и надёжно критическими.
запоминает своё обязательство по возможности
быстро выполнить перевод.
После обработки серии запросов (например 1.4.2 Точность и логичность
каждые пол-секунды) серверы передают друг В конкретной задаче общая сумма денег на
другу полные списки накопившихся запросов счетах в реальности не константа. Ясно и при-
и записей изменений в счетах и извещения вычно, что отправленные с одного счёта деньги
о получении списков. Извещение о получении поступают на другой не мгновенно. Стандартная
посылается только в том случае, когда пакет реализация на основе транзакций прячет время
получен полностью и содержит момент времени, транзакции в неповоротливость пользовательско-
вплоть до которого все данные получены. Па- го интерфейса, искусственно создавая иллюзию
кетная передача помогает гарантировать единый мгновенности сделки.
порядок и отсутствие пропусков в общей части Ретроспективное решение делает находящи-
информации серверов и корректно снизу оценить еся в пути деньги доступными для точного
момент истины системы 𝜇(𝑡), вся история из- последующего анализа.
менений вплоть до которого получена на обоих История изменений счёта, полученная поль-
серверах. зователем, полна до момента 𝜇(𝑡), а после 𝜇(𝑡)
Пользователь получает ответ на свой запрос в ней могут временно отсутствовать деньги,
с учётом реакции только ближайшего сервера. «находящиеся в пути».
Реакция удалённого (например, уведомление о Запросы сводной информации на момент,
получении перевода в другой город) может предшествующий 𝜇(𝑡), не зависят от сервера.
быть учтена в отдельном последующем через Для запроса сводных данных на последний
секунду запросе (который может делаться момент у пользователя есть две возможности:
автоматически либо клиентским приложением
либо на основе технологии comet, позволяющей 1. посмотреть сводную по всем доступным
локальному серверу самостоятельно передать (неполным) данным с предупреждением о
такое уведомление в момент получения). неполноте,
2. посмотреть полную сводную по всем
1.4.1 Скорость и пользовательский интер- данным на последний момент 𝜇(𝑡), для
фейс которого они доступны.
Условия задачи не влекут никаких технических Если запросы следуют не чаще, чем может
препятствий к получению быстрого (в течение обработать традиционная система, то выдаётся
десяти миллисекунд) ответа на запрос на основе в точности тот ответ, каким он был бы в
имеющейся на ближайшем сервере информации. традиционной системе на запрос, посланный
Повышение реактивности системы в сто раз из оптимально выбранного момента прошлого
здесь достигнуто по сути включением в (неважно, был ли такой запрос в действительно-
реакцию системы на запрос пользователя только сти).
немедленно доступной информации.
Это позволяет обеспечить пользователя удоб-
1.4.3 Устойчивость к катастрофам и потерям
ным интерфейсом, дающим возможность выбора,
связи
наблюдать за процессом обработки, любо спо-
койно выключить клиентское приложение либо Поломка связи между городами при стандартном
заняться операциями с другими счетами. подходе полностью блокирует операции в одном
Взаимодействие с внешней системой может из них. При ретроспективном блокируются лишь
породить сложную совместную транзакцию (на- операции, непосредственно нуждающиеся в этой
пример, перевод с одного счёта на другой связи, остальное продолжает работать и сервис
в другой город, оттуда на третий и снова немедленно полностью восстанавливается при
назад) и потери времени станут неизбежны. восстановлении связи.
Для клиента, ожидающего поступлений на счёт, Кроме упомянутых, ретроспективная органи-
может быть создано клиентское приложение, зация имеет и другие полезные особенности:
268
Поломка или неожиданная потеря одного 2 Ретроспективная парадигма про-
сервера базы данных (попадание метеорита) граммной инженерии
при стандартном подходе должно быть заранее
предупреждено специальными мерами, например, Проектирование системной архитектуры предпо-
чёткой организацией резервного копирования или лагает разделение системы на наиболее крупные
репликации базы. Иначе потери могут оказаться составные части и принятие конструктивных
фатальны. решений, которые после их принятия с трудом
При ретроспективном подходе без каких- поддаются изменению.
либо дополнительных мер исчезновение сервера В рассматриваемой общей постановке неогра-
приводит к потере лишь части обновлений за ниченно изменяются концептуальная модель,
последние доли секунды, что оставляет шансы используемое оборудование и приложения (сер-
на спасение. висы). Поэтому они не могут быть общей
основой системной архитектуры для ретроспек-
1.5 Результат тивной системы. Такой основой может быть
только стабильная подсистема идентификации
Теорема. Существует возможность реализации структур процессов и данных, обеспечивающая
прикладной информационной системы с ре- безусловную доступность неподдельной истории
троспективным доступом, вполне адекватной при произвольных изменениях.
функциональностью при разделении, быстрым Прежде, чем её описывать, следует разобрать-
автоматическим восстановлением после вос- ся с понятиями модульности и информационных
становления связи и с временем отклика в объектов, которые в системе с историей и
сто раз ниже, чем у любой реализации на изменчивостью имеют свои особенности.
традиционной основе.
Эта теорема разумеется противоречит не
2.1 Модульность
самой теореме CAP, а её популярным интерпре-
тациям. Модульность освобождает разработчиков при-
Рассмотренный пример вырос из неодно- кладных программ от сложностей организации
кратно обсуждавшихся на конференции [9–11] исполнения. Она традиционно понимается как
ретроспективных систем. Он ставит ряд вопро- разделение на изолированные модули со своими
сов: кодом и данными, обменивающиеся сообщения-
ми. Рассмотрим, как такое понимание может при
1. Ведёт ли он к общей технологии разработки структурных изменениях приводить к неконтро-
ретроспективных информационных систем? лируемому росту сложности организации обмена
2. Не чрезмерны ли требования ретроспек- сообщений.
тивной парадигмы к объёмам памяти и Сложность эта порождается двумя принци-
вычислительных ресурсов? пиальными дефектами неуправляемого обмена
сообщениями:
3. Сможет ли ретроспективная технология
кардинально упростить исправление кон- 1. Новому исполнителю недоступна инфор-
цептуальных ошибок и создание эволюцио- мация, разосланная участникам совместно
нирующих систем? выполняющейся работы.
4. Сможет ли ретроспективная технология 2. Сообщения теряются по разным причинам.
резко уменьшить потери и неудобства
3. Сообщение читается с неизвестным запоз-
пользователей, связанные с обновлением
данием, за это время оно может потерять
систем?
адекватность, а отменить непрочитанное
5. Сможет ли положительный эффект ре- сообщение автор не может.
троспективного подхода проявиться при
организации многопроцессорных распреде- Отсюда опасность использования изоляции
лённых систем и высокопроизводительных модулей с организацией обмена сообщениями в
вычислений с большими гранулами парал- коллаборативном приложении: после успешного
лелизма либо с задержками переконфигу- тестирования малейшее изменение структуры
рирования FPGA [12]? взаимодействия или возникновение задержек
может неожиданно выявить необходимость кор-
Возникшие вопросы ждут комплексной фун- ректирующих сообщений. В итоге безупречная
даментальной проработки. Здесь мы затронем работа обеспечивается лишь до замены модулей,
лишь ключевые аспекты первых двух из них. и откатов неправильных действий, а запуск
новых исполнителей на замененном оборудова-
нии и (или) с новыми алгоритмами исполнения
требует серьёзного рефакторинга системы.
269
Альтернативой обмена сообщениями является изменениями. Используется идея процессного
публикация данных с подпиской на изменения, подхода, рекомендованного стандартами ИСО
и, в частности, стандартное решение DDS (Data серии 9000. Однако вместо термина процесс
Distribution Service) [13]. мы будем использовать более общий термин
Механизм обработки запросов на подписку активность, не предполагающий обязательности
и на публикацию авторы не регламентиру- входных данных и не ассоциирующийся с про-
ют. Во избежание коллизий запросы вероятно цессами операционной системы. Так, множество
должны обрабатываются строго, то есть про- всех ИСО9000-процессов является подмноже-
ходить через общий вычислительный узел, что ством всех активностей системы.
принципиально ограничивает масштабируемость Другие примеры активностей:
(см., например, [14]). В любом случае это
не снижает ценности DDS как перспективного ∙ нажатие пользователем кнопки, переход по
новейшего технического решения для общей ссылке или ввод текста;
памяти распределённой системы, которое по- ∙ обнаружение события, нуждающегося в
видимому может эффективно масштабироваться обработке.
при устойчивых структурах данных с достаточно
∙ обработка данных, полученных от разных
редко меняющимися настройками.
пользователей, при совместном редактиро-
Подписка производится с настройками, уста-
вании.
навливающими количество хранимых версий,
время жизни данных, количество реплициру- Мониторинг сложных активностей осуществ-
емых копий, планово допустимые задержки, ляют активности управления качеством, в част-
учитывающими период изменения данных и ности корректирующие взаимных приоритетов
приоритетность передачи. DDS ничем не огра- дочерних активностей.
ничивает свободы программиста по выбору этих Системная активность управляет качеством
настроек. системы в целом через такие дочерние ак-
Получая полный доступ к гибкому распре- тивности, заведомо неполный список которых
делению вычислительных ресурсов, прикладной включает:
программист к сожалению практически лишён
разумных ориентиров. Это создаёт сложнейшую ∙ мониторинг наличия и состояния физиче-
проблему избыточной гибкости настроек, кото- ских устройств и каналов связи;
рые для долгоживущей системы должны быть ∙ мониторинг информационного обмена меж-
ещё и динамически управляемыми. ду активностями и между физическими
Решение этой проблемы требует систем- узлами и перемещение активностей.
ной организации для гибкого регулирования
минимальным количеством прозрачных настроек. ∙ мониторинг взаимных приоритетов актив-
Построив дерево всех объектов, настройки ностей с общим родителем;
будем считать вектор-функцией от узла. Если ∙ мониторинг качества обновления информа-
предположить, что настройки чаще должны ции;
совпадать для смежных узлов, то задание на- ∙ документирование кода и данных системы;
строек сводится к разрезанию дерева и заданию
настроек для каждой связной части. Поскольку ∙ уточнение приоритетов информационного
каждая связная часть имеет ближайший к корню обслуживания активностей;
элемент, то именно в нём можно задавать или Большинство задач системной активности в
менять настройки. Тогда настройки, сделанные начальной фазе существования системы может
в любом узле, наследуются во всей ветке, за осуществляться человеком, а затем переводиться
исключением подветок со своими настройками. на автоматическое управление. Автоматизация
Это означает, что проблема настроек разделяе- управления требует постановок задач поиска эф-
мой памяти сводится к разумному представлению фективных алгоритмов. Эти алгоритмы должны
всех данных системы в виде дерева объектов. будут разумным образом перестраивать разме-
Примерами таких веток в рассмотренном щения активностей по физическим устройствам
примере являются данные о изменениях в счёте и оптимизировать коммуникации, используя в
отдельного пользователя и данные по городу. качестве входных данных изменения физической
В общем случае такое разделение означает конфигурации системы, изменения приоритетов
иерархию управления изменениями в системе. и статистику мониторинга активностей.
2.2 Контекстная автономная архитектура
Архитектура контекстно-автономной системы [9]
формируется на основе иерархии управления
270
2.2.1 Логическая идентификация данных 2.3 Организация исполнения
Элемент данных (например, атрибут объекта) Иерархия контекстов активностей упрощает
может сохраняться и реплицироваться в разных проблему регулирования разделения ресурсов.
узлах системы. Изменение данного создаёт его Приоритеты допустимости задержек, уровня
новую версию. Прежде чем идентифицировать защищённости и ценности истории устанав-
версии в различных местах системы, мы долж- ливаются (и могут в любой момент быть
ны идентифицировать то, версии чего в ней пересмотрены) для общих активностей верхнего
сохраняются. Идентификатор самого элемента уровня.
(например, поле конкретной формы, заполненное
конкретным пользователем, содержащее код ис- 1. Состояние изменяющегося объекта одно-
полняемого в системе скрипта), не учитывающий значно определено лишь в достаточно
версии и места хранения, будем называть ло- давнем прошлом.
гическим идентификатором элемента данных. 2. Безупречный ответ может быть дан лишь
Прозрачность идентификации данных крайне на запросы об устоявшемся (линейно
важна для доработок системы. упорядоченном) прошлом, предшествую-
Для каждой активности 𝐴 определим её щим моменту истины множества данных,
контекст 𝒟(𝐴) = [𝑑0 (𝐴), 𝑑1 (𝐴)] ⊂ 𝑈 как сегмент нужных доля обработки запроса.
в линейно упорядоченном универсуме 𝑈 всех
возможных логических идентификаторов данных 3. Момент истины (ранее которого прошлое
[15]. устоялось) быстро определяется по времени
Универсум 𝑈 будем считать неисчерпаемым и идентификатору.
в следующем смысле: 4. Обновление информации в автономном кон-
тексте данных происходит с ограниченной
∀𝑥, 𝑦 ∈ 𝑈 ∃𝑧 ∈ 𝑈 : 𝑥 < 𝑧 < 𝑦 частотой при появлении изменений, необ-
работанных на момент, когда все входные
Неисчерпаемость обеспечивает возможность раз- данные устоялись.
мещения в любом контексте множества данных
любой конечной мощности. Например, универсум 5. Изменения помечаются комбинированным
строк символов неограниченной длины с от- временем обработки, интерпретируемым и
ношением лексикографической упорядоченности как частично упорядоченное логическое
неисчерпаем. (линейно упорядоченное до момента исти-
Для вложенных контекстов активность с ны), и как приближение к физическому
более широким контекстом будем называть времени.
родительской, а с более узким — дочерней.
Ограниченность частоты изменений обеспе-
Принцип разделения ответственности и прин-
чивает локализацию последствий ошибок и
цип Байрона-Галуа приводят к следующим
открывает возможность оперативного автомати-
требованиям:
ческого выявления проявившихся в работающей
1. Контексты любых двух активностей либо системе противоречий. Локализация последствий
вложены, либо не пересекаются. ошибок вместе с автоматической диагностикой
особенно важна для ретроспективной системы,
2. Активность с более широким контекстом поскольку перестройку «на ходу» невозможно
не модифицирует контексты дочерних осуществить без временных рассогласований и
активностей. исправляемых ошибок.
3. Перемещение активности в новую область Поясним сказанное.
резервирует старый контекст для воз-
Пример: один процесс обеспечивает 𝑎 = −𝑏,
можного возврата и изоморфно переносит
а другой — 𝑏 = 𝑎 + 1.
все дочерние активности.
Подобное нарушение логики, проскользнув-
Добавляя совокупную активность, поддер- шее в обычную работающую систему, либо
жанную системой, получаем в каждый момент останется незамеченным, либо заставит систему
времени дерево активностей. Оно изменяется бесконечно пересчитывать 𝑎 и 𝑏.
— активности появляются, замирают, глубина Фиксация частоты изменений ограничивает
вложенности активности может изменяться. Это любые негативные эффекты, в том числе и этот.
обеспечивает произвольные структурные пере- При появлении нескольких кандидатов для
стройки и гарантирует доступ к неискажённому значения в близком времени возникает конфликт,
прошлому. требующий разрешения. Иногда для разрешения
271
могут использоваться либо выбор значения, по- среднем пять раз (редкие 100, многие 1),
ступившего последним, либо выбор наибольшего а средний размер элемента превышает длину
(рекордного) из поступивших значений. штампа времени и текущий размер информации
Остальные значения игнорируются или уда- сайта 100 Mb.
ляются при записи. Если конфликты сложнее, то
Общий объём всех версий исходных файлов,
могут вводиться дополнительные активности для
помеченных моментом сохранения, составляет
разных источников значений с целью разрешения
конфликтов. (100 + 100) × 5 = 1000 Mb.
Если, например, от пользователя поступает
более десяти форм в секунду, то это возмож- Объём выданных пользователям веб-страни-
ная попытка взлома. Классическое эффективное чек, которые получаются разными сочетаниями
средство борьбы — это игнорирование промежу- исходных файлов и шаблонов, может на порядки
точных запросов от одного пользователя в малом превосходить эту цифру.
промежутке времени. При этом запросы от всех Для быстрого доступа к любой страничке
разных пользователей должны быть сохранены и из прошлого нужно лишь добыть актуальное
корректно обработаны. на этот момент сочетание файлов и шаблонов,
Уменьшение частоты изменений контекстов что несложно организовать с логарифмически
ресурсозатратных активностей, таких как про- растущими с объёмом издержками [10]. Много
филя пользователя или объёмная статистика, резервных копий системы не потребуется,
экономит ресурсы. поскольку вся история остаётся нетронутой и
сможет пропасть только вместе с используемыми
2.4 Экономия памяти данными.
Пример показывает возможность хранения
История изменений необходима высоко доступной полной истории изменений при
∙ для эффективного согласования распреде- вполне умеренном росте ресурсозатрат.
лённых данных, Даже для сложных систем может оказаться
достаточно обеспечить прозрачную логику сборки
∙ для быстрого восстановления при поломках, и сохранять только версии исходной информации
∙ для ускорения отладки нового кода, и результаты недетерминированных процедур.
∙ для упрощения расследования вторжений и Если ненужные версии данных занимают
других происшествий, слишком много места, часть давно неактуальной
информации может автоматически удалять-
∙ для повышения ответственности персонала. ся [15], создавая белые пятна истории на оси
Последние две цели требуют гарантий непод- времени — промежутки, состоящие из моментов
дельности истории. Эти гарантии нуждаются времени, информация на которые недоступна.
нуждаются в комплексной поддержки истории Этот процесс мог бы проводиться автоматически
изменений на более низком уровне, чем механиз- субоптимально [16], оставляя относительный
мы разрешение конфликтов доступа и механизмы размер каждого белого пятна близким к мини-
обеспечения прикладной функциональности. мально возможному при заданном ограничении
Доступ к физическим ресурсам (процессоры, общего объёма хранилища.
память) обеспечивается ретроспективной СУБД
[11], задачей которой является сохранение Выводы
истории изменений объектов (в частности
исполняемого кода, системной конфигурации и Описан подход к информационному моделирова-
состояния процессов репликации и обработки нию, основанный на доступности неподдельного
данных) и обеспечение быстрого доступа к прошлого и реактивном программировании. Тео-
доступным прошлым состояниям. ретически подход одновременно обеспечивает:
Экономное сохранение истории достигается
разделением данных на небольшие независимо ∙ Возможность неограниченного обновления
изменяемые части. Например, для веб-сайта концептуальной модели, оборудования и
организации, управляемого CMS, должны сохра- сервисов;
няться история изменений шаблонов фрагментов
∙ Устойчивость к предусмотренным задерж-
страниц, версии фрагментов заполнений, версии
кам исполнения и временным потерям
исполняемых процедур, обеспечивающих форми-
связи;
рование страницы на этой основе (об истории
активности пользователей разговор особый). ∙ Быстроту реакции.
Пример: За два года существования сайта Очередным шагом к созданию такой системы
каждый из этих элементов изменяется в станет создание ретроспективной СУБД [11].
272
Благодарности [11] С. В. Знаменский. Ретроспективная ос-
нова совместной реорганизации сложных
Работа проводилась при финансовой поддержке информационных ресурсов. RCDL-2011, с.
Министерства образования и науки Российской 93-101
Федерации. Результаты получены благодаря мно-
[12] L. Bauer, C. Braun, M.E. Imhof, M.A.
голетней поддержке со стороны С. М. Абрамова
Kochte, H. Zhang, H.-J. Wunderlich, J.
и конференций RCDL. Особая признательность
Henkel OTERA: Online Test Strategies
М. Р. Когаловскому за ценные замечания и
for Reliable Reconfigurable Architectures.
рекомендации по изложению.
AHS12, 2012, pp. 38-45.
[13] Angelo Corsaro, Douglas C. Schmidt.
Список литературы The Data Distribution Service – The
Communication Middleware Fabric for
[1] Ji Hong Yan, Chun Hua Feng. Scalable and Extensible Systems-of-Systems.
Sustainability-Oriented Product Modular System of Systems, 2012.
Design Using Design Structure Matrix
[14] Крюков В.А. Операционные системы
(DSM) Method. Applied Mechanics and
распределенных вычислительных систем.
Materials, 2011, pp.1468-1471
Курс лекций (4й курс факультета ВМиК
[2] Betty H.C. Cheng, Rogério de Lemos, МГУ). http://parallel.ru/krukov/.
Holger Giese, Paola Inverardi, Jeff Magee
[15] С. В. Знаменский. Глобальная иден-
Eds. Software Engineering for Self-Adaptive
тификация данных в долговременной
Systems: A Research Roadmap B.H.C.
перспективе. Программные системы: тео-
Cheng et al. (Eds.): Self-Adaptive Systems,
рия и приложения 2012. T. 3, № 2(11), с.
LNCS 5525, 2009, pp. 1–26.
77–88.
[3] A. Metzger, K. Pohl, M. Papazoglou, E.
[16] С. В. Знаменский. Показатели эффек-
Di Nitto, A. Marconi, D. Karastoyanova,
тивности расписания резервного копиро-
“Research challenges on adaptive software
вания. Программные системы: теория и
and services in the future internet: Towards
приложения 2012. T. 3, № 2(11), с. 51–60.
an scube research roadmap,” ICSE 2012.
[4] Eric Brewer, Towards Robust Distributed
Systems, Proceedings of the Nineteenth On the way
Annual ACM Symposium on Principles of to new information systems theory
Distributed Computing, 2000, p. 7. Sergej Znamenskii
[5] Кузнецов С.Д. Транзакционные па- The long-lived evolving system that can adapt to
раллельные СУБД: новая вол- changing requirements and withstand unforeseen
на http://citforum.ru/database/ threats, must be resilient to local losses and
articles/kuz_oltp_2010/ 2010. temporal delays of information. Well-known Brewer
[6] Seth Gilbert, Nancy Lynch. Brewer’s CAP theorem denies the possibility of such systems.
conjecture and the feasibility of consistent, New foundations of information systems allow
available, partition-tolerant web services. us to construct a counterexample. This construction
ACM SIGACT News, 33(2), 2002, pp. theoretically proves the possibility to implement the
51-59. information system with a hundred and more times
better quality than any possible implementation of
[7] D. Sun and C. Sun, Operation Context and
the standard methods.
Context-based Operational Transformation.
The rough sketch of the system architecture is
CSCW 2006. pp. 279–288.
given for general purpose application with unlimitly
[8] Goldman, M., Little, G., and Miller, R. changeable both the functionality and the conceptual
C. Real-time collaborative coding in a web model and also the physical implementation.
IDE. UIST 2011, pp. 155–164.
[9] С.М. Абрамов, С.В. Знаменский, Н.С.
Живчикова, А.В. Котомин, Е.В. Титова
Информационная система для разработки
технологий организации сложной совмест-
ной деятельности. RCDL-2009, c. 186-192.
[10] С. В. Знаменский. Гибкая основа ин-
формационной системы для обучения.
RCDL-2010, с. 451-460.
273