НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

"ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ"

КОЗУЛЯ Тетяна Володимирівна

Дисциплина
GREEN COMPUTING

Частина 2 Green computing. теорія та практика екологічно орієнтованих

інформаційних комп’ютерних технологій.

Модуль 3
Зеленые информационные системы и технологии – Green IT

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

СРЕДСТВА И ЗАДАЧИ МОДЕЛИРОВАНИЯ ЭКОСИСТЕМ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
 Модуль 3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 2
Программное обеспечение представляет собой либо данные для использования в других
программах, либо алгоритм, реализованный в виде последовательности инструкций для
процессора.
В компьютерном жаргоне для ПО часто используется слово «софт» от английского
software.
В области вычислительной техники и программирования рассматривают программное
обеспечение как совокупность всей информации, данных и программ, которые обрабатываются
компьютерными системами.
Методология программирования – это совокупность идей, понятий, принципов, способов и
средств, определяющая стиль написания, отладки и сопровождения программ.
Любая крупная экосистема не имеет географических границ, в ней взаимодействуют
миллионы клиентов, находящихся в любых часовых областях. Эти экосистемы оперируют
петабайтами данных, сотнями и тысячами транзакций в секунду. В основе систем –
технологические платформы, к которым предъявляются схожие требования, а именно:
клиентоцентричность, открытый механизм API, машинное обучение и автоматизированное
обслуживания клиентов, обработка данных в оперативной памяти и ряд других.
Характеризуя экосистемы нового поколения, выделено в них четыре слоя.
Первый слой – универсальный единый фронт-офис, одинаковый для всех цифровых
каналов с точки зрения клиентского опыта, то есть позволяющий клиенту начать
осуществление покупки в одном канале, продолжить в другом и закончить в третьем.
Второй слой – уровень бизнес-логики, где клиенту предлагается сервис.
Третий – тот, где находятся продукты и сервисы игроков данной экосистемы.
Четвертый слой – уровень больших данных, где находится хранилище и вся аналитика,
на основании которой работают механизмы машинного обучения
 Модуль 3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 3
Для построения экосистемы
нового поколения
необходимы новые
процессы разработки и
внедрения, и в этом
контексте актуален переход
на среду разработки DevOps
и гибкие методы Agile, что
позволяет осуществлять
тестирование и установку
новых релизов в
автоматическом режиме
Что касается технологии
искусственного интеллекта, то
Архитектура нового поколения – материалы TAdviser SummIT
последние годы
осуществляются большие
объемы инвестиций в
машинное обучение,
автоматическое принятие
решений. Для решений в этой
сферешироко используются
технологии с открытым кодом
, и этот путь – это
максимально быстрый способ
Перспективы внедрения Agile и DevOps развития новых технологий.
 М3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 4
Екосистеми ПЗ визначають як об'єкти екології програмного забезпечення, розглядаючи засоби моделювання
екосистем ПЗ, типи основних елементів екосистем ПЗ.
Екосистеми ПЗ як системи систем описується з використанням концепцій екосистем та запропоновано дві
моделі екосистем: холістичні, що характеризують систему в цілому, і метрологічні, що характеризують
внутрішню структуру екосистеми.
Екосистема ПЗ – це штучний комплекс, що включає ПЗ, середовище його розробки, експлуатації, супроводу
і утилізації, які пов'язані між собою обміном програмними продуктами і знаннями.
Об’єкт дослідження – це взаємодія програмного забезпечення із середовищем. Предметом дослідження є
принципи, методи, організації, об’єкти, предмети і процеси взаємодії, беруться до уваги зв'язки живих
організмів екосистеми між собою і з їх неживим (технічним) оточенням.
Прикладом екосистеми ПЗ може служити проект Technology Vision 2015 року. Ідея проекту полягає в
тому, що дрони, оснащені фотокамерами, використовуються для контролю фізичного стану ліній
електропередачі та трубопроводів. Всі зібрані дані зберігаються на потужностях "Яндекса" і прямо в "хмарі"
обробляються: аналізуються зібрані фотографії, враховуючи маршрути польотів дронів, формується
ортофотоплан і 3D-модель місцевості, а потім за допомогою різних технік комп'ютерного зору і аналізу даних
формується звіт для клієнта, який відображається у вигляді шарів на "Яндекс Картах". Ця екосистема,
створена для вирішення конкретного завдання, і в ній задіяні виробники дронів, камер, електроенергетичні
підприємства, Accenture, "Сколково", Yandex Data Factory.
Як інший приклад екосистеми ПЗ слід розглянути напрямки Green Software – «Зелене» ПЗ в контексті
Green IT – «зелених інформаційних технологій». В рамках цього напрямку основний акцент робиться на
використанні ПЗ, як засобу прямого або непрямого зменшення шкідливого впливу на навколишнє
середовище. Наприклад, стратегія Green Asus була сформульована в 2000 році і ділиться на чотири частини,
що приводилося вище. Перша частина – Green-Design – повинна забезпечувати створення і впровадження у
виробництво “зелених” компонентів, які складаються з легко відновлюваних матеріалів та ефективно
утилізуються. Друга частина – Green-Manufacturing – забезпечує розробку та впровадження економічних та
екологічних технологій на виробництві. Третя частина – Green-Procurement – регламентує логістику товарів,
використання матеріалів і компонентів від зовнішніх виробників. Четверта частина – Green-Marketing –
вирішує завдання утилізації старих комп'ютерів.
 М3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 5
