CC BY
20
УДК 004.651.4
А.М. Бородин, С.В. Поршнев
О ПАРАЛЛЕЛЬНОМ ПОСТРОЕНИИ ПРОСТРАНСТВЕННЫХ ИНДЕКСОВ ОСНОВНОЙ ПАМЯТИ В OLAP-СИСТЕМАХ
В [1] рассмотрены вопросы построения OLAP-систем на основе индексирования методом R-дерева в основной памяти (in-memory indexing [2]). Данная работа опирается на открытую программную библиотеку «Индексирование многомерных классифицированных данных» [3] (далее - ИМДК), в которой реализованы основные механизмы индексирования данных и построения различных аналитических вычислений.
В последние несколько десятилетий производительность вычислительных средств увеличивалась за счет увеличения тактовой частоты центральных процессоров. Многопроцессорные системы были распространены в сегменте серверных компьютеров, однако рабочие станции и мобильные устройства редко обладали большим количеством центральных процессорных устройств. В областях, тесно связанных с большим количеством арифметических операций, получила распространение SIMD архитектура (Single Instruction Multiple Data) [4] и более удобная в программировании SIMT технология (SIMD + Multitasking) [4]. При этом необходимо отметить, что данный подход ориентирован на выполнение большого количества арифметических операций над относительно небольшим количеством данных, что не подходит для решения задач построения OLAP-систем, в которых, напротив, требуется выполнение относительно небольшого количества арифметических операций над большим объемом данных.
Принимая во внимание, что повышение производительности компьютеров в последние годы осуществляется за счет увеличения количества процессоров в вычислительной системе, становится очевидной необходимость разработки подходов, ориентированных на использование технологий параллельного программирования не только при разработке серверных приложений, но и при создании программного обеспечения, ориентированного на работу на рабочих станциях, ноутбуках, нетбуках, коммуникаторах.
В статье описан подход, ориентированный на использование индексов основной памяти, созда-
ваемых в библиотеке ИМДК. Показано, что предложенный подход оказывается более рациональным при реализации аналитических вычислений на клиентской, но не серверной стороне, которая в данном случае представляет собой хранилище данных.
Особенности параллельной обработки данных при построении индекса
Для построения индекса на серверных системах перед началом работы с данными применяются алгоритмы массовой загрузки (bulk loading) [5], позволяющие построить индекс, оптимальный с точки зрения скорости проведения вычислений. Построенный индекс обновляется при изменении данных, однако, при нормальной работе он перестраивается крайне редко. Когда речь идет о клиентской ЭВМ и хранении индекса в основной, а не в дисковой памяти компьютера, построение индексов всех наборов данных оказывается проблематичным, поскольку пользователь запускает приложение, работает с определенными наборами данных, после чего закрывает приложение. Данные индексирования, с которыми работал пользователь, при этом теряются. Таким образом, производительность работы вычислительной системы оказывается зависящей не только от скорости расчетов, но и от времени загрузки данных.
Анализ алгоритмов массовой загрузки показывает, что они достаточно легко распараллеливаются на несколько процессоров. Основное требование, обеспечивающее работоспособность этих алгоритмов, - наличие одновременно всех данных, которые будут индексироваться. В то же время получение необходимых данных (в большинстве случаев — это передача информации по сети) занимает время. Алгоритмы динамического обновления (в данном случае речь идет о вставке записей в индекс), напротив, позволяют начинать построение индекса сразу после загрузки небольшого количество данных, т. е. процесс получения данных проходит одновременно с процессом построения индекса. Таким образом, ценой отно-
4-
Вычислительные машины и программное обеспечение
сительно незначительного снижения скорости проведения расчетов потенциально существует возможность ускорить старт системы, сократив время от запроса анализа данных со стороны пользователя до получения готового индекса со всеми необходимыми данными.
Ограничивающими факторами при получении данных являются как скорость работы системы хранения данных, так и пропускная способность сети передачи данных. В условиях, когда скорость получения данных является узким местом системы, организация процедуры построения индекса параллельно с загрузкой данных обеспечивает готовность индекса к использованию практически сразу после загрузки последней строки данных. Однако время последовательного построения индекса может превышать время получения данных.
Для решения данной проблемы представляется рациональным использовать вычислительные мощности нескольких центральных процессоров, доступных компьютеру. Далее высказанная идея будет проиллюстрирована на примере синхронизации древовидного индекса.
Синхронизация древовидного индекса
R*-дерево [6] является основной индексирующей структурой программной библиотеки ИМДК.
Процесс вставки записи в древовидный индекс проходит в два основных этапа. Первый этап -поиск листового узла дерева, в который необхо-
димо вставить запись. При этом рассмотрение каждого узла от корневого до узлового сопровождается установкой блокировки (Reader-Writer Lock [7]) чтения узла для того, чтобы из соседних потоков рассматриваемый узел не мог быть изменен (первая строка рис. 1).
Далее, после того как узел найден, необходимо установить блокировки на запись на все узлы дерева, т. к. вставка в большинстве случаев вызовет изменение во внутренних страницах индекса (вторая строка рис. 1).
Возможные конфликты синхронизации иллюстрирует третья строка рис. 1, на которой представлена ситуация, когда корневой узел заблокирован в режиме чтения R3, в то время как идет подъем по дереву двух блокировок на запись W1 и W2. Блокировки W1 и W2 не могут занять корневой узел, т. к. он читается R3. Аналогично, R3 не может занять ни одного из нижележащих узлов, т. к. они заняты W1 или W2. Отметим, что в данном примере совершенно не важно, является ли указанный узел корневым для всего индекса или лишь для приведенного подграфа - части большей, непоказанной индексирующей структуры.
Для разрешения данного конфликта необходимо, чтобы R3 была снята c корневой страницы до того как R3 будет установлена на какой-либо выбранный нижележащий узел.
Соответственно, если в алгоритме вставки insert (две версии алгоритма детально описаны в [6, 8]), использующем блокировку вставки R3, для продолжения поиска места в дереве для вставляе-
Рис. 1. Блокировки в индексирующей структуре данных
мой записи был выбран к рассмотрению узел X, который на данный момент занят блокировкой на запись W1, в дальнейшем нам необходимо сохранить пригодность данного узла X для продолжения алгоритма insert.
Ввиду того, что происходит заполнение индекса данными, мы можем гарантировать, что на данном этапе записи из индекса не удаляются, и вставленные листовые записи не изменяются. Для классического R-дерева [8] этого оказывается вполне достаточно, однако R*-дерево применяет дополнительный алгоритм оптимизации индексирующей структуры, называемый force reinsert, поэтому на определенном этапе вставки данных этот алгоритм может применить удаление и повторную вставку части данных, с целью более оптимального их расположения в индексе.
Для того чтобы не допустить подобной ситуации, необходимо до снятия блокировки R3 установить узлу X признак, запрещающий применение на нем алгоритма reinsert. Далее, блокировка R3 снимается с корневой страницы, в определенный момент устанавливается на X, после чего запрет на reinsert снимается. Данный признак должен быть организован в виде инкрементального счетчика запретов, ввиду того, что вполне возможна одновременная установка нескольких запретов reinsert на один и тот же узел несколькими перемещающимися блокировками.
Необходимо отметить, что при тестировании ситуация конфликта запрета reinsert и признака запрета блокировки ни разу не была воспроизведена, что свидетельствует о ее достаточно редком
проявлении. Однако она теоретически возможна, и без применения описанного механизма синхронизации приведет к непредсказуемым последствиям, результатом которых, в лучшем случае, будет разрушение индексирующей структуры, а, в худшем, - расчет системой некорректных агрегатных значений при использовании индекса.
Таким образом, единственный недостаток данного подхода связан с необходимостью при вставке каждой записи получать блокировку записи на корневую страницу, которая в каждый момент времени, будучи единственной, является основным ресурсом, блокировка которого будет уменьшать производительность синхронизации при многопоточной работе с индексом.
Балансировка параллельных загрузок
При получении данных к индексированию поток записей группируется блоками по 8192 записи. Каждый такой блок является заданием для потока загрузки данных, поэтому можно воспользоваться системным пулом потоков для создания потоков, которые будут выполнять эти задания. Однако с целью оптимизации синхронизационных потерь количество данных потоков не должно значительно превышать количество логических ядер процессоров на ЭВМ системы. В случае работы на однопроцессорной системе этот поток должен быть один. В случае работы на многопроцессорной системе, как показали проведенные эксперименты, наиболее эффективна стратегия использования на 50 % большего количества потоков загрузки, чем количество ядер процессоров.
Рис. 2. Зависимость времени загрузки данных от степени параллелизма
4
Вычислительные машины и программное обеспечение^
В условиях, когда необходимо загружать несколько разных наборов данных, необходимо равномерно распределять между разными индексами количество потоков, выполняющих загрузку, что позволяет максимально освободиться от блокировок на основной разделяемый ресурс каждого из индексов - корневую страницу.
Экспериментальное тестирование подхода
Для проведения эксперимента была реализована синхронизированная версия программной библиотеки ИМДК. Загружались данные из MS SQL Server, связь с которым осуществлялась через 100 Мбит/с Ethernet. Загружаемые данные имели один атрибут типа decimal и были классифицированы по двенадцати измерениям. При загрузке 4 млн записей, загрузка на одном процессоре в среднем заняла 182 с, на двух процессорах - 107 с, на четырех - 83 с. При загрузке двух аналогичных по структуре наборов данных объе-
мом 2 млн записей время загрузки на одном процессоре составило 185 с, на двух процессорах -92 с и на четырех — 71 с. Данные представлены в виде графика на рис. 2.
Небольшое замедление однопроцессорной загрузки при разделении набора данных на два, с нашей точки зрения, связано с тем, что СУБД параллельно читала два физически разнесенных набора данных. В этих условиях, несмотря на то, что поток загрузки был один, он переключался между блоками загрузки различных наборов данных.
Таким образом, предложенный способ загрузки данных достаточно хорошо масштабируется и, как следствие, использование технологий параллельного программирования значительно ускоряет работу системы. В этой связи в настоящее время осуществляется перенос библиотеки ИМДК на SIMT архитектуру.
СПИСОК ЛИТЕРАТУРЫ
1. Бородин, А.М. Сравнительный анализ возможностей и скорости обработки многомерных данных программными средствами бизнес-аналитики на основе индексирующих структур основной памяти [Текст]/ А.М. Бородин, С.В. Поршнев//Научно-технические ведомости СПбГПУ. Сер. Информатика, Телекоммуникации, Управление.-2010.-№ 1.-С. 99-102.
2. Analysis Services in VertiPaq mode [Электронный ресурс]/http://technet.microsoft.com/ru-ru/library/ ee637273(SQL.105).aspx
3. Рекламно-техническое описание «Программная библиотека «Индексирование многомерных классифицированных данных» 45392457.00084-01 99 01. Инвентарный номер ВНИТИЦ 50200900990 [Текст] // Св. о рег эл. ресурса № 14197 ОФЭРНИО.
4. Таненбаум, Э. Архитектура компьютера [Текст]/Э. Таненбаум.-СПб.: Питер, 2007.-5-е изд.-848 с.
5. Бородин, А.М Использование нространствен-ных индексов для обработки аналитических запросов и агрегирования многомерных данных в ИАС [Текст]/А.М Бородин, С.В. Поршнев, М.А. Сидоров// Изв. Томского политехнического ун-та.-2008.-№ 5. -С. 64-86.
6. Beckmann, N. The R*-tree: An Efficient and Robust Access Method for Points and Rectangles [Текст]/№ Beckmann, H.-P. Kriegel, R. Schneider [et al.]//Praktuche Informatlk.-Universitaet Bremen, 1991. -С. 322-331.
7. Ramakrishnan, R. Database Management Systems [Текст]Ж. Ramakrishnan, J.Gehrke.-McGraw-Hill,Wisconsin.-2002.-899 с.
8. Guttman, A. R-Trees: A Dynamic Index Structure for Spatial Searching [Текст]/А Guttman//SIGMOD Conf.-1984.-Q 47-57.
УДК 004.415.2.043
Л.М. Курочкин
ВОПРОСЫ ИНТЕГРАЦИИ ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ
CAD СИСТЕМ ПРЕДПРИЯТИЯ
Повышение эффективности производства рованного проектирования (CAD), инженерных
невозможно без интеграции информационных расчетов (CAE), автоматизированное производ-
систем предприятия. Центральное звено инте- ство (CAM). Во время реализации нового проекта
грированной системы - подсистемы автоматизи- процессы проектирования, инженерных расчетов
