CC BY
62
УДК 681,3,012(04)
Д. А. Лыфарь
Омский государственный университет ул. О. Кошевого 22, Омск, 644082, Россия E-mail: [email protected]
ПАРАЛЛЕЛЬНЫЕ АЛГОРИТМЫ ОБРАБОТКИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
В работе реализован набор параллельных алгоритмов выборки реляционных баз данных на GPU: выборка с условием WHERE, агрегатные функции (MIN, MAX, COUNT для целочисленных данных), а также частичная поддержка операции ORDER BY для целочисленных типов. Представлен анализ скорости работы на центральном и графическом процессорах, а также достоинств и недостатков GPU на рассматриваемой задаче. Сделаны выводы и намечены пути дальнейшего развития.
Ключевые слова: GPU, параллельные алгоритмы, СУБД.
Введение
В современных СУБД цена исполнения одного запроса состоит из двух частей: время, потраченное на операции ввода-вывода (время загрузки данных с медленного носителя в оперативную память), и время вычисления (исполнение запроса над данными и возвращение результата). Традиционно исследователи и разработчики СУБД делали акцент на уменьшении стоимости операций ввода-вывода (IO), так как ранее время ввода-вывода значительно превосходило остальные затраты. Согласно исследованиям ведущих коммерческих фирм соотношение между этими двумя компонентами выравнивается (см. [1-3]). Отметим растущую популярность направления GPGPU (Generic GPU Programming), описывающую способ решения задач на параллельной архитектуре GPU.
В то время как большинство CPU имеют от 1 до 16 процессоров, у GPU их может быть несколько сотен простых процессоров (под простотой здесь понимается отсутствие таких компонентов, как предсказание переходов, кэш и т. п.). Архитектура GPU принадлежит к классификации SIMT (Single Instruction Multiple Thread). Имея функцию, выполняющую некую работу, разработчик назначает ее исполнение на GPU. Каждый поток исполняет одну и ту же функцию, Потоки объединены в группы, каждая из которых исполняется на собственном процессоре. Синхронизация потоков возможна лишь в пределах группы (блока). Возможны также атомарные целочисленные операции. Модель программирования GPU описывает 6 различных областей памяти (различных по скорости доступа, прав на запись-чтение, объему). Подробности архитектуры GPU (в частности ее программной модели CUDA) описаны в [4].
Наличие большого числа процессоров и быстрой памяти предполагает эффективность исполнения выборки данных со сложным условием, ведь каждый поток будет исполняться независимо от других, оперируя лишь малой частью обрабатываемых данных. Признанным стандартом в области обработки реляционных БД является декларативный язык SQL. Целесообразно будет перенести часть языка для исполнения на графическом процессоре.
В этой работе была выбрана известная СУБД с открытым исходным кодом MySQL. Выбор был сделан по следующим соображениям: наличие большой тестовой базы, отсутствие необходимости в реализации парсера, оптимизатора, сетевой части БД и других компонентов, не участвующих непосредственно в самой выборке, а также возможность при наличии
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2010. Том 8, выпуск 4 © Д. А. Лыфарь, 2010
положительных результатов относительно быстро развивать продукт с ростом возможностей GPU.
Далее описаны полученные алгоритмы, структуры данных и приведен анализ производительности. Те запросы к БД, которые нецелесообразно исполнять на GPU, исполняются на обычном процессоре, поэтому полученную систему будем называть гибридной.
Существующие исследования
В области обработки баз данных на GPU уже существует ряд исследований ([5; 6] и др.). Рассмотрим одну из последних и наиболее близких к исследуемому вопросу работ [7]. Множество обрабатываемых данных было ограничено столбцами с типами целое и число одинарной точности с плавающей точкой. Тестовые таблицы представляют собой набор кортежей, в каждом из которых пять элементов. В дополнение к реализации функции SELECT авторы реализовали набор агрегатных операций, таких как SUM, MIN, MAX, COUNT, AVG. Данные одной таблицы постоянно хранятся в памяти GPU для того, чтобы снизить размер передаваемых данных через шину для каждого запроса, Для запуска выборки над множеством данных необходимо преобразование B-дерева в структуру аналогичную табличному представлению, что также учтено во времени передачи данных. Тесты проводились на Tesla C1060 GPU, имеющем 4 Гб оперативной памяти, что и является ограничением размера таблицы. Для метаданных, таких как размер блока, число колонок в блоке, размер каждой колонки использована константная область памяти, SQLite была выбрана авторами на том же основании, что и MySQL в этой работе, однако она является встраиваемой БД. В методику тестирования авторы добавили ряд ограничений, приближающих тесты к практическим условиям:
• мы загружаем данные на GPU полностью, в то время как SQLite на CPU запрашивает их с диска по необходимости. Для того, чтобы устранить очевидное преимущество GPU в этом случае, в SQLite использовалась таблица, которая хранит содержимое таблицы полностью в памяти;
• чтобы сделать традиционное исполнение SQLite быстрее, результаты, возвращаемые ей, игнорировались, а также она была скомпилирована с опцией хранения всех временных файлов в памяти.
Страничная память (pinned или paged-memory), которая позволяет примерно в два раза увеличить скорость обмена данными между host и device за счет одновременной записи и чтения, не использовалась. Авторы реализовали поддержку поточной подгрузки данных на GPU (т. е. когда 25 % данных уже загружены в память GPU, начинается их обработка, а оставшаяся часть загружается параллельно), однако расходы преобразования B-дерева в табличный вид существенно уменьшают выигрыш этого подхода. Возможно, следует рассмотреть поточность в случае, когда мы записываем результат. Основные результаты этого исследования приведены в табл. 1. Авторы использовали тестовую таблицу в 12 миллионов строк (заголовок таблицы представляет собой 3 целочисленных поля и 2 поля типа числа с плавающей точкой). При увеличении размеров таблицы результаты становятся чуть хуже за счет увеличения числа строк, обрабатываемых одним потоком (больше, чем 1), и усиления эффекта расхождения потоков (thread divergence, он будет описан далее). Тестовые запросы имеют вид SELECT c1, c3 FROM test_table WHERE c4 = 5 AND c1 > .5. Запросы написаны таким образом, что результирующее множество занимает половину места исходного.
Таблица 1
Результаты исполнения запросов на CPU и GPU из [7]
Запросы (тип) Ускорение на GPU Ускорение на GPU (с временем передачи)
Int 42,11 28,89
Float 59,16 43,68
aggregation(AND,OR,etc) 36,22 36,19
Average 50,85 36,20
В этом исследовании не были рассмотрены строковые типы и сортировка конечных результатов, однако результаты (50-кратное превосходство без учета времени передачи) дают основание считать успешным применение подобного подхода на практике.
Реляционные запросы, исполняемые на GPU. Постановка задачи
SQL состоит из нескольких подъязыков: DDL, DML, DCL и непосредственно операторов выборки. Мы решаем задачу оптимизации выборки, но вследствие необходимости хранить некоторые данные в памяти постоянно, затронута также часть DML (Data Manipulation Language), отвечающая за добавление, обновление и удаление записей. Общий вид запроса, который будет распараллелен, выглядит так:
SELECT a1 [op value], a2, ... an FROM Table WHERE cond ORDER BY ai где, a1, a2, ... an - выбираемые столбцы; op - арифметическое выражение; cond - условие, в котором участвуют столбцы (может быть объединено булевыми операндами OR, AND, NOT).
Существующие решения нацелены, как правило, на сравнение выполнения какой-либо алгоритмической задачи по обработке данных на CPU и GPU. При этом не учитывается ряд ограничивающих факторов, которые имеют место, но не отражаются в исследованиях, близких по тематике к этому.
1. Отсутствие поддержки большего объема данных, чем может быть обработано за раз на GPU (одна из последних архитектур на момент написания статьи имеет максимальное линейное адресное пространство 4 GB). Необходима реализация подкачки новых данных и слияния результатов для сравнения этих же алгоритмов с CPU и вывода о целесообразности полного замещения CPU в этой задаче.
2. Большинство исследований выбирают в качестве типов данных те, которые имеют аппаратную поддержку на GPU (а именно int и float), тогда как СУБД оперируют намного большим множеством данных. Реализация эмуляции операций со строками, датами, большими числами может привнести разницу в результаты сравнения. Так, например, построение индекса по текстовому полю в обычной базе данных и поиск по нему - частая операция. На GPU существует ряд проблем, связанных с этим: если строки достаточно большого размера, то индекс будет занимать большой объем памяти. Стоит рассмотреть использование хэшей для индексации строк, однако в этом случае будут невозможны операции <, >, и т. п.
3. Современная СУБД управляет десятками таблиц, исполняя сложные запросы (объединения, вложенные запросы, запрос из нескольких таблиц). Это существенно усложняет реализацию СУБД на графическом процессоре.
4. Процессоры последнего поколения имеют богатый набор SIMD-инструкций, в том числе и высокоуровневых, которые не поддерживаются GPU аппаратно. Следует рассмотреть гибридную реализацию СУБД, которая будет использовать преимущества обеих архитектур.
Специфика используемых алгоритмов на GPU
Мы указывали, что архитектура GPU значительно отличается от CPU и имеет ряд ограничений. Существует несколько проблемных мест, которые не свойственны СPU. К наиболее существенным из них можно отнести выровненный доступ к памяти и отсутствие предсказателя условных переходов. Остановимся на вопросе доступа к глобальной памяти (он самый медленный из всех типов памяти). GPU определяет, когда потоки, исполняемые в пределах своей группы (warp), пытаются выполнить инструкцию загрузки из памяти и проверяет адреса, по которым они обращаются (наиболее эффективный доступ получается, когда доступ последователен, т. е. каждый n + 1 поток обращается к участку памяти, находящемуся следом за участком памяти потока n). В случае последовательного доступа запросы объединяются (coalesced access) в один общий, это позволяет увеличить пропускную способность. В случае если последовательный доступ не всегда возможен, предлагается загрузить требуемый участок памяти в shared memory. Так как разделяемая память организована в виде банков памяти, следует учитывать возможные конфликты, возникающие при доступе к словам
из одного банка из разных потоков. Новейшие архитектуры (версии 2.0 и выше) помогают программисту избежать этих конфликтов в случае, если все потоки исполняемой группы (warp) пытаются получить по одному и тому же адресу (broadcasting, доступно также в вери-ях архитектуры ниже, чем 2.0), либо некоторая часть группы потоков (multicasting). Что касается условных переходов, то чем более разнится результат вычисления условия между различными потоками в одном блоке, тем большее число прогонов придется выполнить GPU. Например, если 16 потоков получили в условном операторе false, а остальные 16 - true, то код будет исполнен сначала для первых, затем для вторых (причем половина ресурсов во время исполнения будет простаивать). О других ограничениях архитектуры см. [8]
Алгоритм Prefixsum
Данный алгоритм получил большое распространение в сфере параллельных вычислений на CPU и был успешно применен на GPU. Суть алгоритма заключается в следующем.Пусть мы имеем массив данных A. Необходимо преобразовать исходный массив таким образом, что каждый элемент будет иметь значение суммы всех предыдущих. Параллельная реализация, чтобы быть эффективной, должна иметь такую же временную характеристику (O(n)), что и последовательная [9].
В этой работе prefixsum I - это алгоритм одной из трех фаз определения количества места, необходимого для сохранения результата в любой операции выборки. Имея ограничение настоящей архитектуры GPU, запрещающее динамическое выделение памяти из функции GPU, мы выделяем место под результат следующим образом. Сначала каждый из потоков определяет количество результатов, который он получит. На второй стадии запускается алгоритм prefix sum, результатом работы которого является массив со смещениями из исходного массива данных для записей, удовлетворяющих условию (эти смещения будут использоваться каждым из потоков при записи результатов в глобальную память). Далее CPU, зная общее количество результатов, выделяет необходимое количество памяти для их записи в глобальной памяти. Затем каждый из потоков, используя полученные смещения, пишет свои результаты в глобальную память. Похожий подход был использован в работе [5].
Параллельная сортировка
Операция сортировки используется как служебная функция (операторы ORDER BY, реализация некоторых агрегатных функций). Существует множество подходов к параллельной реализации, среди которых можно выделить поразрядную и битоническую сортировки. Мы использовали поразрядную сортировку для целочисленных данных, в случае со строками необходимо искать другой вариант из-за неконстантных затрат по памяти у поразрядной сортировки.
Существует два варианта поразрядной сортировки: least significant bit и most significant bit. При сортировке сначала сортируются младшие разряды, затем старшие. Получается следующий порядок: короткие ключи идут раньше длинных, ключи одного размера сортируются по алфавиту, это совпадает с нормальным представлением чисел. При сортировке получается алфавитный порядок, который подходит для сортировки строк. Последовательность сортируется по старшему значимому двоичному разряду так, чтобы все ключи, начинающиеся с 0, оказались перед всеми ключами, начинающимися с 1. Для этого необходимо найти крайний слева ключ Ki, начинающийся с 1, и крайний справа ключ Kj, начинающийся с 0, После этого Ki и Kj меняются местами, и процесс повторяется, пока не получится i > j. Пусть F0 I - множество элементов, начинающихся с 0, F1 I множество всех остальных элементов. Будем к F0 применять поразрядную сортировку (начав теперь со второго бита слева, а не со старшего) до тех пор, пока множество F0 полностью не рассортируется, Затем проделаем то же самое с F1. Мы использовали реализацию параллельной поразрядной сортировки из [6]. Она выполняется в два прохода: на первом проходе данные разбиваются на блоки (размер каждого блока не превышает размер shared памяти каждого из мультипроцессоров) и сортируются поразрядной LSD сортировкой. На втором проходе используется параллельное слияние.
Операции со строками
Строковые данные имеют фиксированную длину, что соответствует типу MySQL CHAR. Были реализованы следующие строковые операции: сравнение, поиск подстроки, копирование. Строковые алгоритмы из Mars [9] оперируют векторным типом char4, чтение которого из памяти происходит за одну операцию.
Исполнитель запросов
MySQL имеет абстрактный интерфейс Item, для которого определено множество реализаций (внутреннее представление различных SQL-типов, операции над этими представлениями как реализации интерфейса Item_func).
Рис. 1. Дерево разбора WHERE части SQL-запроса
После разбора запроса MySQL строит дерево из элементов реализаций Item (для части запроса WHERE). Исполнитель запросов на GPU использует это дерево для построения цепочки команд (конвеера), которые будут применены к набору данных (их идентификаторы хранятся в постоянной памяти GPU). В соответсвии с полученным деревом (рис. 1) в константной памяти строится цепочка идентификаторов операций, Для приведенного примера она будет такой: item_equal -> item_func_between. Исполнитель начинает работу с первого элемента цепочки, и каждый поток исполняет текущую функцию для своего набора данных, Каждый поток отвечает за обработку одной строки, размером 4 байта в случае с целочисленными данными и 64 - байта со строковыми (структура таблицы и тестовые запросы описана ниже). Сделав несколько прогонов, полагающихся на результаты использования CUDA Occupancy Calculator, мы выяснили, что оптимальный размер блока потоков 128. Далее строится массив смещений при помощи алгоритма prefixsum, как указано выше, и записываются результаты. Затем для каждого результат проходит через второй элемент цепочки, фаза записи результатов повторяется. В конце мы проверяем, нужна ли сортировка полученных результатов, сортируем по необходимости и возвращаем результат в оперативную память. Исполнитель запросов по своей сути это функция, имеющая блок case внутри, который определяет, что должно быть сделано с текущими данными на основании значений идентификаторов операций из постоянной памяти.
Эксперименты и анализ результатов
Как показали эксперименты, производительность GPU на запросах (типы запросов мы рассматривали выше, это SELECT-запросы с логическими условиями в WHERE, возможностью сортировки результата и применения агрегатных функций) в большинстве случаев превышает CPU. Наибольшее ускорение, как и следовало ожидать, получили запросы для таб-
лиц, помещающихся в памяти и имеющих целочисленные и числа с плавающей точкой, типы данных (результаты приведены в табл. 2). Немалую часть времени отнимает подкачка данных в случае, если данные полностью не помещаются в GPU. В том случае, если время подкачки порции данных превосходит время исполнения запроса над этими данными, выполнение запроса на GPU становится нецелесообразным.
Эксперимент проводился на GPU NVIDIA GTX 275 (1,8 GB) и CPU Intel i5 (4-ядерный, частота ядра 2,66 MHz).
Рассмотрим сначала запросы над данными, которые полностью умещаются в памяти графического процессора (мы использовали данные размером 1 Gb для каждого из рассматриваемых типов), Результаты выполнения запросов для различных типов данных без учета времени передачи данных на GPU приведены в табл. 1. Тестовая таблица (домены, полученные из черных списков сайтов http://www.urlblacklist.com/ и http://www.malwaredomain-list.com/) имеет заголовок, состоящий из полей: id INT, domain_name CHAR(64), ip INT UNSIGNED. Условие запроса ï - это обычная проверка на равенство, записанное таким образом, чтобы в результирующий набор попадало четверть исходных данных в случае с целыми типами и строками. Очевидно, что размер результирующего набора влияет на время исполнения запроса из-за времени передачи данных с устройства в оперативную память, Пример такого запроса:
SELECT id FROM domains WHERE id % 4 = 0.
В случае операций со строками запрос имеет следующий вид (каждый четвертый кортеж содержит доменное имя nvidia.com, чтобы удовлетворять нашему условию для результирующего набора):
SELECT domain FROM domains WHERE domain = 'nvidia.com'.
В случае агрегатных функий запрос имеет вид:
SELECT count(domain) FROM domains WHERE id % 4 = 0,
SELECT max(ip) FROM domains,
SELECT min(ip) FROM domains,
Упорядочивание результатов реализовано в данной работе только для целочисленных типов:
SELECT ip FROM domains ORDER BY ip,
В тестовой таблице находится 7 895 160 записей (что занимает около 1 Gb). Для теста, в котором данные не должны размещаться в памяти целиком, записи дублируются.
В самом простом случае, когда GPU оперирует типами с аппаратной поддержкой, он превосходит обычный процессор в 22-28 раз. При эмуляции более сложных типов данных производительность снижается, но по-прежнему превосходит CPU. Повторяя тот же набор запросов, но над данными, превосходящими по размеру объем памяти GPU, получим снижение общей производительности (табл. 2).
Таблица 2
Результаты тестирования без учета времени передачи
Типы данных столбцов Ускорение относительно CPU Время, проведенное на CPU, с Время, проведенное на GPU, с
INT 28 1,12 0,04
FLOAT 22,6 1,13 0,05
CHAR 12,75 1,53 0,12
MIN,MAX, COUNT 7,9 1,43 0,18
ORDER BY 7 0,76 0,11
Таблица 3
Результаты тестирования с учетом времени передачи
Тип данных столбцов Ускорение относительно CPU Время, проведенное на CPU, с Время, проведенное на GPU с учетом передачи, с Время передачи данных, с
INT 12,4 1,12 0,09 0,05
FLOAT 12,5 1,13 0,09 0,04
CHAR 7,29 1,53 0,21 0,09
MIN,MAX,COUNT 7,52 1,43 0,19 0,01
ORDER BY 4,2 0,76 0,18 0,07
Под указанным временем передачи данных понимается сумма времен передачи с CPU на GPU и получения результатов. Как видно из табл. 2, порядок времени передачи данных сравним с временем обработки, вносит заметное различие в общую производительность. Обратите внимание на почти неизменившиеся результаты агрегатных функций вследствие того, что результат является числом и отсутствует нагрузка на шину. Значительное по сравнению со скоростью обработки время передачи дает основание считать, что будет достигнута точка, при которой исполнение запросов на GPU станет нецелесообразным из-за накладных расходов.
Считая время запроса и время передачи данных постоянными величинами, можно построить график зависимости времени от объема обрабатываемых данных на GPU. Учитывая, что мы обрабатываем данные порциями по 1 Гб, точка, полученная на пересечении прямых, построенных для GPU и CPU, говорит о теоретически достижимых 15,9 Гб за время, пока CPU обработает один гигабайт.
Рис. 2.Соотношение времен обработки данных для CPU и GPU на запросе с целочисленными данными: Column A - рост времени в зависимости от объема обрабатываемых данных, Column B - время обработки 1 Gb данных на CPU
Снизить затраты на время передачи можно частично использованием page-locked типа памяти, который появился в новых архитектурах. Он позволяет иметь доступ к оперативной памяти прямо из исполняющегося потока на GPU, при запросе участка памяти он неявно передается. Этот тип может оказаться полезным по ряду причин. Во-первых, шаблон доступа данных в нашей задаче исключает чтение одних и тех же значений несколько раз, что устраняет потери из-за отсутствия кэш-памяти, во-вторых, мы читаем данные последовательно, т. е. в соответствии с их расположением в памяти, что позволяет группировать несколько запросов на чтение из глобальной памяти в один и, в-третьих, позволяет использовать полнодуплексную шину PCI-E полностью, т. е. запросы на запись и чтение могут быть объединены. Теоретически скорость пропускания ограничена скоростью шины и шаблоном ее использования. Простейший тест скорости передачи данных с CPU на GPU показывает 5 Гб/с на page-locked памяти и 4 Гб/с при использовании обычного копирования. У проецируемой (page-locked) памяти на данный момент существует одно ограничение - возможна адресация до 4 Гб адресного пространства, что затрудняет тестирование запросов на больших объемах данных, помещающихся в обычную оперативную память (RAM современных серверов может иметь от 16 Гб и больше памяти).
Что касается более сложных запросов, в которых участвуют две и более таблиц, а также соединения таблиц, то здесь основной проблемой становится объем памяти на современных GPU. Частично этот недостаток можно компенсировать поиском оптимальных схем хранения данных (например, при выполнении агрегатных запросов есть смысл не резервировать данные под результат запроса), алгоритмами планировщика запросов, позволяющих выполнять их гибридно (что увеличит общую производительность), и использования отображения, описанного в предыдущем абзаце. Однако здесь время исполнения будет расти медленнее не из-за затрат на передачу, а из-за низкой скорости носителя (жесткого диска).
Выводы
По результатом этой работы можно судить о целесообразности использования GPU в задачах обработки реляционных БД. Здесь мы рассмотрели лишь ограниченное множество доступных операций на чтение и используемых типов. Учитывая многопользовательскую природу СУБД MySQL, наличие гораздо большего числа таблиц в используемых БД на практике и существенное время передачи данных между устройством и оперативной памятью, можно сделать вывод о необходимости планировщика запросов, который стремился бы снизить обмен данными, определял бы степень эффективности исполнения запроса на GPU и реализовывал поточную обработку, о которой мы упоминали в обзоре существующих исследований. Однако имеющиеся результаты показывают, что в среднем GPU быстрее в 10 раз на архитектуре не самого последнего поколения.
В качестве направления дальнейшего развития можно указать: полную поддержку синтаксиса оператора выборки (оператор GROUP BY, поддержка ORDER BY для строк, операторы объединения и пересечения, полноценная поддержка агрегатных функций и функций, оперирующих строками). Одним из важнейших направлений является реализация объединений (внешнее, внутреннее, декартово произведение) из-за интенсивного использования памяти. Возможно, нагрузку на шину можно будет снизить, используя поточную архивацию данных (на момент написания статьи существует работа [11], подтверждающая целесообразность этого подхода).
Как видно из результатов, основным ограничивающим фактором является размерность памяти устройства, когда время передачи / получения результатов начинает играть главную роль при принятии решения о целевом процессоре. Однако текущие прогнозы относительно скорости развития графических процессоров выглядят оптимистично. Он основывается на законе Мура, Закон Мура - эмпирическое наблюдение, сделанное в 1965 г., в процессе подготовки выступления Гордоном Муром. Он высказал предположение, что число транзисторов на кристалле будет удваиваться каждые 24 месяца, Представив в виде графика рост производительности запоминающих микросхем, он обнаружил закономерность: новые модели микросхем разрабатывались спустя более или менее одинаковые периоды (18-24 мес.) после появления их предшественников, а ёмкость их при этом возрастала каждый раз примерно
вдвое. Если такая тенденция продолжится, заключил Мур, то мощность вычислительных устройств экспоненциально возрастёт на протяжении относительно короткого промежутка времени. Что касается GPU, то скорость роста их мощности превосходит закон Мура для традиционных процессоров (удвоение вычислительной мощности каждые 10 месяцев). Однако относительно недавно (речь идет о 2009-2010 гг.) закон Мура перестал выполняться, и больше не применим к темпам роста и развития мира кремниевых центральных и графических процессоров. Достигнут предел того, чего можно достичь в разработке традиционных процессоров, реализующих идеологию последовательных вычислений. Каждые 18 месяцев вычислительная мощность процессоров перестала удваиваться, и это представляет собой серьезную проблему многим отраслям промышленности, которые в своей работе всегда полагались на исторически сложившийся темп роста вычислительных мощностей. Одним из решений может быть переход на параллельные вычисления, для которого потребуется адаптировать существующие алгоритмы для работы в многопоточной среде.
Список литературы
1. Andrea Di Blas, Tim Kaldewey. Data Monster. Why graphics processors will transform database processing // Oracle corp. research and development.
2. Govindaraju N., Gray J., Kumar R., Manocha D. GPUTeraSort: high performance graphics co-processor sorting for large database management,// SIGMOD, 2006,
3. Govindaraju N., Lloyd B., Wang W., Lin M., Manocha D. Fast computation of database operations using graphics processors. SIGMOD, 2004
4. NVIDIA CUDA Compute Unified Device Architecture // NVIDIA corp,
5. Bingsheng He et al. Relational Joins on Graphics Processors.
6. Bingsheng He, Mian Lu, Ke Yang, Rui Fang, Naga K, Govindaraju, Qiong Luo, Pedro V. Sander. Relational Query Co-Processing on Graphics Processors, TODS Dec 2009,
7. Peter Bakkum, Kevin Skadron. Accelerating SQL Database Operations on a GPU with CUDA, Department of Computer Science University of Virginia.
8. David Kirk / NVIDIA and Wen-mei Hwu // IAP09 CUDA@MIT (6,963) course
9. Shubhabrata Sengupta, Mark Harris, Yao Zhang, John D. Owens. Scan Primitives for GPU Computing.
10. Mark Harris, Shubhabrata Sengupta, Davis John D. Owens, GPU Gems 3.
11. Wenbin Fang et al. Database Compression on Graphics Processors.
12. Bingsheng He, Wenbin Fang, Qiong Luo et al. A MapReduce Framework on Graphics Processors.
13. Кормен Т. и др. Алгоритмы: построение и анализ. Изд. дом Вильямс, 2007.
Материал поступил в редколлегию 15.10.2010
D. A. Lyfar'
PARALLEL GPU ALGORITHMS OF RELATIONAL DATABASE PROCESSING
This work describes set of parallel algorithms of relational database processing on GPU: conditional SELECT, aggregations (MIN, MAX, COUNT for integer types) and partially implemented ORDER BY operator for integer types. Comparison of performance GPU and CPU processors and pro and contra for using GPU on given task provided. Keywords: GPU, parallel algorithms, DBMS.
