МОДУЛЬ 3

ЛЕКЦИЯ 2 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА:

СРЕДСТВА И ЗАДАЧИ МОДЕЛИРОВАНИЯ ЭКОСИСТЕМ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Програ́ммное обеспе́чение (ПО) – наряду с аппаратными средствами, важнейшая
составляющая информационных технологий, включающая компьютерные программы и
данные, предназначенные для решения определённого круга задач и хранящиеся на
машинных носителях. Программное обеспечение представляет собой либо данные для
использования в других программах, либо алгоритм, реализованный в виде
последовательности инструкций для процессора.
В компьютерном жаргоне для ПО часто используется слово «софт» от английского
software, которое в этом смысле впервые применил в 1958 году в статье American
Mathematical Monthly математик из Принстонского университета Джон Тьюки. В области
вычислительной техники и программирования рассматривают программное обеспечение
как совокупность всей информации, данных и программ, которые обрабатываются
компьютерными системами.
Методология программирования – это совокупность идей, понятий, принципов,
способов и средств, определяющая стиль написания, отладки и сопровождения программ.
Изменения во взаимодействии человека с миром: телефон теперь стал единым
каналом взаимодействия, которое осуществляется в рамках крупных экосистем.
Любая крупная экосистема не имеет географических границ, в ней взаимодействуют
миллионы клиентов, находящихся в любых часовых областях. Эти экосистемы оперируют
петабайтами данных, сотнями и тысячами транзакций в секунду. В основе систем –
технологические платформы, к которым предъявляются схожие требования, а именно:
клиентоцентричность, открытый механизм API, машинное обучение и автоматизированное
обслуживания клиентов, обработка данных в оперативной памяти и ряд других.
Характеризуя экосистемы нового поколения, выделено в них четыре слоя. Первый
слой – универсальный единый фронт-офис, одинаковый для всех цифровых каналов с точки
зрения клиентского опыта, то есть позволяющий клиенту начать осуществление покупки в
одном канале, продолжить в другом и закончить в третьем. Второй слой – уровень бизнес-
логики, где клиенту предлагается сервис. Третий – тот, где находятся продукты и сервисы
игроков данной экосистемы. И четвертый слой – уровень больших данных, где находится
хранилище и вся аналитика, на основании которой работают механизмы машинного
обучения.
***Green IT и устойчивое развитие https://www.icsgroup.ru/library/publications/detail.php?ID=4872

Рисунок 3. – Требования к ИТ системам –презентация на TAdviser SummIT

1
 Для построения экосистемы нового поколения необходимы новые процессы
разработки и внедрения, и в этом контексте актуален переход на среду разработки DevOps и
гибкие методы Agile1, что позволяет осуществлять тестирование и установку новых релизов
в автоматическом режиме.

Рисунок 3. – Архитектура нового поколения – материалы TAdviser SummIT

Что касается технологии искусственного интеллекта, то последние годы

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

Рисунок 3. – Перспективы внедрения Agile и DevOps – слайд из презентации на

TAdviser SummIT
Гріненко О. О., Гріненко С. А. Модель інформаційної взаємодії в екосистемах
програмного забезпечення Телекомунікаційні та інформаційні технології. 2017. №1(54).
С. 104–112.

1
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к
разработке программного обеспечения, ориентированных на использование интерактивной
разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного
взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
Существует несколько методик, относящихся к классу гибких методологий разработки, в частности
экстремальное программирование, DSDM, Scrum, FDD.
Методы Agile — это такие гибкие методологии, как Lean Development («Бережливая разработка ПО»), Scrum и
др., методы Agile направлены в первую очередь на непосредственное общение.
2
 Застосування екологічного підходу до дослідження ПЗ пропонується розглядати через
три напрямки екологічних досліджень ПЗ:“зелене” програмне забезпечення, сталий
розвиток, цифрові екосистеми. Розглядається моделювання екосистем для опису залежності
між виробниками програмного забезпечення, розробниками і кінцевими користувачами,
досліджуються можливості пошуку альтернативних шляхів для досягнення стратегічної мети
кожного учасника.
Екосистеми ПЗ визначають як об'єкти екології програмного забезпечення,
розглядаючи засоби моделювання екосистем ПЗ, типи основних елементів екосистем ПЗ.
Екосистеми ПЗ як системи систем описується з використанням концепцій екосистем та
запропоновано дві моделі екосистем: холістичні, що характеризують систему в цілому, і
метрологічні, що характеризують внутрішню структуру екосистеми.
Екосистема ПЗ – це штучний комплекс, що включає програмне забезпечення,
середовище його розробки, експлуатації, супроводу і утилізації, які пов'язані між собою
обміном програмними продуктами і знаннями. Корпорація «Майкрософт» дає визначення
екосистеми ПЗ як сукупності взаємодій і взаємних впливів організацій (державних,
навчальних і комерційних) і індивідуумів, які працюють з програмним забезпеченням. У
широкому сенсі об'єктом дослідження екосистеми ПЗ є взаємодія ПЗ і природи. У вузькому
смислі об’єкт дослідження – це взаємодія програмного забезпечення із середовищем.
Предметом дослідження є принципи, методи, організації, об’єкти, предмети і процеси
взаємодії. При цьому, беруться до уваги зв'язки живих організмів екосистеми між собою і з
їх неживим (технічним) оточенням. Таким чином розширюються учасники та типи
взаємодій, що підлягають дослідженню, з'являються нові властивості і характеристики,
дослідження екосистем програмного забезпечення.
Прикладом екосистеми ПЗ може служити проект Technology Vision 2015 року. Ідея
проекту полягає в тому, що дрони, оснащені фотокамерами, використовуються для контролю
фізичного стану ліній електропередачі та трубопроводів. Компанія розробляє ПЗ, яке
розпізнає можливі проблеми, аналізуючи фотографії, наприклад, розрив проводів, їх
пошкодження, недозволене будівництво поблизу з об'єктів обстеження та ін. Всі зібрані дані
зберігаються на потужностях "Яндекса" і прямо в "хмарі" обробляються: аналізуються
зібрані фотографії, враховуючи маршрути польотів дронів, формується ортофотоплан і 3D-
модель місцевості, а потім за допомогою різних технік комп'ютерного зору і аналізу даних
формується звіт для клієнта, який відображається у вигляді шарів на "Яндекс Картах". Ця
екосистема, створена для вирішення конкретного завдання, і в ній задіяні виробники дронів,
камер, електроенергетичні підприємства, Accenture, "Сколково", Yandex Data Factory.
Як інший приклад екосистеми ПЗ слід розглянути напрямки Green Software –
«Зелене» ПЗ в контексті Green IT – «зелених інформаційних технологій». В рамках цього
напрямку основний акцент робиться на використанні ПЗ, як засобу прямого або непрямого
зменшення шкідливого впливу на навколишнє середовище. Наприклад, стратегія Green Asus
була сформульована в 2000 році і ділиться на чотири частини, що приводилося вище. Перша
частина – Green-Design – повинна забезпечувати створення і впровадження у виробництво
“зелених” компонентів, які складаються з легко відновлюваних матеріалів та ефективно
утилізуються. Друга частина – Green-Manufacturing – забезпечує розробку та впровадження
економічних та екологічних технологій на виробництві. Третя частина – Green-Procurement –
регламентує логістику товарів, використання матеріалів і компонентів від зовнішніх
виробників. Четверта частина – Green-Marketing – вирішує завдання утилізації старих
комп'ютерів.
Три причини, що викликають застосування екологічного підходу до досліджень
програмного забезпечення. Перші дві пов'язані з концепцією сталого розвитку та
визначаються впливом програмних продуктів та їх виробництв на навколишнє середовище.
3
Третя причина полягає в необхідності спостережень за програмним забезпеченням як за
організованою системою в контексті реального світу.
Перша причина полягає в припущенні, що програмні продукти в складі систем і
технологій та їх виробництво в індустрії ПЗ, як в інших інженерних галузях впливають на
навколишнє середовище. виробництво енергії часто пов'язано з негативним впливом на
екологію планети, причому цей вплив весь час зростає. Засоби обчислювальної техніки,
комп'ютерні системи, самі по собі не відносяться до енергоємних.
Друга причина ґрунтується на відомому феномені розвитку науково-технічного
прогресу, суть якого полягає в тому, що доводиться здійснювати діяльність по ліквідації
результатів діяльності. Третя причина полягає в спостереженні, що ефективне планування
розвитку і обслуговування програмних продуктів вимагає розуміння не тільки їх місця в
реальному світі, обліку їх сталих взаємодій з реальним світом, а також взаємодій всередині
окремого продукту, і всередині елементів продукту, але і розширення учасників і типів
взаємодій, що підлягають дослідженню, розумінню місця ПЗ в історичному контексті.
Так як екосистема ПЗ – це складна система, розглядається її з позиції взаємодії між
трьома компонентами:
– навколишнє середовище (НС) – взаємодіє з об'єктами живої і неживої природи;
– людина – суб'єкт виробничої діяльності ПЗ;
– ПЗ – технічний об'єкт, який взаємодіє з навколишнім середовищем.
Компонент екосистеми ПЗ складається з таких елементів:
а) навколишнє середовище: жива і нежива природа; люди, суспільство; культура;
б) людина: виробник; постачальник; споживач; інші зацікавлені організації та особи;
в) програмне забезпечення: системне ПЗ; вбудовані програми; утиліти; прикладне ПЗ;
інструментальне ПЗ.
Екосистема ПЗ – це множина фізичних або інформаційних компонентів:

де R – екосистема ПЗ, r e – компонент екосистеми ПЗ.

З іншого боку, кожен компонент характеризується:

де ae – назва компонента, re – розмір, Ke – місткість, Ue – стійкість, Ne – надійність, SVe –

самовідновлення, SRe – саморегуляція.
Розмір – це простір, в якому можливе здійснення процесів саморегуляції і
самовідновлення всіх складових компонентів екосистеми.
Місткість – це максимальна чисельність елементів, яку даний компонент здатний
підтримувати в певних умовах протягом тривалого часу.
Стійкість – це здатність компонента екосистеми зберігати свою структуру і
функціональні особливості при впливі зовнішніх і внутрішніх факторів.
Надійність – це здатність компонентів екосистеми щодо повного самовідновлення і
саморегулювання, тобто, утримувати свої основні параметри в часі і просторі.
Самовідновлення – це самостійне повернення компонентів екосистеми до стану
динамічної рівноваги, з якого вони були виведені впливом будь-яких чинників.
Саморегуляція – це здатність компонентів екосистеми до самостійного відновлення
балансу внутрішніх властивостей після будь-якого впливу за допомогою принципу
зворотного зв'язку між її елементами, тобто компонент здатний зберігати свою структуру і
функціонування в певному діапазоні зовнішніх умов.
Усі елементи повинні злагоджено взаємодіють між собою.
Для побудови моделі інформаційної взаємодії екосистему ПЗ з позиції матричної
моделі кожен компонент розглядається як набір зазначених вище елементів, які впорядковані
або пов'язані один з одним і реалізуються через процеси в екосистемі ПЗ. На рис.2 зображена
4
матрична модель інформаційної взаємодії екосистеми ПЗ. Дану модель можна описати у
вигляді матриць (табл.1-3).

У кубі відображається структура взаємодії в екосистемі ПЗ: розподіл потреб в ПЗ в

залежності від факторів НС; виробництво ПЗ; вплив ПЗ на НС.

У процесі взаємодії під впливом інформації кожен з компонентів системи повинен

змінитися. Опис форм інформаційної взаємодії.
1 Категорія «Дія».
– Покращення НС: Інформація про необхідність внесення змін до ПЗ з метою
поліпшення НС.
– Аналіз НС: Інформація про необхідність проаналізувати НС за допомогою ПЗ.
– Пристосування до НС: Інформація про необхідність внесення змін до ПЗ з метою
пристосування до НС.
– Усунення шкідливих наслідків: Інформація про шкідливий вплив результатів
життєдіяльності людей на НС.
2 Категорія «Управління».
– Створення ПЗ: Інформація про необхідність створення ПЗ. Постановка цілей,
завдань, вимог до інтерфейсу, швидкодії ПЗ та інше.
– Зміна ПЗ: Інформація про внесення змін до ПЗ. Виправлення помилок, створення
оновлень, доробка та інше.
– Утилізація ПЗ: Інформація про утилізацію частини або всього ПЗ.
– Маніпуляції з ПЗ: Інформація про проведення маніпуляцій з ПЗ. Продаж,
придбання, налаштування ПЗ та інше.
5
 3 Категорія «Реакція».
– Реакція ПЗ на управління: Інформація про стан ПЗ. Помилки, неефективна робота,
не виконує поставленого завдання, незручний інтерфейс та інше.
4 Категорія «Вплив».
– Позитивна / Негативна. Інформація про позитивний або негативний вплив ПЗ на НС.
Об'єднуються компоненти екосистеми ПЗ і форми взаємодії в єдину модель (рис. 4).

Рисунок 3. – Кругообіг інформації в екосистемі ПЗ

Як приклад надано екосистему ПЗ на приладобудівному підприємстві, яке розробляє

геодезичне обладнання. Компоненти такої екосистеми і їх взаємодія показані на рис. 5, опис
зв’язків подано у табл. 4.

6
 Другие общие тренды развития информационных технологий – повышение