Три причини, що викликають застосування екологічного підходу до досліджень
програмного забезпечення.
Перша причина полягає в припущенні, що програмні продукти в складі систем і технологій
та їх виробництво в індустрії ПЗ, як в інших інженерних галузях впливають на навколишнє
середовище. виробництво енергії часто пов'язано з негативним впливом на екологію НС,
цей вплив весь час зростає.
Друга причина ґрунтується на відомому феномені розвитку науково-технічного прогресу,
суть якого полягає в тому, що доводиться здійснювати діяльність по ліквідації результатів
діяльності. Третя причина полягає в спостереженні, що ефективне планування розвитку і
обслуговування програмних продуктів вимагає розуміння не тільки їх місця в реальному
світі, обліку їх сталих взаємодій з реальним світом, а також взаємодій всередині окремого
продукту, і всередині елементів продукту, але і розширення учасників і типів взаємодій, що
підлягають дослідженню, розумінню місця ПЗ в історичному контексті.
Екосистема ПЗ – це складна система, розглядають її з позиції взаємодії між трьома
компонентами:
– навколишнє середовище (НС) – взаємодіє з об'єктами живої і неживої природи;
– людина – суб'єкт виробничої діяльності ПЗ;
– ПЗ – технічний об'єкт, який взаємодіє з навколишнім середовищем.
Компонент екосистеми ПЗ складається з таких елементів:
а) навколишнє середовище: жива і нежива природа; люди, суспільство; культура;
б) людина: виробник; постачальник; споживач; інші зацікавлені організації та особи;
в) програмне забезпечення: системне ПЗ; вбудовані програми; утиліти; прикладне ПЗ;
інструментальне ПЗ.
 М3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 6
Екосистема ПЗ – це множина фізичних або інформаційних компонентів:
де R – екосистема ПЗ, r e– компонент
екосистеми ПЗ.
З іншого боку, кожен компонент
характеризується:

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

самовідновлення, SRe – саморегуляція.

Розмір – це простір, в якому можливе здійснення процесів саморегуляції і самовідновлення всіх

складових компонентів екосистеми.
Місткість – це максимальна чисельність елементів, яку даний компонент здатний підтримувати
в певних умовах протягом тривалого часу.
Стійкість – це здатність компонента екосистеми зберігати свою структуру і функціональні
особливості при впливі зовнішніх і внутрішніх факторів.
Надійність – це здатність компонентів екосистеми щодо повного самовідновлення і
саморегулювання, тобто, утримувати свої основні параметри в часі і просторі.
Самовідновлення – це самостійне повернення компонентів екосистеми до стану динамічної
рівноваги, з якого вони були виведені впливом будь-яких чинників.
Саморегуляція – це здатність компонентів екосистеми до самостійного відновлення балансу
внутрішніх властивостей після будь-якого впливу за допомогою принципу зворотного зв'язку між її
елементами, тобто компонент здатний зберігати свою структуру і функціонування в певному діапазоні
зовнішніх умов.
 М3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА 7
