Реализация параллельной обработки данных в облачных системах Текст научной статьи по специальности «Компьютерные и информационные науки»

Параллельное и распределенное программирование, грид-технологии, программирование на графических процессорах

УДК 004.272.3

Мунерман В.И.

Смоленский государственный! университет, г. Смоленск, Россия

РЕАЛИЗАЦИЯ ПАРАЛЛЕЛЬНОЙ ОБРАБОТКИ ДАННЫХ В ОБЛАЧНЫХ СИСТЕМАХ

Аннотация

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

Ключевые слова

Облачные системы и вычисления; параллельная обработка данных; массовая обработка данных; архитектура программно-аппаратных комплексов; методы доступа.

Munerman V.I.

Smolensk State University, Smolensk, Russia

THE IMPLEMENTATION OF PARALLEL DATA PROCESSING IN CLOUD SYSTEMS

Abstract

The methods of using cloud computing technology for the development of software that implements parallel processing of distributed data are considered. The method of parallel implementation of the JOIN operation based on the symmetric horizontal distribution principle is considered. There are descriptions of virtual software and hardware systems that implement parallelization at the level of processing requests and at the level of the JOIN operation using Microsoft Azure. Experimental data confirming the effectiveness of the proposed approach are presented.

Keywords

Cloud systems and computing; parallel data processing; massively data processing; softwarehardware complexes architecture; data access methods.

Введение

Статья посвящена рассмотрению методов использования технологии облачных вычислении для разработки программного обеспечения, реализующего параллельную обработку распределенных данных. Она представляет собои развитие методов, предложенных в работе [1].

Облачные вычисления определяются как вычислительные концепции, которые

подразумевают большое количество компьютеров, подключенных через сеть реального времени, подобную Интернет. Как и грид- системы [6] облачные системы служат основой для

распределенных вычислении по сети, а значит, дают возможность запуска программы или приложения на многих подключенных компьютерах одновременно. Облачные

вычисления основаны на данных, приложениях, инфраструктуре и различных платформах для разработчиков приложении, расположенных в глобальной сети (WAN).

Цель работы заключается в исследовании возможности применения облачных технологии для параллельной обработки больших структурированных данных посредством распределения этих данных между большим

количеством вычислителей!.

Анализ ресурсов облачных систем

Облачные системы предоставляют

программисту большои набор инструментальных средств разработки приложении. Они объединены в подсистему, которая называется Платформа как сервис (Platform as a Service - PaaS). PaaS - это предоставление облачных вычислении, при котором потребитель получает доступ к использованию таких технологических платформ, как: операционные системы, системы управления базами данных, связующее программное обеспечение, средства разработки и тестирования приложении, размещенных в облачнои системе [2]. Далее рассматриваются методы и ресурсы, необходимые для параллельной обработки распределенных данных, которые обеспечивает разработчикам PaaS облачнои системы Windows Azure.

Первьш основнои ресурс - это виртуальная машина. Виртуальная машина конструируется пользователем в соответствии с его требованиями. Минимальные возможности - это одноядерный процессор с 768 Мбайтами памяти, а наиболее мощныи вариант - восьмиядерныи процессор с 56 Гбаитами памяти. На виртуальной машине устанавливается операционная система Windows Server. Если виртуальная машина используется для работы с базами данных, то на неи также устанавливается СУБД Microsoft SQL Server Azure. Версия и настроика программного обеспечения определяется мощностью машины.

Второи основнои ресурс - это отдельная база данных. Программисту предоставляется возможность создания необходимого количества баз данных на облачных ресурсах. Эти БД могут быть физически независимыми друг от друга, то есть располагаться на различных облачных хранилищах данных и обрабатываться различными облачными процессорами. Для создания БД и выполнения запросов к неи используется СУБД Microsoft SQL Server Azure.

Третии ресурс, который может быть использован для решения вспомогательных задач параллельной обработки распределенных данных, - хранилище таблиц. К таблицам можно применять только простые запросы, не содержащие бинарных операции типа операции соединения. Таблицы могут использоваться как индексные фаилы при индексно-

последовательнои организации данных.

