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

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

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

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

Итак, ниже мы видим несложное определение класса, содержащее три целочисленных свойства 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; 
}

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

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()
}

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

Подобных издержек можно избежать, если воспользоваться реляционным представлением тех же самых данных в Cache. Изменим код таким образом, чтобы в цикле не создавать и сохранять экземпляры классов, а создавать их аналоги с помощью оператора 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))
}

Результат выполнения этого кода показал, что если избавивиться от накладных расходов, связанных с объектным подходом, время добавления одного миллиона объектов сократится более чем в два раза и составит 233.045 секунды (3 минуты 53 секунды). Кроме того, дополнительных расходов, связанных с проверкой ограничений, созданием индексов и т.п. можно избежать, используя директивы %NOLOCK, %NOCHECK, %NOINDEX (INSERT %NOLOCK, %NOCHECK, %NOINDEX …). Если и после этого производительность не окажется приемлемой, то можно воспользоваться возможностью прямого доступа к хранимым структурам Cache. Как известно, данные в Cache логически хранятся в виде разреженных многомерных массивов. Количество измерений этих массивов не ограничено, и не требуется заранее определять максимальный размер. Поведение массивов в памяти ничем не отличается от поведения массивов, сохраняемых на диске. Все, что нужно сделать, для того чтобы конкретный массив стал хранимой структурой – это добавить перед именем массива символ "^". Например, следующий код ^ myArray(1, "red", -4) = "green" говорит о том, что в массиве myArray в «ячейке» с индексами (1, "red", -4) хранится значение «green». Важно отметить, что в качестве индексов в Cache могут выступать целые числа, дробные числа, строки.

Если вернуться к примеру загрузки данных, то создать набор экземпляров класса Temp.A можно и с помощью прямого доступа к глобалам. Это связано с тем, что в Cache как объектное, так и реляционное представление в основе своей содержат многомерные структуры данных. Стандартная схема хранения в Cache выглядит следующим образом: в глобале данных (в нашем случае это ^ Test.AD) на нулевом уровне хранится идентификатор последнего объекта (^ Test.AD = 99). На первом уровне в индексе хранится сам идентификатор, а в узле – список свойств объекта. Так, например, для объекта с идентификатором 11, у которого свойства a, b и c равны 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. Таким образом, зная структуру хранения объектов в Cache, можно создать набор экземпляров, используя низкоуровневые средства. Рассмотрим следующий код (листинг 4).

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
}

Здесь в цикле создается узел в глобале ^Test.AD, заполняющийся случайными значениями, а также формируются индексы в глобале ^Test.AI. После создания очередного "объекта" счетчик количества объектов увеличивается на единицу. Благодаря использованию прямого доступа время загрузки уменьшилось до 98 с. Однако, это не предел для оптимизации. С алгоритмической точки зрения оказывается излишним увеличение в цикле счетчика объектов. Его можно вынести вне конструкции for и избавиться от N - 1 дополнительных обращений к глобалу ^Test.AD. Тогда код будет выглядеть следующим образом (листинг 5), а время выполнения уменьшится до 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

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

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

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

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

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

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

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

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

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

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    }

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

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

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

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

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;
}

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

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

Однако в данном коде проводится довольно долгая операция разбиения строки с помощью операции $Рiece. В состав новой версии Cache 5.1 будет включена пара функций $listFromString и $listToString, которые сделают процесс преобразования "строка <-> список" более производительным. В среднем в данном коде замена парсинга строки и последующей сборки списка при применении функции $listFromString может сэкономить до 10% времени. Дополнительный прирост производительности достигается не построчным чтением файла, а блочным, что уменьшает количество обращений к диску.

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

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

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

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

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

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

Технология Клиент-Сервер 2004'3

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

Авторы: Александр Чеснавский
InterSystems

Технология Клиент-Сервер 2004'3

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

Авторы: Александр Чеснавский InterSystems

Авторы: Александр Чеснавский
InterSystems