Для побудови моделі інформаційної взаємодії екосистему ПЗ з позиції матричної моделі кожен
компонент розглядається як набір зазначених вище елементів, які впорядковані або пов'язані один з
одним і реалізуються через процеси в екосистемі ПЗ.
У кубі відображається
структура взаємодії в
екосистемі ПЗ: розподіл
потреб в ПЗ в залежності від
факторів НС; виробництво ПЗ;
вплив ПЗ на НС
 М3_ 2.1_ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ЭКОСИСТЕМА
Кругообіг інформації в екосистемі ПЗ
Як приклад надано екосистему ПЗ на приладобудівному
підприємстві
8
Опис форм інформаційної взаємодії.
1 Категорія «Дія».
– Покращення НС: Інформація про необхідність
внесення змін до ПЗ з метою поліпшення НС.
– Аналіз НС: Інформація про необхідність
проаналізувати НС за допомогою ПЗ.
– Пристосування до НС: Інформація про
необхідність внесення змін до ПЗ з метою
пристосування до НС.
– Усунення шкідливих наслідків: Інформація про
шкідливий вплив результатів життєдіяльності людей
на НС.
2 Категорія «Управління».
– Створення ПЗ: Інформація про необхідність
створення ПЗ. Постановка цілей, завдань, вимог до
інтерфейсу, швидкодії ПЗ та інше.
– Зміна ПЗ: Інформація про внесення змін до ПЗ.
Виправлення помилок, створення оновлень, доробка т.
– Утилізація ПЗ: Інформація про утилізацію
частини або всього ПЗ.
– Маніпуляції з ПЗ: Інформація про проведення
маніпуляцій з ПЗ. Продаж, придбання, налаштування
ПЗ та інше.
3 Категорія «Реакція».
– Реакція ПЗ на управління: Інформація про стан
ПЗ. Помилки, неефективна робота, не виконує
поставленого завдання, незручний інтерфейс та інше.
4 Категорія «Вплив».
– Позитивна / Негативна. Інформація про
позитивний або негативний вплив ПЗ на НС.
Об'єднуються компоненти екосистеми ПЗ і
 М3_2.2_Зеленые базы данных и «оптимизация обработки» запросов 9
Основной формой организации информации в современных информационных
системах (ИС) являются связки «база данных (БД) - система управления базой данных
(СУБД)». Связкой «БД-СУБД» реализуется отделение хранения данных от их обработки. В
этой связке БД – это информационная модель предметной области, представленная в виде
совокупности данных, хранимых в памяти компьютера и связанных между собой
правилами, определяющими общие принципы их описания, хранения и манипулирования, а
СУБД – это совокупность языковых и программных средств, предназначенных для
создания, ведения и совместного использования БД многими пользователями.
Ядром БД является модель данных, т.е. совокупность структур данных (именно они
обеспечивают возможность использования того или иного алгоритма) и операций их
обработки. По своему предназначению СУБД делятся на операционные (т.е. обладающие
высокой скоростью реакции на запрос, извлечения и представления информации),
используются для работы с хранилищами данных, содержащими очень большой объем
информации, подготовка представления которой занимает значительное время.
Реализация зеленой ИТ зависит от качества создаваемой ИС, что, в свою очередь,
связано с решением задач проектирования связок «БД-СУБД». Основными требованиями,
предъявляемыми к связкам «БД-СУБД» являются их безопасность (как ИС) и
эффективность функционирования на протяжении всего жизненного цикла.
Эффективность функционирования ИС, в частности, связок «БД-СУБД», включает
минимизацию потребляемых ресурсов, как на этапе эксплуатации, так и на этапе
разработки. Поэтому проблема оптимизации операций связок «БД-СУБД» обрела еще
большую актуальность на современном этапе «озеленения» вычислений и разработки ИТ.
 М3_2.2_ Зеленые базы данных и «оптимизация обработки» запросов 10