эффективности, снижение TCO, динамическая инфраструктура, роботизация, появление
инженеров, знающих и аналитику, и тестирование, и бизнес-процессы. Ключевой целью
финансовой составляющей любой ИТ-стратегии – снижение стоимости операций при росте
транзакционной загрузки.
Заключительный прогноз – дальнейшая автоматизацию, последовательное удаление
человека из бизнес-процессов, в частности, в США порядка 80% профессий, оплачиваемых
меньше 20 долларов в час, будут заняты роботами в течение ближайших 7 лет.
*****раздел 22 оптимизация базы данных для зеленых информационных
технологий часть vi зеленые базы данных и облачный компьютинг раздел 22
оптимизация баз данных для зеленыхинформационных технологий
Основной формой организации информации в современных информационных
системах (ИС) являются связки «база данных (БД) - система управления базой данных
(СУБД)». Связкой «БД-СУБД» реализуется отделение хранения данных от их обработки. В
этой связке БД – это информационная модель предметной области, представленная в виде
совокупности данных, хранимых в памяти компьютера и связанных между собой правилами,
определяющими общие принципы их описания, хранения и манипулирования, а СУБД – это
совокупность языковых и программных средств, предназначенных для создания, ведения и
совместного использования БД многими пользователями.
Ядром БД является модель данных, т.е. совокупность структур данных (именно они
обеспечивают возможность использования того или иного алгоритма) и операций их
обработки. По своему предназначению СУБД делятся на операционные (т.е. обладающие
высокой скоростью реакции на запрос, извлечения и представления информации),
используются для работы с хранилищами данных, содержащими очень большой объем
информации, подготовка представления которой занимает значительное время.
Реализация зеленой ИТ зависит от качества создаваемой ИС, что, в свою очередь,
связано с решением задач проектирования связок «БД-СУБД». Основными требованиями,
предъявляемыми к связкам «БД-СУБД» являются их безопасность (как ИС) и эффективность
функционирования на протяжении всего жизненного цикла.
Эффективность функционирования ИС, в частности, связок «БД-СУБД», включает
минимизацию потребляемых ресурсов, как на этапе эксплуатации, так и на этапе разработки.
Поэтому проблема оптимизации операций связок «БД-СУБД» обрела еще большую
актуальность на современном этапе «озеленения» вычислений и разработки ИТ.
Применение накопленных моделей и методов оптимизации операций можно (и
нужно) применять для решения задач собственно Green ГГ: вместо оценок времени работы,
памяти и т.д. надо рассматривать в качестве мер сложности, например, потребляемую
энергию. Другими словами, стандартные временные и емкостные сигнализирующие надо
заменить на сигнализирующие, диктуемые спецификой Green IT.
Концепция Green ГТ предполагает снижение энергозатрат при оптимальном
использовании имеющегося оборудования, такого как процессор, дисковые накопители и др.,
что достигается благодаря снижению вычислительной сложности применяемых алгоритмов,
оптимизации структур данных и другими комплексами мероприятий.
Одной из типовых задач повышенной сложности, с которой сталкиваются
архитекторы БД, является задача хранения иерархических данных. Реляционная модель
изначально предназначена для связанных табличных данных, и не рассчитана на хранение
иерархических данных. Применение для этого типа задач специализированных
иерархических хранилищ не оправдано стоимостью их внедрения и слабой популярностью
таких хранилищ. На практике эта задача решается путём использования иерархических
7
структур в реляционных БД. Существует несколько методов построения иерархических
структур в реляционных БД, например четыре таких метода:
1. Вложенное множестве (Nested Set) – это дерево, которое отражает подчинение
элементов одного уровня вложенности другому (упорядоченное по уровню вложенности).
2. Список смежных вершин (Adjacency List) – хранение информации о связях
«наследник – родитель» в виде специальной структуры данных со списком смежных вершин
и уровнями этих вершин.
3. «Замкнутые» таблицы (Closure Tables) – хранится полный перечень путей в дереве,
возможно хранение пути нулевой длины для связи узла с самим собой.
4. Материализованный путь (Materialized Path) – хранение информации о полном пути
от корня дерева к данному узлу в заранее подготовленном виде.
Для выбора метода, наилучшего с точки зрения концепции зеленых ИТ, исследованы
эти методы хранения иерархических данных.
Процесс проектирования связки «БД-СУБД» состоит из следующих 4-х этапов:
1. Системный анализ предметной области.
2. Построение инфологической (концептуальной) модели предметной области. Эта
модель не зависит от СУБД (и, следовательно, от среды хранения данных), и представляется
в терминах выбранной семантической модели (одной из наиболее распространенных
семантических моделей является разработанная П.Ченом ER-модель (Entity Relationship)).
3. Построение логической модели. Выбирается модель данных и тип СУБД. Строится
схема БД и подсхемы для различных пользователей. Создается набор возможных типовых
запросов. Определяются спецификации для программного обеспечения (ПО).
4. Построение физической модели. Выбирается размещение БД на внешних носителях
и определяется используемая СУБД. Создается реальная БД. Программируются и
отлаживаются приложения, которые будут работать с БД.
Результатом процесса проектирования связки «БД-СУБД» является готовая к
заполнению реальная БД и готовое к использованию ПО.
Таким образом, в связке «БД-СУБД» выделяются инфологический, логический и
физический уровни. Первые два уровня называются внешними и предназначены для
поддержки санкционированного доступа к данным БД. Третий уровень называется
внутренним и отображает организацию данных в среде хранения.
С позиции логической модели многообразие типов связок «БД- СУБД» в
значительной мере определяется используемыми моделями данных. В настоящее время
основными являются следующие модели данных.
1. Иерархическая модель – набор ориентированных корневых деревьев. Каждая
вершина дерева соответствует записи (или упорядоченному набору записей) со встроенными
указателями на непосредственного предка (кроме корня дерева) и потомков вершины (кроме
листьев). Поддерживает типы связей «один к одному» и «один ко многим». Модель
эффективна при выполнении запросов, естественно формулируемых в терминах операций
модификации двухсвязных списков.
2. Сетевая модель – набор ориентированных связных графов с рядом ограничений на
их структуру. Расширение возможностей по сравнению с предыдущей моделью состоит в
том, что за счет двух встроенных связей «один ко многим» поддерживается связь «многие ко
многим». Модель эффективна при выполнении запросов, естественно формулируемых в
терминах любых операций над двухсвязными списками.
3. Реляционная модель – основана на понятии «отношение» –одном из основных
понятий математики; набор двумерных таблиц, строки которых имеют одинаковую
структуру. Модель эффективна при выполнении запросов, естественно формулируемых в

8
терминах операций над отношениями. В настоящее время эта модель де-факто является
«промышленным стандартом».
4. Объектно-ориентированная модель – понятиями являються «объект» (имеющий
уникальный идентификатор) и «литерал». Объекты разбиваются на атомарные и
структурированные, инкапсулируют свое состояние (определяемое значениями набора
свойств объекта) и поведение (т.е. операции, которые могут быть выполнены объектом или
над ним). Свойства объекта делятся на атрибуты (не являющиеся объектами и
принимающими в качестве значения литерал или идентификатор) и связи (представленные
посредством ссылочных атрибутов). Объекты, имеющие одинаковые атрибуты и
отвечающие на одни и те же сообщения, образуют класс. Отношение наследования (в
частности, множественное) дает возможность определять один класс как частный случай
другого класса (соответственно других классов).
Таким образом, логическая структура этой модели похожа на структуру
иерархической модели (отличие состоит в методах манипулирования данными).
В настоящее время объектно-ориентированная модель недостаточно проработана
теоретически. Как следствие, отсутствует ее стандарт.
5. Объектно-реляционная модель – расширение реляционной модели за счет
поддержки основных концепций (кроме наследования классов) объектно-ориентированного
программирования [18]. В этой модели сняты ограничения неделимости (атомарности)
значений атрибутов в таблицах, допускаются поля, значениями которых являються таблицы,
встроенные в таблицы. Это дает возможность создавать типы даннях любой степени
сложности. Достоинством модели является возможность использовать существующие
реляционные БД для вновь разрабатываемых приложений. В настоящее время на практике
при объектно-ориентированном подходе к программированию используется именно
объектно-реляционная модель.
6. Многомерная модель – обобщение реляционной модели, набор многомерных
таблиц для аналитической обработки больших объемов информации, связанной со временем
(в частности, для решения задач прогнозирования). Основными понятиями являются
«измерение» и «ячейка». Измерение состоит в выделении множества однотипных данных,
соответствующих грани многомерной таблицы. Ячейка – это поле, значение которого
определяется фиксированным набором измерений. Если все таблицы имеют одинаковую
размерность и совпадающие типы данных при всех измерениях, то модель называется
гиперкубической, иначе – поликубической. В модели реализованы специальные операции
«срез», «вращение», «агрегация» и «детализация», дающие возможность осуществлять
анализ информации на различных уровнях ее обобщения.
Многообразие типов связок «БД–СУБД» с позиции физической модели разделяют на
следующие классы.
1.По среде размещения связка «БД-СУБД» является:
1) локальной (сосредоточенной), если она реализована на одном компьютере;
2) распределенной, если она реализована в компьютерной сети.
2. По способу доступа связка «БД-СУБД» является:
1) мейнфреймовой, если рабочее место – это текстовый или графический терминал, а
вся информация обрабатывается на сервере, т.е. компьютере или компьютерах, где хранится
связка;
2) файл-серверной, если она размещена на сервере, доступ к данным и прикладным
программам осуществляется через локальную сеть, а ядро СУБД реализовано на каждом
клиентском компьютере;