Далее рассматриваются методы

взаимодействия прикладных программ с этими основными ресурсами. При этом предполагается, что:

• организация данных реализована на основе принципа симметричного горизонтального распределения;

• программа реализует параллельное выполнение независимых потоков,

которые вместе реализуют массовую обработку данных.

Общая схема взаимодействия прикладной программы с основными облачными ресурсами показана на рисунке 1.

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

Рис. 1. Взаимодействие между прикладной программой и облачными ресурсами

Обработка данных, расположенных в облаке, может быть реализована различными способами.

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

Пример 1. Пусть даны две таблицы с одинаковыми схемами: P(A, B] и Q(A, B], и таблица R(A, С]. Эти таблицы участвуют в запросе, в котором сначала выполняется операция объединения таблиц P и Q, а затем операция JOIN над результатом объединения и таблицей R. Этот запрос имеет вид:

SELECT R.A, PUQ.B, R.C FROM R INNER JOIN PUQ ON R.A =PUQ.A;

PUQ - запрос на объединение таблиц P и Q:

SELECT P.A, P.B FROM P UNION SELECT Q.A, Q.B FROM Q;

Этот запрос может быть преобразован в эквивалентный запрос:

SELECT R.A, P.B, R.C FROM R INNER JOIN P ON R.A =

P.A

UNION

SELECT R.A, Q.B, R.C FROM R INNER JOIN Q ON R.A = Q.A;

(операции JOIN и UNION подчиняются закону дистрибутивности].

Схема взаимодействия прикладной программы с распределенными между двумя БД в облаке данными и запросами приведена на рисунке 2.

Прикладная программа может располагаться как на виртуальнои машине в облаке, так и на

компьютере пользователя. В обоих случаях связь прикладной программы с базами данных осуществляется по глобальной сети. Эта связь может быть реализована в модели ODBC. В первои БД выполняется операция JOIN над таблицами P и R, которые могут располагаться как в этои БД, так и в других. Во второи БД выполняется операция JOIN над таблицами Q и R, которые также могут располагаться как в этои! БД, так и в других._

Приложение Базы данных фрагментов

Основная процедура Поток 1 DB 1 Таблицы pia, в) r (а, с)

Запрос J!=PINNER JOIN r

Сеть

Поток п DB; Таблицы q(a, в) r (a, с)

Запрос J2=Q inner join r

DBr Запрос Ji UNION J2

Рис. 2. Взаимодействие прикладной программы с БД в облаке

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

Второй способ основан на параллельной реализации операции, которые составляют запрос. Далее рассматривается использование облачнои технологии для параллельной реализации операции JOIN. Эта операция выбрана потому, что она имеет более высокую вычислительную сложность, чем остальные операции, определенные в моделях данных. Для параллельной реализации выбрана следующая разновидность операции JOIN:

P INNER JOIN Q ON n(PK, Q.K);

Таблицы P и Q имеют разные схемы, в каждую из которых входит простой или составной ключ K. Предикат п определен на множествах экземпляров ключа K в таблицах P и Q . Далее, для простоты, но без нарушения общности, предполагается, что в операции JOIN используется наиболее естественный предикат п: P.K = Q .K .

Построение параллельной реализации операции JOIN

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

Основнои агрегат данных в теоретико-множественной модели - фаил, который определяется как фактор-множество множества однотипных записеи X по отношению эквивалентности, порожденному множеством K, и обозначается - XK.

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

В общем случае, при выполнении операции JOIN предикат п определен на множестве McK. Тогда фаилы нестрого упорядочены, а таблицы, им соответствующие, будут в первои нормальной форме. В этом случае таблицы как и фаилы состоят из классов эквивалентности, в которых все строки содержат один и тот же экземпляр составного ключа K. Тогда для параллельной реализации операции JOIN можно использовать метаданные, определяющие распределение строк таблицы по классам эквивалентности. Такои подход называется индексно-последовательным и основан на одноименном методе доступа - ISAM.

Для распределения пар классов эквивалентности между базами данных можно использовать известный алгоритм упаковки рюкзака и эвристический алгоритм бустрофедона [4], названный так по аналогии с одним из древних методов письма. Второи алгоритм для N баз данных состоит из следующих шагов.