Концепция Green ГТ предполагает снижение энергозатрат при оптимальном использовании
имеющегося оборудования, такого как процессор, дисковые накопители и др., что достигается
благодаря снижению вычислительной сложности применяемых алгоритмов, оптимизации структур
данных и другими комплексами мероприятий.
Одной из типовых задач повышенной сложности, с которой сталкиваются архитекторы БД,
является задача хранения иерархических данных. Рассмотрены четыре метода построения
иерархических структур в реляционных БД :
1. Вложенное множестве (Nested Set) – это дерево, которое отражает подчинение элементов
одного уровня вложенности другому (упорядоченное по уровню вложенности).
2. Список смежных вершин (Adjacency List) – хранение информации о связях «наследник –
родитель» в виде специальной структуры данных со списком смежных вершин и уровнями этих
вершин.
3. «Замкнутые» таблицы (Closure Tables) – хранится полный перечень путей в дереве, возможно
хранение пути нулевой длины для связи узла с самим собой.
4. Материализованный путь (Materialized Path) – хранение информации о полном пути от корня
дерева к данному узлу в заранее подготовленном виде.
Для выбора метода, наилучшего с точки зрения концепции зеленых ИТ, исследованы эти методы
хранения иерархических данных. Процесс проектирования связки «БД-СУБД» состоит из 4-х этапов:
1. Системный анализ предметной области.
2. Построение инфологической (концептуальной) модели предметной области. Эта модель не
зависит от СУБД (от среды хранения данных), и представляется в терминах выбранной семантической
модели (одной из наиболее распространенных семантических моделей ER-модель (Entity Relationship)).
3. Построение логической модели. Выбирается модель данных и тип СУБД. Строится схема БД и
подсхемы для различных пользователей. Создается набор возможных типовых запросов. Определяются
спецификации для программного обеспечения (ПО).
4. Построение физической модели. Выбирается размещение БД на внешних носителях и
определяется используемая СУБД. Создается реальная БД. Программируются и отлаживаются
приложения, которые будут работать с БД.
 М3_2.2 Зеленые базы данных и «оптимизация обработки» запросов 11
В настоящее время основными являются следующие модели данных связок «БД- СУБД».
1. Иерархическая модель – набор ориентированных корневых деревьев. Каждая вершина дерева соответствует записи
(или упорядоченному набору записей) со встроенными указателями на непосредственного предка (кроме корня дерева)
и потомков вершины (кроме листьев). Поддерживает типы связей «один к одному» и «один ко многим». Модель
эффективна при выполнении запросов, формулируемых в терминах операций модификации двухсвязных списков.
2. Сетевая модель – набор ориентированных связных графов с рядом ограничений на их структуру. Расширение
возможностей по сравнению с предыдущей моделью состоит в том, что за счет двух встроенных связей «один ко
многим» поддерживается связь «многие ко многим». Модель эффективна при выполнении запросов, естественно
формулируемых в терминах любых операций над двухсвязными списками.
3. Реляционная модель – основана на понятии «отношение» –одном из основных понятий математики; набор двумерных
таблиц, строки которых имеют одинаковую структуру. Модель эффективна при выполнении запросов,
формулируемых в терминах операций над отношениями, эта модель де-факто является «промышленным стандартом».
4. Объектно-ориентированная модель – понятиями являються «объект» (имеющий уникальный идентификатор) и
«литерал». Объекты разбиваются на атомарные и структурированные, инкапсулируют свое состояние (определяемое
значениями набора свойств объекта) и поведение (т.е. операции, которые могут быть выполнены объектом или над
ним). Свойства объекта делятся на атрибуты (не являющиеся объектами и принимающими в качестве значения
литерал или идентификатор) и связи (представленные посредством ссылочных атрибутов). Объекты, имеющие
одинаковые атрибуты и отвечающие на одни и те же сообщения, образуют класс. Отношение наследования
(множественное) дает возможность определять один класс как частный случай другого класса ( других классов).
Таким образом, логическая структура этой модели - структура иерархической модели, но отсутствует ее стандарт.
5. Объектно-реляционная модель – расширение реляционной модели за счет поддержки основных концепций (кроме
наследования классов) объектно-ориентированного программирования [18]. В этой модели сняты ограничения
неделимости (атомарности) значений атрибутов в таблицах, допускаются поля, значениями которых являються
таблицы, встроенные в таблицы. Это дает возможность создавать типы даннях любой степени сложности.
Достоинством модели является возможность использовать существующие реляционные БД для вновь
разрабатываемых приложений. В настоящее время на практике при объектно-ориентированном подходе к
программированию используется именно объектно-реляционная модель.
6. Многомерная модель – обобщение реляционной модели, набор многомерных таблиц для аналитической обработки
больших объемов информации, связанной со временем (в частности, для решения задач прогнозирования). Основными
понятиями являются «измерение» и «ячейка». Измерение состоит в выделении множества однотипных данных,
соответствующих грани многомерной таблицы. Ячейка – это поле, значение которого определяется фиксированным
набором измерений. В модели реализованы специальные операции «срез», «вращение», «агрегация» и «детализация»,
дающие возможность осуществлять анализ информации на различных уровнях ее обобщения.
 М3_2.2 Зеленые базы данных и «оптимизация обработки» запросов 12
