В [7] рассмотрены основные проблемы IT-инфраструктуры кафедры высшего учебного заведения с точки зрения надежности и экономической рациональности. Был предложен подход, основанный на концепции интегрированной логистической поддержки.
Интегрированная логистическая поддержка (ИЛП) является средством управления стоимостью жизненного цикла (СЖЦ) и качеством изделия. Система представляет собой совокупность процессов и процедур, направленных на сокращение затрат на постпроизводственных стадиях жизненного цикла (ЖЦ), повышение отказоустойчивости, надежности и ремонтопригодности изделия [4].
Согласно [3], основным этапом ИЛП является анализ логистической поддержки (АЛП). Исходные данные и результаты АЛП должны храниться в специализированной базе данных – БД АЛП. БД АЛП должна заполняться и поддерживаться в актуальном состоянии на протяжении всего ЖЦИ.
До недавнего времени процесс АЛП регламентировался стандартом министерства обороны США MIL-STD-1388. Процесс АЛП регламентируется стандартом DEF STAN 00-60. Согласно этому документу, результаты АЛП представляются в форме реляционной БД, имеющей регламентированную структуру.
Решением для проведения АЛП от компании НИЦ CALS-технологий «Прикладная логистика» является программный продукт LSA Suite, работающий с СУБД Oracle. Конфигурация подключения к СУБД Oracle имеет трёхуровневую архитектуру «Клиент – Сервер приложений – Сервер БД». Клиент LSA Suite взаимодействует с сервером БД через сервер приложений PSS Oracle server. Данная связка клиента и СУБД успешно работает для выполнения АЛП авиационного объекта.
Предлагаемое решение
IT-инфрастурктура отличается по своей структуре от, например, авиадвигателя или самолета (она значительно проще, чем структура двигателя или самолета). Также не существует опыта проведения АЛП над объектами типа IT-инфрастурктуры [7]. Следовательно, структура БД АЛП непостоянна и будет подвергаться изменению\редактированию. Таким образом, если рассматриваемым объектом будет являться IT-инфраструктура, то предлагается использовать нереляционную, документно-ориентированную базу данных. Которая решит основную проблему, возникающую при использовании реляционной СУБД для БД АЛП IT-инфраструктуры: в случае необходимости будет крайне сложно изменить структуру данных. Также такая БД сложно масштабируема.
Рис. 1. График, качественно отображающий преимущества Mongo DB
Рис. 2. Общий вид части реляционной БД
Документно-ориентированная СУБД допускает гораздо большую вложенность и сложность структуры данных, чем остальные NoSQL СУБД (например, документ вложенный в документ, вложенный в документ. В целом, можно описать сколь угодно сложную структуру данных как документ и сохранить в такой БД. Хорошим примером документно-ориентированной СУБД может служить Mongo DB.
Mongo DB – документно-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Типовая архитектура приложения с доступом к хранилищу данных NoSQL будет состоять из 3 уровней:
● приложение;
● API базы данных NoSQL;
● NoSQL-СУБД.
Mongo DB является нечто средним между реляционными БД (RDB) и СУБД Memcached (программное обеспечение, реализующее сервис кэширования данных в оперативной памяти на основе парадигмы хеш-таблицы) [4].
Если объектом исследования будет являться IT-инфраструктура, то важными отличительными характеристиками БД АЛП под управлением СУБД Mongo DB от СУБД Oracle будут являться:
1. Бессхемность. В отличие от СУБД, NoSQL-системам не требуется, чтобы пользователи определяли схемы своих данных [4].
2. Атомарность и отсутствие транзакций. Транзакции снижают производительность и масштабируемость баз данных по горизонтали [4].
3. Масштабируемость и отказоустойчивость. Коллекции в Mongo DB можно разбивать на несколько кластеров, чтобы данные одной коллекции физически хранились на разных машинах [1].
Таким образом, не будет жесткой зависимости от структуры БД. Также можно будет работать со сложной структурой данных, а объем данных будет ограничен объемом жесткого диска сервера.
Однако есть и недостатки применения данной СУБД. Mongo DB не имеет аналогов операции JOIN, как в реляционных БД. Таким образом, придется «прописывать» JOINы вручную, в коде приложения на клиенте. Взаимодействие с сервером баз данных Mongo DB происходит через обмен документами в текстовом формате JSON.
Структура реляционной БД АЛП
БД АЛП хранит множество различных параметров, хранящихся в таблицах. При разработке документно-ориентированной структуры данных за основу можно взять структуру БД АЛП, разработанную компанией НИЦ «CALS Прикладная логистика». На приведенном ниже рисунке – общий вид части реляционной БД АЛП от компании НИЦ «CALS Прикладная логистика».
Рис. 2 отображает структуру лишь части реляционной БД АЛП. Представленная часть БД хранит основную информацию о проекте АЛП, о возможных конфигурациях, о периодах обслуживания, об элементах изделия, включая их характеристики, такие как время работы, количество элементов в изделии, рекомендуемый период обслуживания и т.д., а также описание функций элементов изделия.
Документы нереляционной БД
Так как Mongo DB – это документно-ориентированная СУБД, то основным объектом в базе данных будет являться документ. Документы объединяются в коллекцию. Каждый документ включает в себя данные, записываемые по принципу ключ-значение (key-value), называемые словарем (dictionary). Ключ в каждом словаре имеет смысл поля в реляционных базах, но он не более чем некоторая метка для значения. Здесь ключ используется как ссылка на часть данных документа.
Описание документа в Mongo DB отображающего проект АЛП
На начальном этапе наполнения БД АЛП необходимо создать новый проект АЛП, содержащий основную информацию о проекте: название, описание, валюта, периоды обслуживания и т.д.
Документ, хранящий информацию о проекте АЛП в документно-ориентированной базе данных Mongo DB, будет иметь следующий вид:
Проект АЛП {
_idLSA project: 001
Title:«IT-инфраструктура»
Describingofproject:«Анализ Логистической поддержки IT-инфраструктуры»
Период начального МТО: 10
Валюта:«Euro»
Наработка: {
Единица измерения:«дни»
Средняя наработка в год: 360}
Периоды обслуживания: {
Обозначение периода: 1
Наименование периода:«Первый»
Длительность периода:«5 лет»}
}
Рис. 3. Общий вид документно-ориентированной БД
Описание документа, отображающего логистическую структуру
Процесс проведения анализа логистической поддержки предполагает создание логистических структур (логистическая структура изделия и логистическая структура функций). Документ, хранящий информацию об элементе в общей структуре финального объекта в документно-ориентированной базе данных Mongo DB, будет содержать информацию о номере элемента, наименовании, функции, ресурсе изделия и т.д. и будет иметь следующий вид:
Логистический элемент {
ЛКН: 01-01-01
Уровень разукрупнения ЛКН: 3
Наименования элемента: «Видеокарта»
Описание элемента: «Видеокарта»
Параметры по умолчанию:{
Интенсивность отказов: 2.3454252
Средняя наработка на отказ: «5 лет»
Типа значения: «Справочник»
Источник данных: «Справочник»
КТПО: «Справочник»
Параметры зависящие от проекта АЛП: {
Наименование проекта АЛП:«Проект АЛП»
Число критичности элемента: 5
Доля времени работы в %: 90}
Параметры элемента ЛСИ, зависящие от проекта АЛП: {
Продолжительность планового обслуживания в год: 5
Трудоемкость планового обслуживания в год: 3
Трудоемкость непланового обслуживания в год: 4
Затраты на обслуживание в течении года (для систем и ФИ): 20000}
Параметры LRU\SRU, зависящие от проекта АЛП: {
Рекомендуемый период обслуживания: «Справочник»
Требуемая вероятность безотказной работы: 96 }
Доля времени работы элемента: 95
Элемент ЛСФ: { Описание функции: «устройство, преобразующее графический образ»
Функция подлежит анализу MSG-3:boolean}
Элемент ЛСИ:{
Является корневым элементом: boolean
Порядковый номер в узле:boolean
Наименование ФИ:IT-инфраструктура
Структура функционального ЛКН: 00 00 00 03 02 02 02
Структура физического ЛКН: 00 00 00 03 02 02 02
Параметры элемента-кандидата (ЭК):{
Тип компонента: «Справочник»
Функция элемента: «устройство, преобразующее графический образ»
Средняя наработка до предотказного состояния:8 лет
Доля наработки для предотказного состояния: 3,4564789
Кратность резервирования: 5
Рекомендуется в качестве запчасти: boolean
Взаимозаменяемость: «Справочник»
Код значимости: «Справочник»
Средняя наработка на внеплановый съем: 5 лет
Назначенный ресурс: 10
Назначенный срок службы: 15 лет}
}
}
Структура нереляционной БД АЛП
Таким образом, можно сделать вывод, что документно-ориентированная БД может быть интереснее для решения поставленной задачи, т.к. добавляет важные преимущества (например, бессхемность и масштабируемость). На рис. 3 представлен пример части документно-ориентированной БД АЛП для IT-инфраструктуры в части создания нового АЛП проекта и структуры ЛСИ.
Рис. 3 отображает структуру нереляционной БД, в которой хранятся результаты и информация, необходимая для АЛП. Структура данной БД отличается от БД, представленной на рис. 2. Если попытаться сравнить структуры обеих баз данных, то можно увидеть, что нереляционная БД позволяет хранить «вложенные сущности» (суб-документы). Таким образом, нереляционная БД допускает большую вложенность и сложность структуры данных.
Заключение
В данной статье были рассмотрены основные проблемы, возникающие при использовании реляционной БД АЛП применительно к IT-инфраструктуре. Было предложено использование нереляционной БД Mongo DB для хранения результатов АЛП, а также разработаны основные документы документно-ориентированной БД.
Рецензенты:
Казанцев В.П., д.т.н., доцент, профессор кафедры микропроцессорных средств автоматизации, ФГБОУ ВПО «Пермский национальный исследовательский политехнический университет», г. Пермь;
Бочкарев С.В., д.т.н., доцент, профессор кафедры микропроцессорных средств автоматизации, ФГБОУ ВПО «Пермский национальный исследовательский политехнический университет», г. Пермь.