Базы данных - Cache - статьи
       

Оптимизация загрузки данных в Caché


Александр Чеснавский,

Системы управления базами данных являются неотъемлемой частью любой автоматизированной информационной системы, обеспечивая создание базы данных, поддержание ее в актуальном состоянии и предоставление эффективного доступа пользователей и их приложений к содержащейся в БД информации. В связи с этим весьма актуальной становится проблема оптимизации приложений для более производительного выполнения таких операций, как загрузка и поиск данных. Данная статья содержит набор практических рекомендаций по улучшению систем, созданных на основе СУБД Caché. Основной акцент сделан на проблеме массовой загрузки данных (“bulk load”).

Прежде всего хотелось бы отметить, что СУБД Caché поддерживает несколько моделей данных – объектную, реляционную и иерархическую, благодаря чему открывается большой простор для способов загрузки данных. В одних случаях нам удобно(и, возможно, достаточно) создавать наборы данных с помощью объектного или реляционного подхода, для достижения же максимальной производительности следует использовать возможности прямого доступа к глобальным структурам Caché.

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

Итак, ниже мы видим несложное определение класса, содержащее три целочисленных свойства a, b и c, а также стандартные индексы aIN, bIN и cIN , определенные для свойств a, b и c соответственно.

Class Temp.A Extends %Persistent [ ClassType = persistent, ProcedureBlock ] { Property a As %Integer; Property b As %Integer; Property c As %Integer;

Index aIN On a; Index bIN On b; Index cIN On c; }

Листинг 1 Определение класса Temp.A

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

