IV Международная студенческая научная конференция Студенческий научный форум - 2012

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

Разрабатываемая система METAS Control основана на технологии взаимосвязанных метаданных, описывающих ИС с разных сторон взаимодействия пользователя с данной ИС [1]. В частности, интерпретируя метаданные физического уровня, система формирует запросы к БД для CRUD операций (структура БД заранее не определена). Система является распределенной: сервер выполняет импорт поступающих во внешние источники данных, клиент по собственному запросу / оповещению сервера принимает требуемые данные для отображения.

При проведении мониторинга данные, поступающие от внешних источников, сохраняются в серверной БД с сохранением временных меток (timestamp). Определим схему потоков данных на рис. 1.

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

В связи со спецификой решаемой задачи выделим требования, предъявляемые к кэшу:

• - Кэш является многоуровневым. В системе существуют следующие измерения данных (БД является многомерной): сущности экземпляры сущности атрибуты (время, значение).
• - Кэш реализует алгоритм вытеснения LRU (Least Recently Used - наиболее давно использовавшийся). Соответственно, вследствие работы в режиме real time наиболее давно использующимися элементами являются значения с меньшей временной меткой. Фактически, в связи с характером перемещения и использования данных, LRU совпадет с алгоритмом FIFO.
• - Значения в кэше упорядочены по датам, поэтому вставка / удаление / выборка элемента является достаточно быстрыми по времени операциями; кэш является ассоциативным по времени: считаем стоимость выборки данных по известному ключу равной [10].
• - Интервалы между датами значений не постоянны, т.к. не гарантируется точное считывание и доставка данных на сервер с внешних источников.
• - Так как временной интервал обладает мощностью континуума (т.е.
  ), то вероятность найти значение с временной меткой
  в общем случае равна 0. Поэтому при поиске значения в кэше имеет смысл говорить не о нахождении значения c временной меткой во множестве кэшированных значений , что , а о нахождении значения в заранее заданной временной окрестности : .
• - В кэш значения попадают непосредственно перед вставкой в базу, поэтому разрывов по времени между текущими значениями для одного атрибута нет. Т.е. если известно, что для атрибута в упорядоченном списке кэшированных значений минимальная и максимальная временная метка соответственно равны и , то гарантируется, что .

Кроме текущих значений (с текущими временными метками), пользователь может запросить архивные данные, не содержащиеся в кэше текущих значений. В связи с этим кэш целесообразно разбить на 2 уровня: archive (в нем хранятся недавно используемые архивные данные, запрошенные пользователем для построения отчета / просмотра истории) и runtime (текущие значения показателей за определенный временной интервал).

Такая структура схожа с уровнем Staging Area в архитектуре хранилищ данных (рис. 2). Staging Area - это место для временного хранения копий данных из систем источников [2]. Данные, поступающие из БД приложений, копируются на данный уровень, проходя различные преобразования и предобработки (например, для выполнения выражений требуется, чтобы все аргументы были готовы для выполнения вычислений), трансформации и очистки. Данные, поступающие в кэш, неизменяемы и имеют ценность лишь в ограниченный период времени, что соответствует принципам хранилищ данных.

Кэширование при запросах к БД используется и в ORM-средствах (ORM - Object Relation Mapping, объектно-реляционное отображение), таких как NHibernate и MS EntityFramework. Так, в NHibernate кэшируются не только сами данные, полученные в результате выборки по ключу / произвольному запросу, но и сами запросы и их результаты. Поскольку серверный кэш используется, в основном, в качестве буфера временных значений в течение небольшого интервала времени, то целесообразно использовать кэширование в локальной памяти приложения сервера (подход схож с ORM средствами).

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

Особенности кэширования значений атрибутов на клиенте:

• 1. Достаточно редкое обращение к кэшу (поскольку компоненты имеют свой внутренний кэш небольшого объема) - оптимален вариант с кэшированием с использованием файлов.
• 2. Алгоритм вытеснения - LRU (в нашем случае он совпадает с FIFO).
• 3. Поддержка кэширования любых структур данных постоянного размера (наиболее употребляемые - структуры время-значение типа int или float) - затруднительно использовать кэширование в легковесных настольных БД (SQLite, SQL CE).
• 4. Минимальные накладные расходы (поскольку кэширование выполняется на клиентах, которые стремятся быть "тонкими") - лучше не использовать кэширование в оперативной памяти, (например, memcached и проч.).

Список литературы

1. Воронов В.А., Калашников Е.А., Лядова Л.Н. Технология создания системы мониторинга энергопотребления // Материалы международной научно-технической конференции по интеллектуальным системам AIS´10. - Геленджик-Дивноморское, 2010.
2. Kimball R. - Is Data Staging Relational?. - URL: http://www.kimballgroup.com/html/articles_search/articles1998/9804d05. Дата обращения - 26.01.12.

Код для цитирования: Скопировать