CC BY
86
ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ
ТЕХНИКА
УДК 004.657
Ю. А. Григорьев, В. Л. Плужников
МОДЕЛЬ ОБРАБОТКИ ЗАПРОСОВ В ПАРАЛЛЕЛЬНОЙ СИСТЕМЕ БАЗ ДАННЫХ
Проанализированы существующие методы выполнения запросов в параллельной СУБД. Разработана модель обработки запросов в виде замкнутой и разомкнутой систем массового обслуживания. Приведено преобразование Лапласа-Стилтьеса времени выполнения запроса в параллельной СУБД и рассмотрены варианты этого преобразования для различных архитектур параллельных систем баз данных. Проанализирован способ выбора архитектуры по критерию стоимости с ограничением на верхнюю границу доверительного интервала времени выполнения запроса.
E-mail: grigorev@iu5.bmstu.ru; plz@croc.ru
Ключевые слова: параллельные базы данных, преобразование Лапласа-
Стилтьеса, математическое ожидание времени выполнения запроса.
Параллельные системы баз данных начинают вытеснять традиционные компьютеры основного класса, так как они позволяют работать со значительно более крупными базами данных в режиме, поддерживающем транзакции [1]. Успех таких систем опровергает прогноз статьи, опубликованной в 1983 г. [2] и предрекавшей скорое исчезновение машин баз данных. За последние десять лет компании Teradata, Tandem и другие успешно разрабатывали и продавали параллельные машины, что можно объяснить широким распространением реляционных баз данных. В 1983 г. они только еще появлялись на рынке, сегодня же доминируют. Реляционные запросы как нельзя лучше подходят для параллельного выполнения. Они состоят из однородных операций над однородным потоком данных. Каждая операция образует новое отношение (таблицу), так что из операций могут быть составлены высокопараллельные графы потоков данных.
В настоящее время не существует научно обоснованного метода оценки и выбора архитектуры параллельной системы баз данных. Сравнительный анализ архитектурных решений выполняется или на основе экспертных оценок качественных критериев (масштабируемости, доступности данных, баланса загрузки, межпроцессорных коммуникаций, когерентности кэшей, организации блокировок и др.) [3], или на основе результатов тестов (TPC и др.) для конкретных платформ [4]. Оценки времени (сложности) выполнения алгоритмов в многопроцессорных системах, как правило, представляются в виде асимп-
тотических выражений на уровне множества функций О, в, что не позволяет их использовать для получения численных результатов [5].
В настоящей статье предложены математические методы оценки индексов производительности и выбора архитектуры параллельных систем баз данных, учитывающие особенности выполнения запросов к базе данных проектируемой системы, а также топологию (структуру) различных архитектурных решений.
Выполнение запроса в параллельной СУБД. В этом разделе в качестве иллюстрации основных положений параллельных систем баз данных приведены некоторые сведения, изложенные Л.Б. Соколинским и М.Л. Цымблером в работе [3].
Основной формой параллельной обработки запросов является фрагментный параллелизм (рис. 1). Каждое отношение (таблица) делится на части, называемые фрагментами. Фрагменты отношения распределяются по различным процессорным узлам многопроцессорной системы. Способ фрагментации определяется функцией фрагментации ф, которая для каждого кортежа отношения вычисляет номер процессорного узла, где должен быть размещен этот кортеж. На рис. 1 показана фрагментация отношения Поставщик (П) по атрибуту Код_П (код поставщика) на основе метода диапазонов. В данном случае функция фрагментации имеет вид: ф(П) = П.Код_Пёгу10; здесь Шу — операция деления нацело. В простейшем случае запрос параллельно выполняется на всех процессорных узлах. Полученные фрагменты сливаются в результирующее отношение.
На практике, однако, не удается избежать пересылки кортежей между процессорами во время выполнения запроса. Рассмотрим пример. Пусть отношение Поставщик (П) фрагментировано по атрибуту
Рис. 1. Фрагментный параллелизм
Код_П, а отношение Поставщик деталей (ПД) — по атрибуту Код_Д (код детали). Предположим, что выполняется соединение отношений П и ПД в соответствии с условием П.Код_П = ПД.Код_П. При выполнении операции соединения СУБД должна перераспределять кортежи отношения ПД, так как оно фрагментировано не по атрибуту соединения. Способ перераспределения определяется функцией распределения S, которая для каждого кортежа отношения вычисляет номер процессорного узла, на котором должен быть обработан этот кортеж. В данном примере в качестве функции распределения для отношения ПД следует взять функцию фрагментации отношения П: ¿пд (ПД) = фп (ПД) = ПД.Код_П div 10.
Если оба отношения, участвующие в соединении, фрагментирова-ны не по атрибуту соединения, то СУБД придется перераспределять между процессорами оба входных отношения. При этом в качестве функции распределения для обоих отношений СУБД может взять любую, но одну и ту же функцию распределения по атрибуту соединения, которая отправляет кортежи с одинаковыми значениями атрибута соединения на один и тот же процессорный узел.
Для организации межпроцессорных обменов в соответствующие места дерева плана запроса СУБД вставляет специальный оператор exchange. Оператор exchange реализуется на основе использования стандартного скобочного шаблона и имеет два специальных параметра, определяемых пользователем: номер порта обмена и указатель на функцию распределения. Функция распределения для каждого кортежа вычисляет логический номер процессорного узла, на котором данный кортеж должен быть обработан. Параметр "порт обмена" позволяет включать в дерево запроса произвольное число операторов exchange (для каждого оператора указывается свой уникальный порт обмена).
Структура оператора обмена exchange изображена на рис. 2. Оператор exchange является составным и включает в себя четыре оператора: gather, scatter, split и merge, которые реализуются на базе стандартного скобочного шаблона. Оператор split — это бинарный оператор, который
Рис. 2. Структура оператора exchange
разбивает кортежи, поступающие из входного потока, на две группы: свои и чужие. Свои кортежи — это те, которые должны быть обработаны на данном процессорном узле. Они направляются в выходной буфер оператора split. Чужие кортежи, т.е. кортежи, обработанные на процессорных узлах, отличных от данного, помещаются оператором split в выходной буфер правого дочернего узла, в качестве которого фигурирует оператор scatter. Здесь выходной буфер оператора split играет роль входного потока данных.
Нульарный оператор scatter извлекает кортежи из своего выходного буфера и пересылает их на соответствующие процессорные узлы, используя заданный номер порта. Запись кортежа в порт может быть завершена только после того, как реципиент выполнит операцию чтения из данного порта.
Нульарный оператор gather выполняет перманентное чтение кортежей из указанного порта со всех процессорных узлов, отличных от данного. Считанные кортежи помещаются в выходной буфер оператора gather.
Оператор merge определяется как бинарный оператор, который забирает кортежи из выходных буферов своих дочерних узлов и помещает их в собственный выходной буфер.
Общая схема обработки запроса в параллельной СУБД изображена на рис.3. В соответствии с этой схемой запрос на языке SQL преобразуется в некоторый последовательный план, который, в свою очередь, преобразуется в параллельный план, представляющий собой совокупность n идентичных параллельных агентов, реализующих те же операции, что и последовательный план. Здесь n обозначает число процессорных узлов. Это достигается путем вставки оператора обмена exchange в соответствующие места дерева плана запроса. На завершающем этапе агенты рассылаются на соответствующие процессорные узлы, где интерпретируются исполнителем запросов. Результаты выполнения агентов объединяются корневым оператором exchange на нулевом процессорном модуле.
Рис. 3. Обработка запроса в параллельной СУБД
Рис. 4. Классификация Стоунбрейкера
Модель обработки запросов. Наиболее распространенной системой классификации параллельных систем баз данных является система, предложенная Майклом Стоунбрейкером [6, 7] (рис. 4). На рис. 4 введены следующие обозначения: P — процессор, M — модуль оперативной памяти (ОП), D — дисковое устройство, N — соединительная сеть. Эта классификация неполная, имеются и другие архитектуры, в частности архитектура SN может быть реализована на основе персональных компьютеров.
Далее предлагаются оценки времени выполнения запроса "select A from R where F" с планом (aF(R)) для различных конфигураций параллельных систем баз данных.
На рис. 5 представлены модели обработки запроса и приняты следующие обозначения: дисциплины обслуживания: PS — Processor Sharing (квантование); IS — Immediately Served (ресурс без очереди); L — число записей в блоке БД; PF — вероятность, что запись удовлетворяет условию поиска F; 1 — чтение блока БД с L записями с диска RAID-массива в кэш диска; 2 — перезапись блока с L записями БД из кэша диска в ОП (интенсивность XL), чтение L записей из ОП в кэш процессора (XL), сохранение записей, удовлетворяющих условию поиска F, в ОП для слияния их на выделенном процессоре (XPFL); 3 — обработка в процессоре L записей БД; 4 — передача записей (для SD и SN), удовлетворяющих условию поиска (с вероятностью PF), выделенному процессору для слияния результатов (межпроцессорный обмен).
Следует отметить, что обработка данных в каком-либо ресурсе разбита на кванты. Для дискового массива — это чередующиеся секторы блока БД, для шины ОП — это слова записи БД. Для сети N — это пакеты записи БД, передаваемые по межпроцессорной шине.
Как видно из рис. 5, модель обработки запроса к БД представляет собой замкнутую СМО с различными дисциплинами обслуживания в узлах. В модели циркулируют n заявок, которые соответствуют процессорам системы. Точный метод расчета индексов производительности с помощью этой модели имеет ряд недостатков: расчеты по этой
A(2L-1) X(1-Pf)(L-1)
а
H2L-1) X(\—Pf)(L—\)
Рис.5. Модель обработки запроса в параллельной системе баз данных с архитектурой SE (а) и архитектурами SD и SN (б)
модели достаточно сложны для большого числа процессоров п; результаты анализа нельзя представить в виде простых аналитических формул, с помощью которых можно было бы построить графики зависимостей и сравнить варианты решений.
Чтобы упростить расчеты и сделать их более наглядными, далее предложено использовать метод "узкого места". Пусть г-й и 3 -й узлы — это ресурсы с очередью в замкнутой СМО. Тогда из работы [8, формула (1.34)] имеем
- » ^ ^ Яг » ^, (1)
Рг Рэ
где , -э — интенсивности входных потоков узлов; , — интенсивности обслуживания заявок в этих узлах; , — среднее число заявок в узлах.
В случае выполнения неравенства (1) для всех 3 = г (т.е. при наличии "узкого места") модели (см. рис. 5) можно свести к двухузловой замкнутой СМО (рис. 6) с композиционным центром (1) и г-м разделяемым ресурсом (2). Здесь а и Ь — время обработки в узлах, п — число циркулирующих заявок (процессоров).
Рассматривая модели, приведенные на рис. 5, как дискретные марковские цепи в моменты выхода заявки из узлов, можно рассчитать параметры модели, представленной на рис. 6 (табл. 1).
Архитектура Условие Узкое место Параметры модели
а b
SE 1 2 + PF — »-F Мв Мм Диск ( 2 + PF + 1 )L V ßM ßp/ 1 ßDB
2 + PF 1 -» — Мм Мв ОП 1 ( 1 1 X 2 + Pf V ßp + ßD' 1 ßM
SD 1 PF — » —- Мв Мм Диск (A + .1 + Pf )L VßM ßp ßN' 1 ßDB
PF 1 — » — Мм Мв Сеть 1 ( 1 1 2 x ■Б"!—^ —+- Pf Vßp ßD ßM' 1 ßN
SN Нет Сеть 1 ( 1 1 2 \ -Б-1— + — +- Pf Vßp ßD ßM' 1 ßN
Рис. 6. Двухузловая замкнутой СМО с композиционным центром
Таблица 1 СМО с композиционным центром
Архитектура
SE
SD
SN
Условие
1 2 + PF
— »-F
ßD ßM
2 + Pf 1
-» —
ßM ßD
1 PF
- ^ —F
ßD ßN
PF 1
- » -
ßN ßD
Нет
Узкое место
Диск
ОП
Диск
Сеть
Сеть
Параметры модели
'2 + PF + ^ )L
ßM
ßP
1
2 + Pf V ßp ßD'
(A + -L + Pf )L
VßM ßp ßN'
1 ( 1 1 2 X
Pf Vßp ßD ßM'
1 ( 1 1 2 \
-Б-1— + — +-
Pf Vßp ßD ßM'
ßDB
1
ßM
1
ßDB
1
ßN
1
ßN
В табл. 1 приняты следующие обозначения: — интенсивность чтения записей БД с диска ЯАГО-массива; = • Ь, где — интенсивность чтения блоков БД с диска; — интенсивность чтения/сохранения записей БД в ОП; — интенсивность передачи записей БД по сети (межпроцессорный обмен); — интенсивность обработки записей БД в процессоре.
Сведение замкнутой двухузловой СМО к разомкнутой. Модель, приведенная на рис. 6, проще, чем модели, представленные на рис. 5. Однако она имеет существенный недостаток: результаты анализа нельзя представить в виде простых аналитических формул, с помощью которых можно было бы сравнить варианты решений.
Рассмотрим два случая (см. рис. 6).
1. Загрузка ресурса 2 большая. В этом случае интенсивность выходного потока примерно равна 1/Ь. Тогда средняя длина очереди в разделяемом ресурсе 2 составляет к = п — а/Ь. Отсюда получаем
nb
n
> 1.
(2)
а п — к
В этом случае можно сделать интересный вывод. Пусть Ь > а (разделяемый ресурс 2 медленный). Тогда > Я\, где и —
b
а
1
среднее число заявок в ресурсах 2 и 1. Это следует из утверждения [8, формула (1.34)]
а'
бг >-, г = 1,...,п ^Я2 >дь (3)
г!
Значит, = тп, - < т < 1. Отсюда получаем оценку для среднего 2
времени обработки записей таблицы базы данных
Т = ^ + а) 5 = 56 (V + 4), (4)
п V п6/
где 5 — либо число блоков в таблице ("узкое место" — диск), либо число записей в таблице ("узкое место" — ОП или сеть).
Из уравнения (4) следует, что Т слабо зависит от числа процессоров п. Отсюда можно сделать следующий вывод: если в системе имеется медленный разделяемый ресурс, то распараллеливание выполнения запроса по нескольким процессорам не приведет к существенному уменьшению времени обработки этого запроса к БД.
2. Загрузка ресурса 2 небольшая. Интенсивность выходного потока равна Р/6, где Р — вероятность, что разделяемый ресурс 2 занят. Отсюда для достаточно больших п имеем
п6 Рп
Р = — =-т < 1. (5)
а п — к
Известно [8], что СМО (см. рис. 6) с дисциплиной квантования (Р5) эквивалентна СМО с дисциплиной "первый пришел — первый обслужен" (БСБЗ) и экспоненциальным распределением времени обслуживания (по крайней мере, это справедливо для распределения числа заявок в разделяемом ресурсе 2 и среднего времени пребывания в нем). Для последней СМО справедливо следующее распределение вероятностей числа заявок в разделяемом ресурсе 2 [9]:
/п6у (п — г + 1)(п — г + 2)... п
Рг = Ро — -----, 1 < г < п. (6)
V а / пг
При малых г и больших п
'п6 у
Рг ^ Р^ . (7)
п6
Если выполняется условие (5), то Ро ^ 1 — р =1--. Ошибка
а
вычисления Рг по формуле (7) возрастает при увеличении г, но в этом случае Рг мало.
Однако распределение (7) справедливо для разомкнутой СМО М/М/1. Интенсивность входного потока для М/М/1 определяется по
формуле
л = пЛ, Л = 1, (8)
а
где параметр а рассчитывается по формулам, приведенным в табл. 1.
Далее будем использовать следующие обозначения для интенсив-ностей входного потока:
Лов и Ло = ЛовL — интенсивность заявок на чтение с диска от одного процессора блоков и соответственно записей БД; Лм — интенсивность заявок на чтение/сохранение записей БД в ОП от одного процессора; Лм — интенсивность заявок на передачу записей БД по сети межпроцессорного обмена от одного процессора.
Можно сформулировать стратегию вычислений индексов производительности параллельной системы базы данных, построенной на основе какого-либо архитектурного решения (см. рис. 4):
1. Выявить "узкое место" системы (см. табл. 1).
2. Если выполняется неравенство (2), то считать архитектуру параллельной системы базы данных неудачной и перейти к другому архитектурному решению.
3. Если выполняется неравенство (5), то для расчетов модели, приведенной на рис. 6, использовать разомкнутую СМО М/М/1 с параметрами, которые указаны в табл. 1.
Оценка времени выполнения запроса. Используя подход, предложенный в работе [10], можно вывести следующее преобразование Лапласа-Стилтьеса (ПЛС) времени выполнения запроса к базе данных с планом пА(ор(Л)):
ф(в) = С(ф]^ (в)фМ (я)(1 — Ре (1 — фм (в)))фр (в)), (9)
где й = гу/п — производящая функция числа записей фрагментиро-ванной таблицы Л, обрабатываемых на одном процессоре; V — общее число записей в таблице Л; п — число процессоров (или персональных компьютеров в кластере); фо (в) — ПЛС времени чтения блока БД фрагментированной таблицы с диска (с учетом очереди к дисковому массиву), Ь — число записей таблицы в блоке БД; фм(в) — ПЛС времени чтения/сохранения записи фрагментированной таблицы в оперативной памяти (с учетом очереди к шине памяти); фм(в) — ПЛС времени межпроцессорного обмена при передаче результирующей записи по сети N; фР(в) — ПЛС времени обработки записи в процессоре, который является неразделяемым ресурсом (будем предполагать, что это время распределено по экспоненциальному закону); РЕ — вероятность, что запись удовлетворяет условию поиска ^ (эта вероятность рассчитывается по известным формулам [10]) .
На основе приведенных рассуждений будем считать, что каждое ПЛС фо(в), фм(в), фм(в) соответствует времени пребывания в СМО
М/М/1. Время пребывания в СМО М/М/1 распределено по экспоненциальному закону. Для фр(з), фм(з), ф^(з), фр(в) имеем
(^д - пЛр)(ир +
(s) =
Фм (s) =
Фм (s) =
фр(s) =
^D
^м
^D (^D - «ad + Ls) (^d + Ls) (^M - пЛм)(^M + s) ^M (^M - пЛм + s) (^N - nAW)(^N + s)
(^M + s)
= фDW (s^dc (s); (10)
= Фмw (s)фм с (s); (11)
^N
^N (^N - «An + s) (^N + s)
= Фм-W (s)фN С (s);
(12) (13)
^р + з
Здесь п — число процессоров; (в), ф^(з) — это соответственно ПЛС времени обработки записи и ожидания обработки ее в ресурсе.
Обозначения ^ и Л были введены ранее; при этом должно выполняться неравенство
' р = ПЛ< 1. (14)
^
Преобразования Лапласа-Стилтьеса времени выполнения запроса к базе данных (см. (9)) для различных конфигураций (см. рис. 4) отличаются присутствием или отсутствием в них ПЛС фр^ (з), фм^ (з), фм^ (з) (табл. 2). Все зависит от того, разделяемый ли в конфигурации ресурс (т.е. возможна ли к нему очередь) или нет. Если ПЛС отсутствует, то в формулах (10)-(12) его заменяют единицей.
Наличие составляющей ф^ (з) зависит также от того, является ли ресурс "узким местом" (см. табл. 1).
Из выражения (9) можно получить математическое ожидание и дисперсию времени выполнения запроса к БД:
М = -ф' (0); (15)
М?2 = ф(2)(0);
о\ = M?2 - M|.
(16) (17)
В качестве примера выведем теперь выражение для математического ожидания времени выполнения запроса к БД для архитектуры ББ в предположении, что "узким местом" является диск (см. табл. 1).
Таблица 2
Наличие/отсутствие ПЛС в формуле (9)
Архитектура <pDW (S) <Pmw (s) Фмш (з)
SE Да Да фм(й) следует заменить на фм(з), так как нет сети
SD Да Нет Да
SN Нет Нет Да
Дифференцируя выражение (9) как сложную функцию в нуле, получаем
ы^ = -Ф (0) = -(
1
+
1 \
n\ßD - n\D ßMP
1
ßM + ßp (2 + PF )
(18)
Рис. 7. График зависимости M^ от числа процессоров n
1^МР ЦР
С помощью формул (16) и (17) можно записать выражения для М^2 и а^ •
График зависимости математического ожидания М^ времени выполнения запроса от числа процессоров п в параллельной системе баз данных показан на рис. 7.
Координаты точек, обозначенных на рис. 7 (п* — точка минимума), вычисляются по формулам:
У1 = М^ (1) = V ( 1 Л + —); (19)
^ х +
ßD - ^D ßMP
* ßD
n = T
AD
ßMP
D
ßD ßMP
+ 1- 1
y
V f 1
= ые (n * ) = V(-
n ßD n
1\
+
^D ßMP
У
(20)
(21)
п* — п*Х
Из уравнения (20) следует, что при возрастании ^мР значение п убывает. Используя правило Лопиталя, запишем
lim
*
n =
2А
D
(22)
Можно показать, что производная n* по PF больше нуля. Поэтому значение n* возрастает с увеличением PF (0 ^ PF ^ 1).
Поведение функции Ы% (n) (см. рис. 7) объясняется тем, что сначала с ростом числа процессоров время убывает благодаря распараллеливанию обработки запроса, затем время возрастает из-за перегрузки подсистемы ввода/вывода.
Метод выбора архитектуры системы. Используя сведения, приведенные в табл. 1 и 2, а также формулы (9)-(17), можно получить математические ожидания и дисперсии времени выполнения запроса к БД для всех архитектур, представленных на рис. 4. С помощью этих выражений можно выполнить сравнение архитектур по стоимости с учетом ограничения на время выполнения запроса или смеси запросов.
Для каждой i-й архитектуры необходимо решить задачу оптимизации:
Ci (n) — min
+ ka^ < ТГр, (23)
где Ci(n) — стоимость i-й архитектуры с n процессорами; M^ + ka^ — верхняя граница доверительного интервала (k = 1... 3); Тгр — предельно допустимое время выполнения запроса или смеси запросов.
Следует отметить, что если величина V/n достаточна велика, то в соответствии с центральной предельной теоремой Ляпунова функция распределения времени выполнения запроса стремится к нормальному закону (это объясняет граничное значение k, равное 3).
Оптимальной будет архитектура с минимальным значением C^n^i). Смысл задачи (23) заключается в том, что какая-то архитектура может быть быстрой, но иметь высокую стоимость, и наоборот.
Заключение. 1. Проанализирован существующий способ выполнения запросов в параллельной системе баз данных. СУБД выполняет фрагментацию таблиц (отношений) базы данных и пересылку фрагментов процессорам. Оптимальный последовательный план тиражируется по процессорам, т.е. создаются n идентичных параллельных агентов, каждый из которых выполняет операции с фрагментами таблиц, переданными процессору. Результаты, полученные от всех процессоров, объединяются.
2. Разработана модель обработки запросов в параллельной системе баз данных в виде замкнутой и разомкнутой СМО, учитывающая наличие "узкого места" в системе.
3. Приведено преобразование Лапласа-Стилтьеса времени выполнения запроса, имеющего план nA(aF (R)), в параллельной СУБД. Рассмотрены варианты этого преобразования для различных архитектур параллельных систем баз данных, т.е. ПЛС времени ожидания освобождения ресурса входит или не входит в исходное ПЛС времени выполнения запроса в зависимости от того, является ли ресурс разделяемым или нет.
4. Исследована зависимость математического ожидания времени выполнения запроса к БД от числа процессоров для архитектуры SE. Показано, что сначала с ростом числа процессоров время убывает благодаря распараллеливанию обработки запроса, затем время возрастает из-за перегрузки подсистемы ввода/вывода, которая является разделяемым ресурсом.
5. Предложен способ выбора архитектуры параллельной системы баз данных по критерию стоимости с ограничением на верхнюю границу доверительного интервала времени выполнения запроса или смеси запросов.
6. Предполагается продолжить исследования и получить оценки времени выполнения запросов с более сложными планами реализации (например, для плана соединения таблиц).
СПИСОК ЛИТЕРАТУРЫ
1. Дэвид Девитт, Джим Грэй. Параллельные системы баз данных: будущее высокоэффективных систем баз данных / Пер. С. Кузнецова, 2009: [Электронный ресурс]. [http://www.citforum.ru/database/classics/parallel_f]. Проверено 10.04.2009.
2. B o r a l H. and D e W i 11 D. Database machines: An idea whose time has passed? A critique of the future of the database machines. In Proceedings of the 1983 Workshop on Database Machines. H.-O. Leilich and M. Missikoff, Eds., SpringerVerlag, 1983.
3.Соколинский Л. Б., Цымблер М. Л. Лекции по курсу "Параллельные системы баз данных": [Электронный ресурс]. [http://pdbs.susu.ru/CourseManual.html]. Проверено 10.04.2009.
4. Transaction Processing Performance Council (TPC): [Электронный ресурс]. [http://www.tpc.org]. Проверено 10.04.2009.
5. Миллер Р., Боксер Л. Последовательные и параллельные алгоритмы. Общий подход. - М.: БИНОМ. Лаборатория знаний, 2006. - 406 с.
6. Соколинский Л. Б. Обзор архитектур параллельных систем баз данных // Программирование. - 2004. - № 6. - С. 1-15.
7. DavidDewitt, Jim Gray. Parallel database systems: the future of high performance database systems // Communications of the ACM. - June 1992. -Vol.35. No. 6. - P. 1-26.
8. Жожикашвили В. А., Вишневский В. М. Сети массового обслуживания. Теория и применение к сетям ЭВМ. - М.: Радио и связь, 1988. -192 с.
9. К л е й н р о к Л. Теория массового обслуживания. - М.: Машиностроение, 1979. - 432 с.
10. Григорьев Ю. А., Плутенко А. Д. Теоретические основы анализа процессов доступа к распределенным базам данных. - Новосибирск: Наука, 2002. - 180 с.
Статья поступила в редакцию 22.03.2010
Юрий Александрович Григорьев родился в 1951 г., окончил МГТУ им. Н.Э. Баумана в 1975 г. Д-р техн. наук, профессор кафедры "Cистемы обработки информации и управления" МГТУ им. Н.Э. Баумана. Автор более 75 научных работ в области обработки информации и управления.
Yu.A. Grigoriev (b. 1951) graduated from the Bauman Moscow Higher Technical School in 1975. D. Sc. (Eng.), professor of "Systems of Data Processing and Management" department of the Bauman Moscow State Technical University. Author of more than 75 publications in the field of data processing and management.
Всеволод Львович Плужников родился в 1984 г., окончил МГТУ им. Н.Э. Баумана в 2006 г. Ведущий инженер ЗАО "КРОК Инкорпорейтед". Автор одной научной работы в области обработки информации и управления.
V.L. Pluzhnikov (b. 1984) graduated from the Bauman Moscow State Technical University in 2006. Leading engineer of private company "KROK Incorporated". Author of 1 publication in the field of data processing and management.