1. Из таблиц P и Q формируется сводная индексная таблица Comlnd, упорядоченная по убыванию значении поля MM.

2. Первые N пар классов эквивалентности таблиц P и Q, которые отмечены в первых N строках таблицы Comlnd, последовательно добавляются в таблицы-фрагменты Pi и Qi баз данных DB,- (/=1, ..., N).

3. Последние N пар классов эквивалентности таблиц P и Q, которые отмечены в последних N строках таблицы Comlnd, в обратном порядке (i=N, ..., 1) последовательно добавляются в таблицы-фрагменты Р/ и Q/ баз данных DB/.

4. Прямои (обратным) счетчик строк таблицы Comlnd увеличивается (уменьшается) на N.

5. Пункты 2-4 повторяются до тех пор, пока не будет исчерпана таблица Comlnd.

В [4] проведен совместный анализ алгоритма упаковки рюкзака и алгоритма бустрофедона. Анализ показал, что с увеличением N:

1. Результаты работы алгоритмов сближаются. Это позволяет отдать предпочтение более быстрому (полиномиальному) алгоритму бустрофедона.

2. Величина Rmax- Rmin возрастает. При этом уменьшается количество пар классов эквивалентности, которые размещаются в таблицах-фрагментах Р/ и Q/ баз данных DB,-(/=1, ..., N). В предельном случае, когда число пар классов равно количеству вычислителей, время выполнения операции JOIN близко к времени декартова произведения пары классов эквивалентности, соответствующих величине Rmax.

Далее показано, как симметричное горизонтальное распределение таблиц может быть реализовано исключительно средствами СУБД.

Пусть Ki, ..., Kn - множество значении ключа K. Таблицы P(K, ...) и Q(K, ...) имеют схемы, которые содержат ключ K и произвольные наборы полеи (как правило, различные). Таблице P можно поставить в соответствие индексную таблицу со схемои indP(K, I, M). Эта таблица - есть множество строк indP={< Kl ,it ,mt >, ..., <Km,im,mm> } . j -индекс первои записи класса эквивалентности, строки которого содержат экземпляр Kj ключа K, mj - количество записей в этом классе эквивалентности. Поле I имеет тип Счетчик строк, а поле М - целочисленное. Таблица indP может быть получена в результате двух запросов:

1. Q1=INSERT INTO indPt ( K, M ) SELECT P.K, 1 AS M FROM P ORDER BY P.K;

2. Q2=SELECT indPt.K, First(indPt.M) AS I, Sum(IndPt.M) AS M INTO indP FROM indPt GROUP BY indPt.K ORDER BY indPt.K;

Запрос Q1 формирует промежуточную таблицу, которая содержит столько же строк, что и таблица

P. Каждая строка этои таблицы содержит свои номер, значение ключа K из соответствующей строки таблицы P и поле M, содержащее значение 1. Запрос Q2 завершает построение таблицы indP посредством операции группировки. Этому двухпроходному алгоритму соответствует простои однопроходный алгоритм, которьш легко разработать на любом языке программирования, связанным с СУБД, или на языках манипулирования данными, такими как Tranzact-SQL или PL-SQL. Листинг 1 демонстрирует реализацию однопроходного алгоритма построения индексного файла для индексно-последовательного доступа к таблице P.

Этому двухпроходному алгоритму

соответствует простои однопроходный алгоритм, которыи легко разработать на любом языке программирования, связанном с СУБД, или на языках манипулирования данными, такими как Tranzact-SQL или PL-SQL. Листинг 1 демонстрирует реализацию однопроходного алгоритма построения индексного фаила для индексно-последовательного доступа к таблице P.

Листинг 1. Построение индексного файла средствами языка Tranzact-SQL

1. DECLARE @K <тип>, @currentK <тип>, @I int, @M int, @RowCount int

2. DECLARE @j int

3. DELETE FROM indP

4. DECLARE cursorP CURSOR FOR SELECT K FROM P ORDER BY K

5. OPEN cursorP

6. SET @RowCount =@@Cursor_Rows