Типы связок «БД–СУБД» с позиции физической модели разделяют на следующие классы.
1.По среде размещения связка «БД-СУБД» является:
1) локальной (сосредоточенной), если она реализована на одном компьютере;
2) распределенной, если она реализована в компьютерной сети.
2. По способу доступа связка «БД-СУБД» является:
1) мейнфреймовой, если рабочее место – это текстовый или графический терминал, а вся
информация обрабатывается на сервере, т.е. компьютере или компьютерах, где хранится связка;
2) файл-серверной, если она размещена на сервере, доступ к данным и прикладным программам
осуществляется через локальную сеть, а ядро СУБД реализовано на каждом клиентском компьютере;
3) клиент-серверной, если она размещена на сервере, доступ к данным через локальную сеть, а
клиентская часть СУБД и прикладные программы реализованы на клиентских компьютерах;
4) встраиваемой, если она является программной библиотекой, т.е. на локальных компьютерах
организовано унифицированное хранение больших объемов данных, а доступ к ним происходит
посредством запросов или вызовом функций библиотеки из приложения пользователя.
3. По подходу к организации вычислений связка «БД-СУБД» является:
1) классической (фон-неймановской) – при обработке запросов используется только классический
(т.е. последовательный) подход к организации вычислений;
2) нео-классической – при обработке запросов параллельные и/или распределенные вычисления.
В реальной связке «БД-СУБД» время обработки любого запроса состоит из (1) времени,
затраченного на операцию загрузки данных с медленного носителя в оперативную память, (2) времени,
затраченного на вычисление, и (3) времени, затраченного на возвращение результата в
соответствующий медленный носитель. Выделяются следующие два подхода к анализу
эффективности обработки запросов в связке «БД-СУБД».Первый подход основан на
использовании симбиоза математической логики, теории моделей и прикладной теории
алгоритмов. Предметом исследования является математическая модель связки «БД-СУБД». Цель
состоит в построении нижних оценок асимптотической временной сложности функционирования
связки «в наихудшем случае» или «в среднем».Второй подход основан исследовании реальной
связки «БД-СУБД». Он осуществляется методами статистического анализа. Цель состоит в оценке
реального времени обработки запросов (возможно, модельными) реализациями связки при тех или
иных условиях.
 М3_2.2 Зеленые базы данных и «оптимизация обработки» запросов 13
«Оптимизация обработки» запросов представляет собой нетривиальную многокритериальную задачу.
Методы «оптимизации обработки» запросов привели к пониманию необходимости разработки полномасштабного
унифицированного подхода к решению этой задачи, основанного на нисходящем подходе (top-down approach).
Сформировались следующие три направления исследования задачи «оптимизация обработки» запросов.
1. Разработка методов «оптимизации обработки» последовательности запросов. Это попытка снижения стоимости
обработки запроса за счет использования в последовательности составных запросов содержания значительного
количества общих подвыражений.
Первые методы «оптимизации обработки» последовательности запросов были основаны на исчерпывающемся
поиске. Эти методы использовали дважды экспоненциальную память от размера запроса и являлись
неэффективными на практике.
Эффективным была разработка методов «оптимизации обработки» последовательности запросов, основанных на
использовании представления запросов ориентированными ациклическими И-ИЛИ графами (AND-OR DAG
representation). Некоторые из них представляют собой прототипы методов, реализованных в 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;
8) индексируйте соединенные столбцы, что существенно уменьшит (на несколько порядков) время выполнения
соединения таблиц;
9) используйте преимущества покрывающих индексов, т.е. содержащих все столбцы, указанные в операторах
SELECT, UPDATE или DELETE, что уменьшает время выполнения этих операций до тех пор, пока суммарная длина
всех входящих в индекс столбцов значительно меньше, чем длина строки таблицы.
 М3_2.2_ Зеленые базы данных и «оптимизация обработки» запросов 14