9
 3) клиент-серверной, если она размещена на сервере, доступ к данным
осуществляется через локальную сеть, а клиентская часть СУБД и прикладные программы
реализованы на клиентских компьютерах;
4) встраиваемой, если она является программной библиотекой, т.е. на локальных
компьютерах организовано унифицированное хранение больших объемов данных, а доступ к
ним происходит посредством запросов или вызовом функций библиотеки из приложения
пользователя.
3. По подходу к организации вычислений связка «БД-СУБД» является:
1) классической (фон-неймановской) – при обработке запросов используется только
классический (т.е. последовательный) подход к организации вычислений;
2) нео-классической – при обработке запросов используются параллельные и/или
распределенные вычисления.
В реальной связке «БД-СУБД» время обработки любого запроса состоит из (1)
времени, затраченного на операцию загрузки данных с медленного носителя в оперативную
память, (2) времени, затраченного на вычисление, и (3) времени, затраченного на
возвращение результата в соответствующий медленный носитель. Выделяются следующие
два подхода к анализу эффективности обработки запросов в связке «БД-СУБД».
Первый подход основан на использовании симбиоза математической логики,
теории моделей и прикладной теории алгоритмов. Предметом исследования является
математическая модель связки «БД-СУБД». Цель состоит в построении нижних оценок
асимптотической временной сложности функционирования связки «в наихудшем случае»
или «в среднем».
Второй подход основан исследовании реальной связки «БД-СУБД». Он
осуществляется методами статистического анализа. Цель состоит в оценке реального
времени обработки запросов (возможно, модельными) реализациями связки при тех или
иных условиях.
Одной из основных сложных задач, связанных с появлением связок «БД-СУБД»,
является «оптимизация обработки» запросов СУБД. «Оптимизация» подразумевает выбор
наилучшего (или близкого к нему в соответствии с заданным критерием) объекта или
алгоритма, принадлежащего формально определенному классу, соответственно, объектов
или алгоритмов. Такой подход неприменим ни с теоретической, ни с практической точки
зрения к связке «БД-СУБД» (как и ко многим другим прикладным системам). Поэтому под
«оптимизацией обработки» запросов СУБД понимают стратегии, предназначенные для
повышения эффективности процедур обработки запросов, что является качеством для
фиксации зелености ПО.
Такие стратегии представляют собой эвристические методы, целесообразность
использования которых обосновывается статистическими методами, т.е. обработкой
результатов проведенных экспериментов.
Понятие «запрос», по своей сути, является выражением некоторого языка и
рассматривается, по крайней мере, в следующих трех контекстах:
1) как стандартное требование доступа пользователя к данным БД (в этом случае
«оптимизация» осуществляется за счет программирования соответствующих процедур
поиска данных и преобразования входа пользователя в результат требуемого формата);
2) как транзакция, осуществляющая изменение данных БД на основании их текущего
значения;
3) как выражение, которое СУБД использует для авторизации пользователя [56],
обеспечения целостности данных [57] и синхронизации многопользовательского доступа к
БД [58].

10
 «Оптимизация обработки» запросов, прежде всего, понимается под «стоимостью»
запроса. Выделяют следующие составляющие этого понятия:
1) коммуникационная стоимость, т.е. стоимость передачи данных из их
местоположения во вторичную память (т.е. память, из которой загружаются данные для
вычисления) плюс стоимость перемещения результата в его местоположение;
2)стоимость доступа к вторичной памяти, т.е. стоимость загрузки порций данных из
вторичной памяти в основную память, используемую при вычислении;
3)стоимость запоминания, т.е. стоимость времени использования вторичной памяти и
памяти буферов (что особенно актуально для связок «БД-СУБД», обладающих «узкими
местами», изменяющимися в зависимости от запросов);
4)стоимость вычисления, т.е. стоимость времени, используемого непосредственно для
вычисления.
Таким образом, «оптимизация обработки» запросов представляет собой
нетривиальную многокритериальную задачу.
Методы «оптимизации обработки» запросов привели к пониманию необходимости
разработки полномасштабного унифицированного подхода к решению этой задачи,
основанного на нисходящем подходе (top-down approach). Сформировались следующие три
направления исследования задачи «оптимизация обработки» запросов.
1. Разработка методов «оптимизации обработки» последовательности запросов. Это
попытка снижения стоимости обработки запроса за счет использования в
последовательности составных запросов содержания значительного количества общих
подвыражений.
Первые методы «оптимизации обработки» последовательности запросов были
основаны на исчерпывающемся поиске [63-65]. Эти методы использовали дважды
экспоненциальную память от размера запроса и являлись неэффективными на практике.
Эффективным была разработка методов «оптимизации обработки»
последовательности запросов, основанных на использовании представления запросов
ориентированными ациклическими И-ИЛИ графами (AND-OR DAG representation) [66-68].
Некоторые из них представляют собой прототипы методов, реализованных в SQL Microsoft
Server.
Разработка этих методов – основание для выработки общих рекомендаций увеличения
производительности SQL Microsoft Server 6.5:
1) выделите серверу оперативной памяти, сколько он выдержит;
2) используйте массивы RAID (эти массивы распределяют запросы на чтение по
нескольким физическим дискам) уровня 0 или 5 для распараллеливания получения
информации из БД;
3) обеспечьте для функции Max Async I/O возможность использования всех
преимуществ компьютера;
4) установите пороги расширения блокировок (Lock Escalation) на всю таблицу,
позволяющие избежать «накладных расходов», связанных со значительным числом
блокировок;
5) создайте кластеризованные индексы для запросов, считывающих диапазоны
значений;
6) выделите некластеризованные индексы для запросов на поиск уникальных
значений;
7) создайте составные индексы для поддержания последовательности запросов, что
дает существенный выигрыш, когда, в основном, осуществляется чтение данных и
выполняются операции UPDATE и INSERT;