7. SET @j=0

8. FETCH NEXT FROM cursorP INTO @K

9. SET @currentK =@K

10. SET @I=1

11. SET @M=1

12. WHILE @j<@ RowCount-1

13. BEGIN

14. FETCH NEXT FROM cursorP INTO @K

15. IF @currentK =@K

16. SET @M=@M+1

17. ELSE

18. BEGIN

19. INSERT INTO indP (K, I, M) VALUES (@currentK, @I, @M)

20. SET @currentK =@K

21. SET @I=@I+@M

22. SET @M=1

23. END

24. SET @j=@j+1

25. END

26. INSERT INTO indP (K, I, M) VALUES (@currentK, @I, @M)

Подготовительная часть алгоритма (строки 811) формирует заготовку первои строки таблицы indP. Эта строка содержит первое по порядку значение ключа K. Основная часть алгоритма заключена в теле цикла (строки 13-25). Здесь при

совпадении значения ключа K в очередной! строке таблицы P и в заготовке текущей строки таблицы indP накапливается значение поля M, в противном случае производится вывод текущей строки в таблицу indP и формируется заготовка новои строки этои таблицы. По завершении цикла последняя сформированная строка выводится в таблицу indP (строка 26).

Таблица indQ для таблицы Q может быть получена аналогично.

Очевидно, что таблица-результат операции JOIN будет содержать только те классы эквивалентности, которые принадлежат пересечению индексных таблиц indPnindQ. Запрос, в результате которого получается это пересечение, имеет вид:

SELECT indP.M*indQ.M AS MM, indP.K, indP.l, indQ.l, indP.M, indQ.M

INTO Comlnd FROM indP, indQ WHERE indP.K = indB.K ORDER BY indP.M*indQ.M

Результат запроса - таблица Comlnd. Она содержит составной ключ К, поля I и M обеих индексных таблиц, а также поле MM, по которому она упорядочена. Поле MM вычисляется как произведение количества строк в обоих классах эквивалентности, строки которых содержат одно и то же значение составного ключа K. Его значение определяет число выходных строк, которое получится в результате обработки этих классов эквивалентности операцией JOIN.

Использование таблицы Comlnd позволяет распределить таблицы P и Q между несколькими независимыми базами данных. Если имеется N таких баз данных, то эти таблицы разделяются на строки в таблицу indP фрагментов. Каждая база данных DBSnpi (i=1, ..., N) содержит пару фрагментов <P, Qi > таблиц P и Q. При этом классы эквивалентности, записи которых содержат одинаковые значения составного ключа K, полностью расположены в одном и только одном фрагменте. Такои способ распределения таблиц соответствует принципу симметричного горизонтального распределения данных. Таблица Comlnd соответствует фаилу indD. Алгоритм бустрофедона, реализующий симметричное горизонтальное распределение таблиц P и Q также может быть реализован средствами языка Tranzact-SQL так, как это показано в листинге 2.

Листинг 2. Реализация симметричного горизонтального распределения средствами языка Tranzact-SQL

1. DECLARE @KA <тип>, @KD <тип>, @RowCount int, @i int ORDER BY MM ASC

2. DECLARE cursorDSC CURSOR FOR SELECT K, MM FROM Comlnd ORDER BY MM DESC

3. OPEN cursorASC

4. OPEN cursorDSC

5. SET @ RowCount =@@Cursor_Rows

6. IF @ RowCount %2=0

7. SET @RowCount =@RowCount /2

8. ELSE

9. SET @RowCount =@RowCount /2+1

10. SET @i=0

11. WHILE @i<@RowCount

12. BEGIN

13. FETCH NEXT FROM cursorASC INTO @ KA

14. FETCH NEXT FROM cursorDSC INTO @ KD

15. IF @i % N=0

16. BEGIN

17. INSERT INTO PSnpl SELECT * FROM P WHERE K=@KA

18. INSERT INTO PSnpl SELECT * FROM P WHERE K=@KD

19. INSERT INTO RSnpl SELECT * FROM R WHERE K=@KA

20. INSERT INTO RSnpl SELECT * FROM R WHERE K=@KD