2. Разработка методов лексической и семантической «оптимизации» запросов. Лексическая
«оптимизация» запроса состоит в его преобразовании, направленном на устранение избыточности на основе
анализа ограничений и условий, содержащихся в нем. Существуют следующие два подхода к решению этой задачи.
1 Преобразование запроса, представленного на нереляционном языке (при необходимости и данных), к
реляционной форме, и применение к ней методов лексической «оптимизации», разработанных для реляционных
СУБД .
2 Построение новых алгебр, предназначенных для представления запросов с учетом особенностей новых
языков, и разработка методов «оптимизации» выражений этих алгебр.
Семантическая «оптимизация» запроса представляет собой валидацию и преобразование синтаксического
дерева запроса к виду, пригодному для выполнения дальнейших шагов оптимизации. При этом преобразование
запросов в каноническую форму (т.е. раскрытие представлений, преобразование подзапросов в соединения, спуск
предикатов), упрощение условий, распределение предикатов и преобразование дерева условий в пути выборки .
3. Разработка методов «оптимизации обработки» запросов в параллельной распределенной связке «БД-
СУБД». Именно эти исследования определили следующие три направления исследований, наиболее интенсивно
развивающиеся в настоящее время.
Во-первых, это разработка детерминированных и вероятностных методов «оптимизации» запросов для
различных моделей параллельныхраспределенных связок «БД-СУБД» С ростом числа процессоров сначала время
убывает благодаря распараллеливанию обработки запроса, а затем возрастает из-за перегрузки системы
ввода/вывода, которая является разделяемым ресурсом.
Во-вторых, это построение моделей связок «БД-СУБД» на основе использования графических процессоров
(GPU) . Модель программирования GPU описывает 6 типов областей памяти, различных по скорости доступа, прав
на запись-чтение, объему. Это существенно снижает различие между временем загрузки данных с медленного
носителя в оперативную память и временем, затрачиваемым на исполнения запроса и возвращения результата.
В-третьих, это разработка моделей и методов обработки и хранения больших данных. Под термином «большие
данные» понимают электронные данные, характеризующиеся большим объемом, разнообразием и скоростью, с
которой структурированные и неструктурированные данные поступают по сетям передачи в процессоры и
хранилища, наличием эффективных процессов переработки данных в требуемую информацию [88]. Типичными
примерами больших данных являются системы компьютерной поддержки функционирования ведущих фондовых
бирж мира, социальная сеть Facebook, проект Internet Archive, системы компьютерной поддержки уникальных
экспериментальных установок исследования процессов микромира, таких, как Большой андронный коллайдер.
 М3_2.3Экосистема данных Системы хранения данных (СХД) -Hitachi VSP 5000 15
Среди СХД, как и среди многих высокотехнологических продуктов, есть упрощенные варианты,
«рабочие лошадки» и изделия класса Hi-End, сочетающие сверхвысокую надежность и максимальные
функциональные возможности. Hitachi Virtual Storage Platform (VSP) серии 5000, безусловно,
относятся ко второму классу, поскольку производитель дает гарантию 100% надежности. Показатели
производительности очень высоки – миллионы операций в секунду.
Возможности VSP 5000
Надежность, устойчивость к отказам
Надежность — самый важный показатель работы корпоративной СХД для очень многих
представителей финансовой, транспортной, энергетической и многих других сфер, где работает
крупный бизнес.
СХД серии VSP 5000 – это устройства, обеспечивающие 100% надежность, доступность данных.
Достигается это, в первую очередь, за счет избыточности всех устройств, применения компонентов и
инженерных решений с максимально возможной степенью надежности. Это позволяет производителю
не
: только заявить о доступности класса «шесть девяток», но и дать финансовые гарантии 100%
доступности данных.
Удобное управление и искусственный интеллект
Управление самыми сложными и высокотехнологичными системами должно быть удобным,
понятным и умным.
Управляющий центр для СХД Hitachi Ops Center имеет интуитивно-понятный графический
интерфейс. С его помощью можно быстро настроить, а потом легко управлять СХД. API-интерфейсы,
выполненные по архитектуре REST, позволяют интегрировать устройство с разными наборами
инструментов и шаблонами автоматизации. Все вместе это упрощает развертывание, мониторинг и
перенастройку ресурсов хранения, обеспечивает централизацию административных операций.
Использование искусственного интеллекта снижает количество задач по управления хранилищем,
возникает экономия человеко-часов, что существенно сократить количество ручных этапов
управления хранилищем
 М3_2.3 Экосистема данных Системы хранения данных (СХД) -Hitachi VSP 5000 16