11
 8) индексируйте соединенные столбцы, что существенно уменьшит (на несколько
порядков) время выполнения соединения таблиц;
9) используйте преимущества покрывающих индексов, т.е. содержащих все столбцы,
указанные в операторах SELECT, UPDATE или DELETE, что уменьшает время выполнения
этих операций до тех пор, пока суммарная длина всех входящих в индекс столбцов
значительно меньше, чем длина строки таблицы.
2. Разработка методов лексической и семантической «оптимизации» запросов.
Лексическая «оптимизация» запроса состоит в его преобразовании, направленном на
устранение избыточности на основе анализа ограничений и условий, содержащихся в нем.
Существуют следующие два подхода к решению этой задачи.
1 Преобразование запроса, представленного на нереляционном языке (а при
необходимости и данных), к реляционной форме, и применение к ней методов лексической
«оптимизации», разработанных для реляционных СУБД [69-71].
2 Построение новых алгебр, предназначенных для представления запросов с учетом
особенностей новых языков, и разработка методов «оптимизации» выражений этих алгебр
[73-75]..
Семантическая «оптимизация» запроса представляет собой валидацию и
преобразование синтаксического дерева запроса к виду, пригодному для выполнения
дальнейших шагов оптимизации. При этом осуществляется преобразование запросов в
каноническую форму (т.е. раскрытие представлений, преобразование подзапросов в
соединения, спуск предикатов), упрощение условий, распределение предикатов и
преобразование дерева условий в пути выборки [78-80].
3. Разработка методов «оптимизации обработки» запросов в параллельной
распределенной связке «БД-СУБД». Именно эти исследования определили следующие три
направления исследований, наиболее интенсивно развивающиеся в настоящее время.
Во-первых, это разработка детерминированных и вероятностных методов
«оптимизации» запросов для различных моделей параллельныхраспределенных связок «БД-
СУБД» [81-83]. Предложен способ выбора архитектуры параллельной распределенной
связки «БД-СУБД» по критерию стоимости с ограничением на верхнюю границу
доверительного интервала времени выполнения запроса. При этом для конфигурации SE [82,
84] исследована зависимость математического ожидания времени выполнения запроса от
числа процессоров. Показано, что с ростом числа процессоров сначала время убывает
благодаря распараллеливанию обработки запроса, а затем возрастает из-за перегрузки
системы ввода/вывода, которая является разделяемым ресурсом.
Во-вторых, это построение моделей связок «БД-СУБД» на основе использования
графических процессоров (GPU) [85-87]. В состав обычного CPU входят от 1 до 16
процессоров, а в состав GPU - несколько сотен простых процессоров. Под «простыми»
понимаются процессоры, не содержащие компонент проверки условий, кэш и т.д.
Архитектура GPU представляет собой SIMT (single instruction multiple thread). Имея
функцию, выполняющую некоторую работу, разработчик 072 €назначает ее исполнение на
тот или иной GPU.
Модель программирования GPU описывает 6 типов областей памяти, различных по
скорости доступа, прав на запись-чтение, объему. Наличие большого числа процессоров и
быстрой памяти обеспечивает эффективность выборки данных со сложным условием –
каждый поток исполняется независимо от других, оперируя малой частью обрабатываемых
данных. Это существенно снижает различие между временем загрузки данных с медленного
носителя в оперативную память и временем, затрачиваемым на исполнения запроса и
возвращения результата.

12
 В-третьих, это разработка моделей и методов обработки и хранения больших данных.
Под термином «большие данные» понимают электронные данные, характеризующиеся
большим объемом, разнообразием и скоростью, с которой структурированные и
неструктурированные данные поступают по сетям передачи в процессоры и хранилища, а
также наличием эффективных процессов переработки данных в требуемую информацию
[88]. Типичными примерами больших данных являются системы компьютерной поддержки
функционирования ведущих фондовых бирж мира, социальная сеть Facebook, проект
Internet Archive, системы компьютерной поддержки уникальных экспериментальных
установок исследования процессов микромира, таких, как Большой андронный коллайдер.
Актуальность разработки средств эффективной обработки больших данных привела к
появлению концепции NoSQL (Not Only SQL). Ее суть состоит в проектировании
архитектуры, обладающей свойством адаптации к возрастающим объемам данных.
При этом сохранение эффективности процессов обработки данных обеспечивается за
счет высокой пропускной способности и потенциально неограниченного горизонтального
масштабирования. Предложена следующая классификация существующих в настоящее
время NoSQL решений по типу используемых хранилищ.
1. Хранилище ключ-значение – «словарь», предназначенный для работы с данными по
ключу. Дает возможность обеспечить высокую производительность обработки данных за
счет усложнения структуры запросов, в словаре отсутствует информация о структуре
значений данных)
2 . Документное хранилище – словарь с логическим объединением множеств пар
ключ-значение в структуру, называемую «документ». Документы имеют вложенную
структуру. Они объединяться в коллекции. Работа с документами по ключу и/или по
значениям атрибутов.
3. Колоночные хранилища. Значения данных хранятся в виде интерпретируемых
байтовых массивов, адресуемых кортежами вида (а1, а2, а3), где а1 – ключ строки, а2 – ключ
столбца и а3 – метка времени [94]. Основой модели является «колонка». Число колонок в
таблице потенциально неограниченно. Колонки по ключам объединяются в семейства,
обладающие заданным набором свойств.
Значительное число публикаций, посвященных «оптимизации запросов» именно для
этой модели обусловлено ее большой схожестью с реляционными связками «БД- СУБД».
4. Хранилища на графах – для объектов с четко выраженной сетевой структурой
(таких, как социальные сети, системы управления авиаперелетами, стратегические системы
обеспечения безопасности страны, глобальные системы оповещения о природных
катастрофах и т.д.). Модель состоит из вершин (в которых сосредоточены данные) и ребер
(размеченных свойствами). Работа с данными осуществляется методом того или иного
обхода графа по ребрам с заданными свойствами.
В настоящее время уделяется внимание разработкам, предназначенным для обработки
потоков событий в реальном времени.

13
 Экосистема данных Сегодня бизнес эффективен, только если он основан на данных,
циркулирующих в специальной экосистеме, построенной на современных и надежных
Системы хранения данных (СХД).
Hitachi VSP 5000 – высокотехнологичное легкое для сборки надежной платформы
данных.
В этой статье будет рассказано о Hitachi Virtual Storage Platform (VSP) серии 5000 –
корпоративной платформе данных самого высокого класса, с возможностью
горизонтального масштабирования, объединяющей в одной среде твердотельные NVMe-
диски, SSD-диски с последовательным подключением SCSI (SAS) и традиционные жесткие
диски HDD.
Среди СХД, как и среди многих высокотехнологических продуктов, есть упрощенные
варианты, «рабочие лошадки» и изделия класса Hi-End, сочетающие сверхвысокую
надежность и максимальные функциональные возможности. Hitachi Virtual Storage Platform
(VSP) серии 5000, безусловно, относятся ко второму классу, поскольку производитель дает
гарантию 100% надежности. Показатели производительности очень высоки – миллионы
операций в секунду.
Есть у VSP 5000 и еще одна важная для рынка особенность: технические
характеристики СХД – класса Hi-End, но ценник совсем не обязательно такого же высокого
уровня — все зависит от конкретной конфигурации. Это возможно благодаря
коммутируемой, модульной архитектуре, позволяющей сравнить СХД VSP 5000 с
высокотехнологичным легко для сборки СХД под требования заказчика. Модульный подход
позволяет масштабировать технические возможности каждой конкретной СХД, без ущерба
для ТТХ системы.
Возможности VSP 5000
Надежность, устойчивость к отказам
Надежность — самый важный показатель работы корпоративной СХД для очень
многих представителей финансовой, транспортной, энергетической и многих других сфер,
где работает крупный бизнес.
СХД серии VSP 5000 – это устройства, обеспечивающие 100% надежность,
доступность данных. Достигается это, в первую очередь, за счет избыточности всех
устройств, применения компонентов и инженерных решений с максимально возможной
степенью надежности. Это позволяет производителю не только заявить о доступности класса
«шесть девяток», но и дать финансовые гарантии 100% доступности данных.
Удобное управление и искусственный интеллект
Управление самыми сложными и высокотехнологичными системами должно быть
удобным, понятным и умным.
Управляющий центр для СХД Hitachi Ops Center имеет интуитивно-понятный
графический интерфейс. С его помощью можно быстро настроить, а потом легко управлять
СХД. API-интерфейсы, выполненные по архитектуре REST, позволяют интегрировать
устройство с разными наборами инструментов и шаблонами автоматизации. Все вместе это
упрощает развертывание, мониторинг и перенастройку ресурсов хранения, обеспечивает
централизацию административных операций.
Центр обеспечивает управление инфраструктурой хранения данных на основе
искусственного интеллекта. Оптимизация, автоматизация, планирование, устранение
неполадок и защита инфраструктуры хранения данных – задачи, которые помогает решить
новейшая технология на основе нейросетей и машинного обучения.
Использование искусственного интеллекта снижает количество задач по управления
хранилищем, возникает экономия человеко-часов, что существенно сократить количество
ручных этапов управления хранилищем.
14
 Готовность к переменам