21. END

22. ...

23. IF @i % N=N-1

24. BEGIN

25. INSERT INTO PSnpN SELECT * FROM P WHERE K=@KA

26. INSERT INTO PSnpN SELECT * FROM P WHERE K=@KD

27. INSERT INTO RSnpN SELECT * FROM R WHERE K=@KA

28. INSERT INTO RSnpN SELECT * FROM R WHERE K=@KD

29. END

30. SET @/=@/+1

31. END

Средства языка Tranzact-SQL позволяют существенно использовать в процедуре, реализующей алгоритм бустрофедона,

упорядоченность таблиц, что отличает его от языка SQL, отражающего свойства классической реляционной модели. Поэтому строки таблицы Comlnd могут быть прочитаны двумя запросами по возрастанию и по убыванию значении поля MM (строки 2, 3). Это позволяет соединить наибольшее и наименьшее значения этого поля. В зависимости от того, четно или нечетно число строк в таблице Comlnd, определяется количество обрабатываемых строк (строки 7-10), поскольку считывание таблицы двумя запросами с противоположным упорядочиванием позволяет читать только половину таблицы (плюс одна строка, если число строк нечетно). В теле основного цикла (строки 14-31) формируются фрагменты таблиц P и Q. Как и в случае фаиловои модели, после выполнения этого варианта алгоритма бустрофедона, количества строк таблицы-результата,

получаемые в результате операции JOIN над фрагментами P/ и R/ таблиц P и R, будут минимально отличаться друг от друга.

Важное значение при реализации симметричного горизонтального распределения

таблиц имеет тот факт, что сами таблицы могут располагаться в БД на различных серверах, а их перемещение между серверами осуществляется автоматически с использованием оператора SELECT ... INTO ... с указанием сервера, на котором находится БД, содержащая таблицу-операнд.

После завершения симметричного

горизонтального распределения таблиц P и Q по базам данных DBSnpi над содержащимися в этих базах данных парами фрагментов таблиц Pi и Qi выполняются операции JOIN, по завершении которых полученные фрагменты таблицы результата сливаются в одну таблицу.

Пусть база данных DB,- содержит фрагменты Pi и Qi, каждыи из которых содержит pi пар классов эквивалентности таблиц P и Q. Операция Pi INNER JOIN Qi создаст таблицу, которая будет содержать Pi

R = ^ MM. строк. Очевидно, что чем меньше

j=i 1

значение разности Rmax -Rmin, тем более эффективно распараллеливание операции JOIN.

Симметричное горизонтальное распределение таблиц P и Q между N базами данных фактически приводит к построению виртуального программно-аппаратного комплекса с MPP архитектурой который располагается в облачнои системе. Структура такого комплекса приведена на рисунке 3.

Приложение

Основная процедура

Процедура Бустрофедон

Основная * БД

Таблицы

Запросы/ хранимые процедуры

Р, Q, Comlnd

01. 02, CreateComlnd и/или хранимая процедура распределения таблиц

Фрагменты:

БД,

Таблицы

Запросы/ хранимые процедуры

Pi, Qi

Загрузка фрагментов таблиц и

Pi INNER JOIN Qi

БДм

Таблицы

Запросы/ хранимые процедуры

Рн, Ом

Загрузка фрагментов таблиц и

PN INNER JOIN QM

Рис.3. Структура виртуального программно-аппаратного комплекса для массовой обработки данных

Анализ параллельной реализации операции Join

Для оценки качества распараллеливания операции JOIN был проведен вычислительный эксперимент. Виртуальный комплекс был построен на основе Windows Azure - платформы Microsoft, разработанной для реализации облачных вычислений В состав комплекса входили пять независимых баз данных, расположенных на различных и географически удаленных друг от друга серверах. Из них четыре использовались для симметричного

горизонтального распределения таблиц. Результаты эксперимента приведены на рисунке 4.

Эксперимент проводился для таблиц P и Q, число строк в которых изменялось от 400000 до 2500000. Распределение таблиц производилось

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

700

600

500

; 400

i 300

200

100

Tt <£> S. СО О

w П í UÍ