СХД Hitachi VSP 5000 построена на NVMe и твердотельных накопителях с интерфейсом SAS.
Скорость работы устройств этой серии значительно выше, чем у решений этого класса других
вендоров: обеспечивается до 21 миллиона операций ввода/вывода в секунду и задержка до 70
микросекунд. Это стало возможно не только благодаря использованию исключительно флеш-
технологий, но и операционной системе Hitachi Storage Virtualization RF (SVOS RF), уменьшающей
нагрузку ввода/вывода при горизонтальном масштабировании платформы данных.
Можно снизить расходы.
Операционная система SVOS RF не только уменьшает нагрузку при масштабировании. Она
работает по технологии адаптивного сокращения данных (Adaptive Data Reduce, ADR). Это позволяет
лучше использовать хранилища – снижать объем занимаемой памяти, а значит и затраты на управление
данными. И дает возможность сэкономить не только при покупке мощности, но и на потреблении
арендуемой площади, коммунальных платежах и сопутствующих расходах.
Единое пространство для любых нагрузок — гибкость хранения. В любом крупном бизнесе
сегодня используют множество разных приложений, работающих под различной нагрузкой и,
соответственно, с разными потребностями в ресурсах. Для их поддержки нужна гибкая, управляемая
данными цифровая инфраструктура хранения данных, готовая к масштабированию и поддержке любой
рабочей нагрузки. Решить эту проблему можно внедрив единую систему, способную консолидировать
несколько рабочих нагрузок любого типа – от традиционных проприетарных приложений (Oracle, SAP,
Microsoft и др.) до современных контейнерных систем, на базе свободного ПО, а также мейнфреймов.
Функционал и технические характеристики VSP 5000
СХД VSP 5000 обеспечивают виртуализацию систем хранения, репликацию данных, управление
копированием, аналитику инфраструктуры, миграцию без прерывания работы устройств. Все
модификации имеют гарантии 100% доступности данных. Серия VSP 5000 построена на модульной
архитектуре и включает две основных модификации – VSP 5100 (младшего уровня) и VSP 5500
(старшего уровня), у каждой есть гибридный вариант – VSP 5100H и VSP5500H.
 М3_2.3 Экосистема данных Системы хранения данных (СХД) -HitachiVSP E990 17
Мост от среднего к крупному: как выбрать СХД для растущего бизнеса VSP E990 завершает линейку
СХД среднего класса от Hitachi. Это полностью твердотельная, с энергонезависимой памятью
платформа хранения данных (all-flash NVMe), предназначенная для приложений, требующих
высокой и предсказуемой производительности, чувствительных к задержке. Данная СХД
ориентирована на предприятия «мостового диапазона», предприятия, которые в результате
естественного роста бизнеса, оказались на стадии перехода от среднего бизнеса к крупному.
Функциональные возможности. VSP E990 обеспечивает широкие функциональные возможности, а
именно:
1) 100% доступность данных;
2) гарантированно высокую производительность, доступность и масштабируемость данных, что дает
надежную платформу для цифровой трансформации;
3) сокращение затрат на хранение данных;
4) ускорение предоставления приложений пользователям до 90%;
5) анализ показателей телеметрии на всем пути передачи данных, от виртуальной машины до общих
ресурсов хранения, что, в свою очередь, обеспечивает ускоренный поиск и устранение
неисправностей;
6) снижение количества выполняемых вручную задач, что позволяет ИТ-специалистам уделять
меньше времени техническому обслуживанию и больше – стратегическим вопросам развития
экосистемы данных на предприятии;
7) облачная модель потребления, позволяющая сократить затраты на ресурсы;
8) возможность выбора предоставляемых услуг, что дает снижение эксплуатационных расходов;
9) предсказуемость результатов, что позволяет оптимизировать затраты в соответствии с фактическим
использованием ресурсов.
Высокопроизводительный полностью твердотельный (all-flash NVMe) массив VSP E990 предназначен
для обслуживания критически важных рабочих нагрузок внутри системы хранения данных, не
требующей поддержки традиционных жестких дисков (HDD).
 М3_2.3 Экосистема данных 17