for i=1:1:N { Set obj=##class(Test.A).%New() Set obj.a=$Random(1000) Set obj.b=$Random(1000) Set obj.c=$Random(1000) Do obj.%Save() }

Листинг 2 Загрузка данных на основе объектного подхода



Попробуем выполнить этот код. На моей машине ( Intel Pentium III 800 Mhz ,256М ОЗУ, Microsoft Windows 2000 SP 4, Caché 5.0.5.936.2) этот процесс занял 473.421 секунд (7 минут и 53 секунды). Стоит отметить, что на время загрузки влияют такие факторы, как размер кэша глобалей и программ, журналирование, транзакции, блокировки и т.д. Конкретное влияние этих факторов будет рассмотрено ниже. Если говорить про описанную выше загрузку объектов, то длительность этого процесса можно объяснить накладными расходами на создание объектов и их сохранение, многочисленными проверками и преобразованиями, которые необходимо проводить в рамках объектного подхода.

Подобных издержек можно избежать с использованием реляционного представления тех же самых данных в Caché. Изменим код таким образом, чтобы в цикле не инстанцировать и сохранять экземпляры классов, а создавать их аналоги с помощью оператора SQL INSERT.

for i=1:1:N { Set val1=$Random(1000) Set val2=$Random(1000) Set val3=$Random(1000) &sql(INSERT INTO Test.A (a, b, c) VALUES (:val1,:val2,:val3) ) }

Листинг 3. Загрузка данных на основе SQL-подхода

Результат выполнения этого кода показал, что избавившись от накладных расходов, связанных с объектным подходом, время добавления одного миллиона объектов сократилось более чем в два раза и составило 233.045 секунды (3 минуты 53 секунды). Кроме того, дополнительных расходов, связанных с проверкой ограничений, созданием индексов и т.п. можно избежать, используя директивы %NOLOCK, %NOCHECK, %NOINDEX (INSERT %NOLOCK,%NOCHECK,%NOINDEX …). Если данная производительность не является достаточной, то существует возможность прямого доступа к хранимым структурам Caché. Как известно, данные в Caché логически хранятся в виде разреженных многомерных массивов.


Количество измерений этих массивов не ограничено, и не требуется заранее определять максимальную размерность. Поведение массивов в памяти ничем не отличается от поведения массивов, сохраняемых на диске. Все, что нужно сделать, для того чтобы конкретный массив стал хранимой структурой - это добавить перед именем массива знак ^ («циркумфлекс»). Например, следующий код ^ myArray (1,” red ”,-4)=”green” говорит о том, что в массиве (хранимые массивы в Caché называются глобалами, в отличие от локалей – массивов в памяти) myArray в «ячейке» с индексами ( 1, “red”, -4 ) хранится значение “green”. Важно отметить, что в качестве индексов в Caché могут выступать целые числа, дробные числа, строки.

Если вернуться к примеру загрузки данных, то создать набор экземпляров класса Temp. A можно и с помощью прямого доступа к глобалам. Это связано с тем, что в Caché как классовое представление, так и реляционное в основе своей содержат многомерные структуры данных. Стандартная схема хранения в Caché выглядит следующим образом: в глобале данных (в нашем случае это ^ Test . AD) на нулевом уровне хранится идентификатор последнего объекта (^ Test . AD =99). На первом уровне в индексе хранится сам идентификатор, а в узле список свойств объекта. Так, например, для объекта с идентификатором 11, у которого свойства a, b и c равны 1, 2 и 3 соответственно, запись в глобале будет выглядеть следующим образом: ^Test.AD(11)=<<$ListBuild("","1","2","3")>>

Возникает вопрос, почему первый элемент списка является пустым? Он используется для идентификации экземпляров классов-потомков. В нашем случае класс Test . A наследует только от системного класса % Persistent и в схеме хранения определен лишь один класс Test. A, поэтому значение первого элемента списка пустое. Если же определить класс Test. B, являющийся наследником от Test . A , то по умолчанию экземпляры класса Test . B будут хранится в одном глобале с экземплярами класса Test.


A, и для определения класса, к которому принадлежит конкретный экземпляр, и вводится первый элемент в списке.

Кроме того, если в классе определены индексы, то по умолчанию создается структура хранения для индексов (в нашем случае это ^ Test . AI ). Структура этого глобала довольно проста (здесь рассматриваются лишь стандартные индексы): для каждого индекса с именем indexName создается узел в глобале, который выглядит следующим образом: ^Test.AI(" indexName ",value , ID )=.

Здесь value – значение свойства, на которое «настроен» данный индекс в объекте с идентификатором ID. Таким образом, зная структуру хранения объектов в Caché, можно создать набор экземпляров, используя низкоуровневые средства. Рассмотрим следующий код:

for i=1:1:N { Set val1=$Random(1000) Set val2=$Random(1000) Set val3=$Random(1000)

Set ^Test.AD(i)=$ListBuild("",val1,val2,val3) Set ^Test.AI("aIN",val1,i)="" Set ^Test.AI("bIN",val2,i)="" Set ^Test.AI("cIN",val3,i)=""

Set ^Test.AD=i }

Листинг 4. Загрузка данных на основе прямого доступа

Здесь в цикле создается узел в глобале ^Test.AD, который заполняется случайными значениями, а также формируются индексы в глобале ^Test.AI. После создания очередного «объекта» счетчик количества объектов увеличивается на единицу. Благодаря использованию прямого доступа время загрузки уменьшилось до 98 секунд. Однако, это не предел для оптимизации. С алгоритмической точки зрения, оказывается излишним увеличение в цикле счетчика объектов. Его можно вынести вне конструкции for и избавиться от N -1 дополнительных обращений к глобалу ^Test.AD. Тогда код будет выглядеть следующим образом, а время выполнения уменьшится до 85 секунд:

for i=1:1:N { Set val1=$Random(1000) Set val2=$Random(1000) Set val3=$Random(1000)

Set ^Test.AD(i)=$ListBuild("",val1,val2,val3) Set ^Test.AI("aIN",val1,i)="" Set ^Test.AI("bIN",val2,i)="" Set ^Test.AI("cIN",val3,i)="" } Set ^Test.AD=N



Листинг 5. Загрузка данных на основе прямого доступа. Улучшение 1.

Данный код, как и предыдущий, не использует транзакции и блокировки. Более корректным решением было бы использование конструкции TSTART - TCOMMIT, обрамляющие запись в глобал, а также установка соответствующих блокировок. Однако, использование транзакций при массовой загрузке данных снижает скорость записи приблизительно на 40 процентов, и в условиях “bulk load” в ряде случаев можно отказаться от использования связки TSTART - TCOMMIT - TROLLBACK (зачастую при массовой загрузке данных система функционирует как однопользовательская, и необходимо любыми способами достичь максимальной производительности).

Выше уже говорилось, что данные в Caché хранятся в виде многомерных разреженных массивов (глобалов). Однако это лишь логическое представление. На физическом уровне глобалы организованы в виде B *-деревьев, детальное описание которых не является предметом этой статьи. Однако, для создания эффективных алгоритмов записи в глобал следует знать, что наиболее быстро происходит добавление элементов, когда индексы добавляемых элементов упорядочены в лексикографическом порядке (что имеет место в случае заполнения глобала ^Test.AD). При добавлении неупорядоченных элементов происходит частое расщепление блоков, в которых хранятся глобалы, что неизбежно приводит к падению производительности (в нашем случае это формирование индексов в глобале ^Test.AI). Эффективным средством для борьбы с этой проблемой является использование промежуточного буфера в памяти. Запись в глобал происходит через этот буфер. Элементы в нем автоматически упорядочиваются и сбрасываются на диск в лексикографическом порядке, что положительно сказывается на производительности. К счастью, в Caché предусмотрен механизм создания такого буфера с помощью команд $ SORTBEGIN /$ SORTEND . Критический участок кода обрамляется этой конструкцией,и далее работа с глобалами идет также, как и без использования $ SORTBEGIN /$ SORTEND . Таким образом, абсолютно прозрачно для разработчика формируется буфер, который сбрасывает на диск глобалы с уже упорядоченными индексами.


Чтобы использовать эту возможность, необходимо незначительно изменить код:

Set res=$SortBegin(^Test.AI) for i=1:1:N { Set val1=$Random(1000) Set val2=$Random(1000) Set val3=$Random(1000)

Set ^Test.AD(i)=$ListBuild("",val1,val2,val3) Set ^Test.AI("aIN",val1,i)="" Set ^Test.AI("bIN",val2,i)="" Set ^Test.AI("cIN",val3,i)="" } Set ret = $SortEnd(^Temp.AI) Set ^Test.AD=N

Листинг 6. Загрузка данных на основе прямого доступа. Улучшение 2.

Если же говорить о производительности, то выполнение этого кода при N =1000000 занимает порядка 38 секунд, что быстрее варианта без использования связки $ SORTBEGIN /$ SORTEND более чем в два раза.

Последняя стратегия записи в глобал активно использует временные структуры. Поэтому одним из средств увеличения производительности служит настройка размера кэша глобалей. Сама настройка проводится очень просто – необходимо указать новый размер кэша в Редакторе Конфигураций ® Основное. Более интересным представляется определение требуемого размера кэша. Это можно сделать несколькими способами:

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

Во-вторых, с помощью набора утилит для анализа производительности системы (GLOSTAT, PERFMON и другие), входящих в состав Caché. Среди прочей статистики о системе, они содержат информацию об эффективности использования кэша глобалов и программ, с помощью которой можно с большей точностью определить необходимый размер кэша. А благодаря тому, что каждый процесс ( в том числе и тот процесс, в котором мы загружаем данные) является отдельным процессом операционной системы, то появляется возможность дополнительной настройки производительности средствами операционной системы.

Рассмотрим более подробно профилировку программы с помощью утилиты ^%MONLBL. Эта утилита служит для сбора статистики по выполнению программ. Процедура использования этой утилиты (как и многих других утилит сбора статистики) следующая: запустить монитор, выполнить программу, которую требуется проанализировать, получить статистику и остановить монитор.



После запуска утилиты ^% MONLBL предлагается выбрать набор программ для профилировки и набор метрик. Для выбора предоставляется более 50 метрик, среди которых есть метрики, связанные с числом глобальных ссылок (GloRef), операций с глобалами (GloSet, GloKill). Кроме того, есть возможность анализа статистик по обращению к физической организации глобалов в виде B *-дерева (DirBlkRd, UpntBlkRd, BpntBlkRd и другие), функционированию в распределенной среде( NetGloRef, NCaché Hit, NCaché Miss и другие) и т.д.

Для анализа описанной выше программы рассмотрим временные статистики (Time, TotalTime).

После настройки утилиты запустим программу загрузки одного миллиона объектов. Стоит отметить, что при сборе статистики процедура загрузки будет проходить медленнее, что связано с накладными расходами на сбор данных. Отчет, созданный с помощью ^% MONLBL, выглядит следующим образом.

Line Time TotalTime 1 0.000026 0.000026 add(N=1000) public 2 0 0 { 3 0.039753 0.039753 k ^Test.AD 4 0.021115 0.021115 k ^Test.AI 5 0.000165 0.000165 Set ret = $SortBegin(^Test.AI) 6 0.000013 0.000013 for i=1:1:N 7 0 0 { 8 7.349726 7.349726 Set val1=$Random(1000) 9 6.954847 6.954847 Set val2=$Random(1000) 10 6.966766 6.966766 Set val3=$Random(1000) 11 15.408908 15.408908 Set ^Test.AD(i)= $ListBuild("",val1,val2,val3) 12 13.878284 13.878284 Set ^Test.AI("aIN",val1,i)="" 13 11.493729 11.493729 Set ^Test.AI("bIN",val2,i)="" 14 11.358133 11.358133 Set ^Test.AI("cIN",val3,i)="" 15 4.163146 4.163146 } 16 21.203588 21.203588 Set ret = $SortEnd(^Test.AI) 17 0.035609 0.035609 Set ^Test.AD=N 18 0.000029 0.000029 }

Листинг 7 Результат сбора статистики с помощью утилиты ^%MONLBL

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

Еще одна возможность увеличения производительности – отключение журналирования. Это также может в определенной степени увеличить скорость загрузки данных в Caché, однако, как и отказ от использования блокировок и транзакций, требует известной осторожности, т.к.


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

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

Допустим, что в плоском файле с разделителями хранятся данные о компаниях: название, адрес, ключевые цели и т.д. Наша задача – переместить эти данные из плоских файлов в объекты Caché. Для этого создадим описание класса с требуемыми полями (для простоты не будем определять индексы):

Class Test.B Extends %Persistent [ ClassType = persistent, ProcedureBlock ] { Property city As %String; Property company As %String; Property mission As %String; Property state As %String; Property street As %String; }

Листинг 8 Определение класса Temp.B

Для загрузки данных из плоского файла можно предложить следующий код:

Open AFileName Use AFileName Set i = 0 while $ZEOF'=-1 { Read result If $ZEOF>-1 { Set i = i + 1 Set ^Test.BD(i) = $ListBuild("",$Piece(result,ADelim,2),$ Piece (result,ADelim,1),$ Piece (result,ADelim,3),$ Piece (result,ADelim,4),$ Piece (result,ADelim,5)) } } Close AFileName Set ^Test.BD=I

Листинг 9 Загрузка данных из файла

Однако, в данном коде проводится довольно долгая операция разбиения строки с помощью операции $piece. В состав новой версии Caché 5.1 будет включена пара функций $listFromString и $listToString, которые сделают процесс преобразования строка «список более производительным. В среднем, в данном коде замена парсинга строки и последующей сборки списка на применение функции $listFromString может сэкономить до 10% времени выполнения.


Дополнительный прирост производительности можно достичь не построчным чтением файла, а блочным, что уменьшит количество обращений к диску.

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

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

Среди способов оптимизации на физическом уровне можно отметить дефрагментацию базы данных (утилита ^GCOMPACT), которая позволяет объединять разрозненные блоки, улучшая характеристики B *-дерева. Однако, здесь нужно помнить следующее правило: дефрагментация положительно сказывается на операциях поиска и отрицательно - на операциях добавления. Тем не менее, требуемого компромисса можно достичь благодаря тому, что утилита ^GCOMPACT позволяет «сжимать» блоки до определенного процентного соотношения (например, 80%).

В алгоритмическом плане может быть полезным использование временной базы данных («In - Memory Database») Caché TEMP. С точки зрения разработчика, эта база данных ничем не отличается от обычных баз данных, однако она полностью хранится в оперативной памяти и не журналируется, за счет чего и достигается большее быстродействие.

Для оптимизации SQL -доступа можно использовать следующие опции:

?  установка параметров Selectivity и ExtentSize, которые используются Caché SQL оптимизатором при составлении планов запросов. Их можно установить либо вручную, либо автоматически с помощью утилиты $system.SQL.TuneTable().



?  Директивы управления Caché SQL оптимизатором %inorder (формирование соединений JOIN именно в том порядке, как они записаны), %full (анализ всех возможных альтернативных планов запроса).

?  Кэширование запросов.

?  Создание хранимых процедур на Caché Object Script . В Caché существует возможность создания хранимых запросов не только на SQL , но и с использованием прямого доступа, что позволяет существенно повысить производительность хранимых процедур. При создании хранимых процедур, основанных на Caché Object Script, может быть полезным анализ сохраненных запросов, описанных в предыдущем пункте.

Итак, в этой статье мы рассмотрели набор рекомендаций для повышения производительности ваших систем на основе СУБД Caché. Безусловно, этот набор далеко неполный, но его можно считать базисом для улучшении своих систем. Необходимо помнить, что исключительно административные и технические улучшения не помогут построить действительно высокопроизводительные системы, так как в основе должна лежать именно алгоритмическая оптимизация. Использовать наилучшие алгоритмы - вот что требуется в первую очередь!


Содержание раздела