сч сч сч сч

Объем каждой таблицы (тыс. строк)

-Последовательно--2 параллельных БД — '4 параллельных БД

Рис.4. Сравнительный анализ времени

последовательного и параллельного выполнения операции JOIN

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

Заключение

Таким образом, из сказанного можно сделать следующие выводы:

1) предложенные в статье методы параллельнои реализации обработки данных на уровне операции позволяют получить существенное ускорение;

2) реализация этих методов не требует использования сложных и достаточно дорогостоящих аппаратных средств, таких как машины баз данных, подобные IBM Netezza и Oracle Exadata;

3) эти методы не зависят от сложности и свойств СУБД, в минимальном варианте достаточно, чтобы СУБД поддерживала язык манипулирования данными SQL и была связана с системой программирования, обеспечивающей разработку параллельных программ;

4) разработка программного обеспечения параллельнои обработки данных на основе

симметричного горизонтального

распределения достаточно проста и может быть реализована с использованием простых и даже непроцедурных языков манипулирования данными.

Благодарности

Результаты, приведенные в статье, были получены при поддержке корпорации Microsoft в

рамках гранта на использование ресурсов облачнои системы Windows Azure, благодаря которому эти результаты получили экспериментальное подтверждение.

Автор выражает благодарность доктору технических наук профессору И.Н. Синицыну за неоценимую поддержку и помощь, которая была им оказана в ходе работы над приведенными в статье результатами.

Литература

1. Munerman V.I. The experience of massive data processing in the cloud using Windows Azure (as an example). - Moscow: Highly available systems, 2, Vol. 10, 2014. - P. 3-8.

2. Redkar T., Guidici T. Windows Azure Platform, 2nd Edition. - APRESS, 2011. - P. 602.

3. Мунерман В.И. Объектно-ориентированная модель массовои обработки данных // Системы высокои доступности. - 2011. Том 7, № 4. - С. 72-74.

4. Мунерман В.И. Модели обработки больших объемов данных в системах массового параллелизма // Системы высокои доступности. - 2013. Том 9, № 1. - С. 35-43.

5. Посыпкин М.А., Сухомлин В.А., Храпов Н.П. Комбинированные распределенные инфраструктуры в науке и образовании // Современные информационные технологии и ИТ-образование. - 2015. Том 1, № 11. - 31-36.

6. Посыпкин М.А. Грид-систем из персональных компьютеров в России: текущее состояние и перспективы // Современные информационные технологии и ИТ-образование. - 2012. - № 8. - С. 951-957.

References

1. Munerman V.I. The experience of massive data processing in the cloud using Windows Azure (as an example). - Moscow: Highly available systems, 2, Vol. 10, 2014. - P. 3-8.

2. Redkar T., Guidici T. Windows Azure Platform, 2nd Edition. - APRESS, 2011. - P. 602.

3. Munerman V.I. Ob#ektno-orientirovannaja model' massovoj obrabotki dannyh / / Sistemy vysokoj dostupnosti. - 2011. Tom 7, № 4. - S. 72-74.

4. Munerman V.I. Modeli obrabotki bol'shih ob#emov dannyh v sistemah massovogo parallelizma / / Sistemy vysokoj dostupnosti. -2013. Tom 9, № 1. - S. 35-43.

5. Posypkin M.A., Suhomlin V.A., Hrapov N.P. Kombinirovannye raspredelennye infrastruktury v nauke i obrazovanii // Sovremennye informacionnye tehnologii i IT-obrazovanie. - 2015. Tom 1, № 11. - 31-36.

6. Posypkin M.A. Grid-sistem iz personal'nyh komp'juterov v Rossii: tekushhee sostojanie i perspektivy // Sovremennye informacionnye tehnologii i IT-obrazovanie. - 2012. - № 8. - S. 951-957.

Поступила: 25.05.2017

Об авторе:

Мунерман Виктор Иосифович, кандидат технических наук, доцент кафедры информатики, Смоленский государственный университет, [email protected].

Note on the author:

Munerman Victor I., Candidate of Technical Sciences, associate professor of Phisics & Math Department, Smolensk State University, [email protected].