Мост от среднего к крупному: как выбрать СХД для растущего бизнеса VSP E990 завершает линейку
СХД среднего класса от Hitachi. Это полностью твердотельная, с энергонезависимой памятью
платформа хранения данных (all-flash NVMe), предназначенная для приложений, требующих
высокой и предсказуемой производительности, чувствительных к задержке. Данная СХД
ориентирована на предприятия «мостового диапазона», предприятия, которые в результате
естественного роста бизнеса, оказались на стадии перехода от среднего бизнеса к крупному.
Функциональные возможности. VSP E990 обеспечивает широкие функциональные возможности, а
именно:
1) 100% доступность данных;
2) гарантированно высокую производительность, доступность и масштабируемость данных, что дает
надежную платформу для цифровой трансформации;
3) сокращение затрат на хранение данных;
4) ускорение предоставления приложений пользователям до 90%;
5) анализ показателей телеметрии на всем пути передачи данных, от виртуальной машины до общих
ресурсов хранения, что, в свою очередь, обеспечивает ускоренный поиск и устранение
неисправностей;
6) снижение количества выполняемых вручную задач, что позволяет ИТ-специалистам уделять
меньше времени техническому обслуживанию и больше – стратегическим вопросам развития
экосистемы данных на предприятии;
7) облачная модель потребления, позволяющая сократить затраты на ресурсы;
8) возможность выбора предоставляемых услуг, что дает снижение эксплуатационных расходов;
9) предсказуемость результатов, что позволяет оптимизировать затраты в соответствии с фактическим
использованием ресурсов.
Высокопроизводительный полностью твердотельный (all-flash NVMe) массив VSP E990 предназначен
для обслуживания критически важных рабочих нагрузок внутри системы хранения данных, не
требующей поддержки традиционных жестких дисков (HDD).
 М3_2.3 Экосистема данных_гибридное облако 18

Основа гибридного облака – единый инструмент централизованного управления вычислительными

ресурсами и ресурсами хранения данных. При этом управление ведётся в разрезе сервисов, а сами
ресурсы располагаются как в собственном ЦОД предприятия, так и у публичных провайдеров.
Типовые случаи использования гибридной модели: Вы – продуктовая компания и регулярно
выпускаете релизы своих приложений. Соответственно, вам периодически нужно проводить
функциональное, интеграционное и нагрузочное тестирование, которое требует дополнительных
вычислительных мощностей на короткий срок .
У вас B2C онлайн-сервис, и вы хотите подготовиться к росту количества пользователей. Как и в
первом кейсе, приобретать новое «железо», чтобы обеспечить стабильную работу онлайн-площадки в
период пиковых нагрузок, – экономически необоснованно. Автоматическое масштабирование ресурсов
в облаке решит задачу, сохранив лояльность ваших клиентов. Вам нужна резервная площадка для
обеспечения катастрофоусточивости ваших сервисов.
Вы стремитесь оказывать качественный сервис по всему миру в соответствии с местным
законодательством. В этом случае вам приходится выносить часть своих данных и информационных
систем ближе к региональным точкам обмена трафиком .
Затраты на создание гибридной модели с единым управлением и каталогом сервисов можно
компенсировать за счёт её же преимуществ:
автоматизация процесса поможет системным администраторам и разработчикам в пару кликов или
автоматически через программный интерфейс перемещать нагрузку между дата-центрами и облаками,
ИТ-директору – повысить эффективность использования инфраструктуры (как частной, так и
публичной) на основе данных о её потреблении различными командами в режиме реального времени.