Технологии устаревают настолько быстро, что думать об их будущем нужно еще до
покупки, в момент выбора подходящей СХД. Время подсказывает: выбор нужно делать в
пользу гибкой и расширяемой инфраструктуры хранения. В будущем это позволит докупать
новые решения и дополнять, а не заменять ими действующее хранилище.
VSP серии 5000 – это первая платформа хранения данных в отрасли, предлагающая в
одной среде NVMe-твердотельный диск, твердотельный диск с последовательным
подключением SCSI (SAS) и использование – в гибридных модификациях – традиционного
жесткого диска HDD. СХД работают с высокоскоростными энергонезависимыми
устройствами класса SCM (Storage-Class Memory) и технологией NVMe-oF.
Такая единая среда способна масштабироваться как по емкости, так и по
производительности. Ее можно дополнять устройствами для хранения любых данных и
поддерживать различные рабочие нагрузки.
Можно увеличить производительность приложений. Прогнозная аналитика —
действенный инструмент в конкурентной борьбе. Она помогает принимать быстрые и
верные управленческие решения на основе знаний, добытых из информации,
циркулирующей в той или иной ИС, в том числе – из потоковых данных. Однако при
обработке потоковых данных возрастает рабочая нагрузка на клиентские приложения и,
соответственно, требования к их производительности. На современном уровне развития
технологий это означает потребность в СХД, построенных на твердотельных накопителях
(SSD), производительность которых повышена с помощью технологии энергонезависимой
памяти.
СХД Hitachi VSP 5000 построена на NVMe и твердотельных накопителях с
интерфейсом SAS. Скорость работы устройств этой серии значительно выше, чем у решений
этого класса других вендоров: обеспечивается до 21 миллиона операций ввода/вывода в
секунду и задержка до 70 микросекунд. Это стало возможно не только благодаря
использованию исключительно флеш-технологий, но и операционной системе Hitachi Storage
Virtualization RF (SVOS RF), уменьшающей нагрузку ввода/вывода при горизонтальном
масштабировании платформы данных.
Можно снизить расходы.
Операционная система SVOS RF не только уменьшает нагрузку при
масштабировании. Она работает по технологии адаптивного сокращения данных (Adaptive
Data Reduce, ADR). Это позволяет лучше использовать хранилища – снижать объем
занимаемой памяти, а значит и затраты на управление данными. И дает возможность
сэкономить не только при покупке мощности, но и на потреблении арендуемой площади,
коммунальных платежах и сопутствующих расходах.
Единое пространство для любых нагрузок — гибкость хранения. В любом
крупном бизнесе сегодня используют множество разных приложений, работающих под
различной нагрузкой и, соответственно, с разными потребностями в ресурсах. Для их
поддержки нужна гибкая, управляемая данными цифровая инфраструктура хранения
данных, готовая к масштабированию и поддержке любой рабочей нагрузки. Решить эту
проблему можно внедрив единую систему, способную консолидировать несколько рабочих
нагрузок любого типа – от традиционных проприетарных приложений (Oracle, SAP,
Microsoft и др.) до современных контейнерных систем, на базе свободного ПО, а также
мейнфреймов.
СХД серии VSP 5000 имеют внутреннюю физическую емкость до 69ПБ и
обеспечивают единое пространство для большинства рабочих нагрузок, а аналитическая
платформа Hitachi Pentaho позволяет в полной мере использовать высокие технические
характеристики СХД этой серии.
15
 Функционал и технические характеристики VSP 5000
СХД VSP 5000 обеспечивают виртуализацию систем хранения, репликацию данных,
управление копированием, аналитику инфраструктуры, миграцию без прерывания работы
устройств. Все модификации имеют гарантии 100% доступности данных. Серия VSP 5000
построена на модульной архитектуре и включает две основных модификации – VSP 5100
(младшего уровня) и VSP 5500 (старшего уровня), у каждой есть гибридный вариант – VSP
5100H и VSP5500H.
Модификации имеют несколько исполнений – наращиваются количество дисков,
внутренняя и внешняя физическая емкости. Для VSP 5500 может увеличиваться число
контроллеров и модулей Fabric Acceleration. В модели 5100 только два контроллера, но она
может быть несложным способом — путем добавления контроллеров и других компонентов
— преобразована в 5500. В гибридном исполнении в состав СХД включаются традиционные
механические HDD, в дополнение к твердотельным. Кроме того, появляется возможность
динамического перемещения данных по уровням хранения между флэш-накопителями
NVMe/SAS и HDD. Основные технические показатели VSP 5100: до 4,2 млн операций
ввода/вывода в секунду, пропускная способность — 25 Гб/сек, максимальная внутренняя
физическая емкость 23 Пб. Для VSP 5500 те же показатели, соответственно: до 21 млн iOPs,
149 Гб/сек. и 69 Пб. Минимальное время отклика зависит от профиля нагрузки, номинальная
величина — 70 мкс. Гарантированное сжатие данных 4:1.
Основные технические характеристики Hitachi VSP серии 5000
VSP 5100 VSP 5500
Максимальный объем внутренней
23 69
емкости, ПБ
Макс. внешняя емкость, ПБ 287 287
Количество операций, млн. операций
4,2 21
ввода/вывода в секунду (iOPS)
Пропускная способность, ГБ/сек. 25 149
Число контроллеров, шт. 2 4, 8, 12
Коммуникация контроллеров, кол-во
4 8, 16, 24
модулей Fabric Acceleration
Выводы
Устройства такого класса надежности как СХД VSP 5000 необходимы, в первую
очередь, тем компаниям и деловым структурам, для кого бесперебойная работа — насущная
жизненная необходимость. Простой или даже небольшие перебои в доступе к данным могут
привести либо к катастрофическим последствиям — как, например, в случае с
информационной системой аэропорта или атомной станции, либо к колоссальным
финансовым убыткам — случай крупного розничного банка. Второй признак того, что
нужны именно высокопроизводительные СХД, — высокая нагрузка на инфраструктуру
хранения данных, и, соответственно, требование предсказуемости работы СХД при любых
режимах работы. И третий показатель — потребность в создании единого цифрового
пространства хранения данных, в том числе — с возможностью коммутации с
мейнфреймами.
Высокие характеристики надежности и производительности подтверждаются
практикой: 87% финансовых компаний из списка Fortune 100 доверяют СХД Hitachi свои
критически важные данные.

Мост от среднего к крупному: как выбрать СХД для растущего бизнеса VSP E990
завершает линейку СХД среднего класса от Hitachi. Это полностью твердотельная, с
16
энергонезависимой памятью платформа хранения данных (all-flash NVMe), предназначенная
для приложений, требующих высокой и предсказуемой производительности,
чувствительных к задержке. Данная СХД ориентирована на предприятия «мостового
диапазона», то есть предприятия, которые в результате естественного роста бизнеса,
слияний и поглощений оказались на стадии перехода от среднего бизнеса к крупному.
Предприятие, переходящее от среднего масштаба бизнеса к крупному, испытывает ряд
специфических проблем:
 разрыв в навыках специалистов ИТ-подразделения, привыкших больше внимания
уделять техническому обслуживанию, а не стратегическим проектам для развития бизнеса;
 необходимость выполнять больше внутренних и внешних SLA с меньшими
затратами, без привлечения дополнительных ресурсов;
 задача для бизнеса стать более гибким, получать большую пользу от данных в
соответствии с новыми требованиями цифровой трансформации;
 низкая эффективность, растянутость бюджетов, в то время как клиенты требуют
инноваций для удовлетворения своих технологических потребностей; непредсказуемый рост
бизнеса;
 необходимость защищать данные, ценность которых возрастает.
Общая линейка. Чтобы правильно оценить место, занимаемое массивом E990,
напомним, как выглядит вся продуктовая линейка СХД от Hitachi:VSP серии 5000:
мультиконтроллерные полностью твердотельные системы верхнего уровня,
ориентированные на максимально большие объемы бизнеса с самыми высокими
требованиями по производительности и надежности, предназначены для задач сегмента
Enterprise, модификации – VSP 5100 и VSP 5500 (гибридные варианты систем, с
возможностью использования традиционных HDD наряду с SDD, – VSP 5100H и VSP
5500H);VSP серии E: двухконтроллерные полностью твердотельные системы для средних
предприятий, но с повышенными требованиями к мощности и быстродействию СХД,
предназначены для задач и приложений, требующих высокую производительность, но по
объёмам не относящихся к масштабу Enterprise, модификации – E590, E790 и E990;VSP
серии F: двухконтроллерные полностью твердотельные системы, готовые к работе в
облачной инфраструктуре и стабильной поддержке работы с данными любого бизнеса,
модификации – F700 / F900 (гибридные варианты – G700 / G900), F350 / F370 (гибридные
системы – G350 / G370).
Таким образом, предприятиям предлагается длинная линейка моделей СХД в
широком диапазоне цен и мощностей для различных вариантов использования и бизнеса
разного масштаба – от среднего уровня до самых крупных предприятий.
Место E990 по техническим параметрам. Массив E990 по ряду технических
показателей превосходит другие решения среднего уровня – Е590 и Е790. Например,
максимальный объем внутренней физической памяти у этой СХД составляет 1,444 ПБ (361
Тб у младших моделей). Главное же, что выделяет этот массив в E-серии: эта СХД может
быть расширена до 96 NVMe-носителей с применением интерфейса PCIe между
контроллерами и полками расширения, то есть имеет коммутируемую внутреннюю
архитектуру, сходную с VSP серии 5000.
Если продолжить сравнение массива Е990 с решениями Hitachi премиального класса,
то по многим техническим параметрам эта СХД находится с ними на одном уровне (см.
Таблица) — например, гарантия абсолютной эффективности до 7:1. Эта гарантия
подразумевает экономию за счет дедупликации, сжатия данных, моментальных снимков и
тонкого выделения ресурсов. По количеству же операций ввода/вывода и пропускной
способности Е990 даже опережает модель VSP 5100: 5,8 млн. оп/сек и 30 Гб/сек против 4,2
млн.оп./сек и 25 Гб/сек.
17
 Таким образом, массив E990 как бы заполняет пробел между СХД среднего уровня и
массивами высочайшего класса, ориентированными на самые крупные предприятия.
Технические характеристики VSP E990 и VSP серии 5000
VSP Е990 VSP 5100 VSP 5500
1,444 ПБ
Максимальный объем 23 ПБ 69 ПБ
(15 ТБ
внутренней физической (30 ТБ (30 ТБ
NVMe
емкости SSD) SSD)
SSD)
Гарантия абсолютной
до 7:1 до 7:1 до 7:1
эффективности
Гарантированное сжатие
4:1 4:1 4:1
данных
Количество операций
4,2 21
ввода/вывода в секунду 5,8 млн/сек
млн/сек млн/сек
(iOPS)
149
Пропускная способность 30 ГБ/сек. 25 ГБ/сек
ГБ/сек
288
96 NVMe
NVMe
Максимальное количество 33 NVMe
33 NVMe
накопителей на базе флеш- SCM
96 NVMe SCM
памяти, включая запасные, 192 FMD
576 FMD
шт. 768 SFF
2,304
SSD
SFF SSD
Аппаратная часть
Массив E990 выполнен в форм-факторе 4U, с активным контроллером и внутренней
шиной PCIe. Внутренняя аппаратная емкость этой СХД варьируется в диапазоне от 6 ТБ до
1.4 ПБ. Максимальное число хост-портов может быть доведено до 80 волоконно-оптических
(пропускная способность – 32 Гб/сек или 16 ГБ/сек) и 40 по стандарту iSCSI (10 ГБ/сек).
СХД Е990 использует прямой аппаратный доступ к памяти.
Программное обеспечение. Как и VSP 5000, массив E990 управляется ОС
виртуализации хранения данных SVOS RF (версия 9.4), позволяющей использовать
преимущества NVMe-носителей, обеспечивая тем самым лучшую в своем классе СХД
производительность и низкую задержку (до 64 мкс). Все системы хранения VSP E990
включают следующее программное обеспечение, входящее в состав Hitachi Ops
Center:Hitachi OPS Center Administrator: системное администрирование;Hitachi OPS Center
Protector: расширенное управление перемещением, локальная защита данных и управление
их копированием;Hitachi OPS Center Analyzer: ИТ-аналитика и анализ хранения данных.
Работа ПО Hitachi OPS Center основана на искусственном интеллекте и машинном
обучении, что делает управление VSP E990 простым и эффективным. Это ПО обновляется
без дополнительных затрат со стороны предприятия.
Технология Advanced Data Reduction (ADR), также базирующаяся на ИИ, в разы
повышает эффективность использования физической емкости Е990, гарантируя уменьшение
объема данных в соотношении 4:1.
По требованию клиента система E990 способна поддерживать технологии SCM
(Server Class Memory) и NVMe-oF – как и у VSP серии 5000. По оценке экспертов, спрос на
эти технологии на рынке пока невелик, и, тем не менее, такая возможность предусмотрена
для использования.

18
 Функциональные возможности. VSP E990 обеспечивает широкие функциональные
возможности, а именно:
1) 100% доступность данных;
2) гарантированно высокую производительность, доступность и масштабируемость
данных, что дает надежную платформу для цифровой трансформации;
3) сокращение затрат на хранение данных;
4) ускорение предоставления приложений пользователям до 90%;
5) анализ показателей телеметрии на всем пути передачи данных, от виртуальной
машины до общих ресурсов хранения, что, в свою очередь, обеспечивает ускоренный поиск
и устранение неисправностей;
6) снижение количества выполняемых вручную задач, что позволяет ИТ-
специалистам уделять меньше времени техническому обслуживанию и больше –
стратегическим вопросам развития экосистемы данных на предприятии;
7) облачная модель потребления, позволяющая сократить затраты на ресурсы;
8) возможность выбора предоставляемых услуг, что дает снижение
эксплуатационных расходов;
9) предсказуемость результатов, что позволяет оптимизировать затраты в
соответствии с фактическим использованием ресурсов.
Выводы. Высокопроизводительный полностью твердотельный (all-flash NVMe)
массив VSP E990 предназначен для обслуживания критически важных рабочих нагрузок
внутри системы хранения данных, не требующей поддержки традиционных жестких дисков
(HDD). Данная СХД ориентирована на средний бизнес, работающий с данными в режиме
крупного предприятия. VSP E990 имеет коммутируемую внутреннюю архитектуру, сходную
с VSP серии 5000, и ту же операционную систему SVOS RF в целях гарантированного
сокращения объема данных, высокой производительности и эффективности. Отметим в
заключение, что в ценовом плане, в сравнении с аналогичными массивами от Pure Storage и
Dell EMC, массив Hitachi VSP E990 конкурентоспособен.

19
 Что такое гибридное облако и почему оно полезно бизнесу
Современный бизнес всё больше уходит в облако, чему особенно поспособствовала
ситуация с пандемией COVID-19, из-за которой во многих предприятиях значительная часть
сотрудников была переведена на удалённую работу. Они по разным причинам не могла
получать полноценный доступ к локальной ИТ-инфраструктуре.
Однако далеко не все организации готовы полностью перейти в общедоступное
облако, в частности, по соображениям безопасности и надёжности, а также в связи с
требованиями регуляторов. При этом многие желали бы пользоваться преимуществами
гибкости и масштабируемости, предлагаемыми облачными сервисами. В таких случаях
оптимальным решением может стать гибридное облако, объединяющее частное и
общедоступное облака в единую инфраструктуру. В каких кейсах имеет смысл выбрать
гибридное облако и какие решения лучше использовать, нам помогал разобраться Олег
Головко, первый заместитель управляющего директора компании «ЛАНИТ-Интеграция»
(входит в группу ЛАНИТ).
Зачем нужно гибридное облако
Основа гибридного облака – единый инструмент централизованного управления
вычислительными ресурсами и ресурсами хранения данных. При этом управление ведётся в
разрезе сервисов, а сами ресурсы располагаются как в собственном ЦОД предприятия, так и
у публичных провайдеров.
Типовые случаи использования гибридной модели: Вы – продуктовая компания и
регулярно выпускаете релизы своих приложений. Соответственно, вам периодически нужно
проводить функциональное, интеграционное и нагрузочное тестирование, которое требует
дополнительных вычислительных мощностей на короткий срок. Приобретать собственное
«железо» под задачи с такими непостоянными нагрузками просто нецелесообразно – проще
вынести тестовые среды в публичное облако. Кроме того, вы оплачиваете лишь
потребленные ресурсы, а протестированный код вашего высоконагруженного приложения
переносится в продуктивную среду в своём частном облаке. Такой подход применим ещё и
потому, что при тестировании используются обезличенные данные, которые можно
спокойно размещать вне доверенной зоны безопасности. У вас B2C онлайн-сервис, и вы
хотите подготовиться к росту количества пользователей. Как и в первом кейсе, приобретать
новое «железо», чтобы обеспечить стабильную работу онлайн-площадки в период пиковых
нагрузок, – экономически необоснованно. Автоматическое масштабирование ресурсов в
облаке решит задачу, сохранив лояльность ваших клиентов. Вам нужна резервная площадка
для обеспечения катастрофоусточивости ваших сервисов. В случае аварии в вашем ЦОДе,
резервная площадка в публичном облаке перехватит основную нагрузку, а после вы сможете
вернуться к своей ИТ-инфраструктуре, держа публичное облако наготове. Кроме того,
облачные провайдеры предлагают различные уровни хранения с разной
производительностью. Например, на «горячих» уровнях размещают данные, к которым часто
обращаются и для работы с которыми требуется высокая скорость. Для менее актуальных
данных, которые нужны редко (резервные копии или архивы), достаточно «холодных»
уровней. То же самое касается и вычислительных мощностей с различными уровнями
переподписки. Низкие уровни могут стоить до 5 раз дешевле, плюс – их можно менять в
любое время в зависимости от ваших потребностей. Вы стремитесь оказывать качественный
сервис по всему миру в соответствии с местным законодательством. В этом случае вам
приходится выносить часть своих данных и информационных систем ближе к региональным
точкам обмена трафиком, например, в Амстердам, чтобы минимизировать задержки при
передаче данных и тем самым повысить эффективность работы с локальными заказчиками.
Кроме того, нужно соблюдать законодательство о персональных данных, которое в том или
ином виде существует в большинстве стран.
20
 Затраты на создание гибридной модели с единым управлением и каталогом сервисов
можно компенсировать за счёт её же преимуществ:
 автоматизация процесса поможет системным администраторам и разработчикам в
пару кликов или автоматически через программный интерфейс перемещать нагрузку между
дата-центрами и облаками,
 ИТ-директору – повысить эффективность использования инфраструктуры (как
частной, так и публичной) на основе данных о её потреблении различными командами в
режиме реального времени.
Какие решения лучше использовать. Перед компанией, решившей перейти на
гибридную модель, стоят две большие задачи: создание единого портала управления ИТ-
инфраструктурой и миграция приложений на облачную инфраструктуру с соответствующим
изменением процессов разработки и защиты информации. Обе задачи действительно
трудозатратны – нужна экспертиза и опыт.
Для интеграторов оптимизация ИТ-инфраструктуры – исторически сильное
направление работы. В «ЛАНИТ-Интеграции» подходят к решению этой задачи поэтапно и
комплексно:
Сначала проводится оценка требований к непрерывности бизнеса с учётом
функциональных задач заказчика, особенностей обрабатываемой информации, а также
требований внешних стейкхолдеров. Затем проводится анализ ИТ-инфраструктуры заказчика
и подбирается оптимальная платформа централизованного управления, а также провайдера,
в облаке которого лучше размещаться. Для снижения зависимости от технологий
конкретного поставщика (vendor lock), рекомендуется использовать решения не одного, а
нескольких производителей.Проводится оптимизация и автоматизация гибридной
инфраструктуры.Проводится миграция ИТ-решений на облачную инфраструктуру с учётом
требуемых параметров отказоустойчивости.Реализуется автоматизация процессов DevOps в
облачной среде (проектирование и внедрение процессов CI/CD).
Обеспечивается compliance: разрабатываются предложения по повышению уровня
информационной безопасности и непрерывности деятельности в облачной
инфраструктуре.
Если у заказчика есть критическая информационная инфраструктура и серьёзные
планы по развитию бизнеса, интегратор помогает определить, какую её часть можно вынести
в публичное облако с учётом наложенных средств безопасности, выбрать провайдера,
соответствующего требованиям регулятора, а также обеспечивает безопасное
взаимодействие публичного и частного облаков.
«ЛАНИТ-Интеграция» помогает управлять данными за счёт их миграции, хранения
и обработки в облачной инфраструктуре, а также создания единого хранилища данных,
которое используется различными бизнес-приложениями как источник для аналитики.

О. С. Бомчик, Я. С. Парамуд Комп’ютерна система управління багатоканальними

освітлювальними пристроями © Бомчик О. С., Парамуд Я. С., 2018
O. Bomchyk, Y. Paramud Lviv Polytechnic National University, Computer Engineering Department
Для управління світловими пристроями, а саме світлодіодними, сьогодні все частіше впроваджують
нові комп’ютерні системи, які передають сигнал управління за допомогою різних інтерфейсів та протоколів. Ці
протоколи дозволяють стандартизувати процес управління світловими пристроями, які виробляються різними
фірмами [1]. Протоколи для керування світловим обладнанням не є ідеальними, і їх постійно вдосконалюють.
Впровадження нових протоколів приводить до створення нових освітлювальних пристроїв та відповідних
засобів управління. Алгоритми управління постійно вдосконалюють і їх реалізація потребує застосування
сучасних складних комп’ютерних засобів та технологій. Виникає необхідність застосування
високопродуктивних обчислювальних пристроїв, здатних виконати значну обчислювальну роботу в реальному,
жорстко обмеженому, часі та впровадження нових інтерфейсів, які б швидко передавали команди управління
від обчислювача до виконавчих елементів та освітлювальних пристроїв. Виконання обчислювальної роботи

21
можна покладати на персональні комп’ютери (ПК), мобільні пристрої, мікро-ЕОМ та мікроконтролери. Обмін
інформацією доцільно здійснювати магістральними інтерфейсами, які мають здатність забезпечити
багатоканальність. Для реалізації безпровідникового управління можна використовувати стандарт WIFI.
Впровадження такого управління передбачає наявність мережевих засобів та спеціального програмного
забезпечення, яке буде встановлено на планшет або мобільний пристрій. Такий спосіб віддаленого управління
зручно використовувати, коли потрібно досягти мобільності при управлінні багатоканальними
освітлювальними пристроями.

22