Сравнение IMS DB и DB2

1. Сравнение IMS DB и DB2 for z/OS
при использовании в DB2
OLTP системах
Часть I
Эффективность
Григорий Власов
5 ноября 2014 г.
1 Введение
IBM имеет две СУБД для z/OS, IMS (далее DB1), и DB2 (далее DB2/Z)
поэтому вопрос сравнения и поиска области применимости иногда стоит
остро. Можно делая выбор судить по косвенным признакам. Для DB1 су-
ществуют официально опубликованные результаты нагрузочного тестиро-
вания модели финансового приложения с полным описанием, для DB2/Z
существуют различные vs материалы, указывающие на ее производительность
в составе решений, но найти выделенный документ посвященный произво-
DB1 дительности DB2/Z не удалось.
Но хотелось бы понять, каким способом, за счёт чего, DB1 в частности, и
IMS в целом, получают такие результаты. Для этого придётся рассмотреть
архитектуру обеих систем с точки зрения достижения высокой эффективно-
сти. Под эффективностью понимается отношение количества выполненной
работы к затраченным на эту работу ресурсам. Под ресурсами понимают-
ся процессоры общего назначения System z GP, General Processor, а так же
ZiiP и ZaaP, в отличие от процессоров SAP. Далее под процессорами общего
назначения будут пониматься и GP, и Ziip/ZaaP процессоры.
2 Особенности OLTP систем
• все запросы к данным известны до запуска системы;
• большое количество простых небольших запросов, поступающих асин-
хронно, преимущественно на изменение и на вставку данных, с вы-
сокими требованиями по времени отклика, и высокой вероятностью
конфликта по доступу нескольких транзакций к одному ресурсу (на-
пример, синтетические счета), при чём изменяется как правило часть
одной записи, реже целая запись (например, остатки по счёту);
• небольшое количество регламентных запросов на доступ к большим
массивам данных в основном последовательно и на чтение (статисти-
ческие отчёты, операции закрытия опер. дня, и т.д.), время допусти-
мое на выполнение регламентных запросов как правило на по рядки
больше времени, допустимого на выполнение асинхронных запросов;
1

2. • высокие требования по ведению аудита работы, поскольку система
имеет дело с финансовой информацией, и более того, создаёт первич-
ные данные, которые в будущем могут многократно обрабатываться
(в разных аналитических системах).
2.1 Краткие выводы, вытекающие из особенностей
• Запросы на доступ к данным можно создать и оптимизировать за-
ранее, включая оптимизацию модели данных и физических структур
данных;
• высокие требования к качеству исполнения асинхронных запросов и
интенсивность их применения требуют DB2
тщательности их разработки;
• возможность быстро адресовать нужную запись с наименьшими на-
кладными расходами, и быстро произвести её обработку с наимень-
шим временем на блокирование записи для достижения высокой сте-
пени параллелизма;
• обработка каждым запросом важной первичной финансовой инфор-
мации требует отсутствия взаимного влияния параллельно выполня-
ющихся запросов, другими словами, должна обеспечиваться макси-
мальная изоляция параллельно выполняющихся запросов и обработки
данных;
• необходимо предусматривать средства всестороннего аудита проводи-
мых операций vs с записями с наименьшими накладными расходами и
минимальным влиянием на проводимые операции с записями.
DB1 3 Различие в работе с DASD и Main Storage
3.1 Различие в методах доступа
DB2/Z для хранения данных использует VSAM LDS. Это по сути поток
байт, не имеющий смысла с точки зрения бизнес-логики, читается с дис-
ка и отдаётся DB2/Z, и собирается в логическую запись уже на ресурсах
процессоров общего назначения, используя метаданные. Контролировать с
точки зрения бизнес-логики размещение данных в LDS невозможно. Это
повышает использование процессоров общего назначения.
DB1 использует для хранения данных ESDS, KSDS и OSAM. Описание
физической структуры данных позволяет подобрать физические парамет-
ры хранения исходя из потребностей бизнес-логики. Соответствующая ка-
нальная программа считывает с устройства в память порцию данных име-
ющую логическое значение. Описание здесь:
• DEDB design guidelines
• Parts of a DEDB area
• How HDAM and PHDAM records are stored
• Designing full-function databases
Вывод: при работе с данными на внешних дисках DB1 в большей степени
использует канальную подсистему с её процессорами и программами, и в
меньшей степени процессоры общего назначения.
2

3. 3.2 Различие в работе с метаданными
DB2/Z хранит все метаданные в каталоге (и часть в Directory), который
представляет собой набор таблиц, данные из которых извлекаются SQL за-
просами. Работа с метаданными происходит полностью с использованием
ресурсов процессоров общего назначения.
DB1 ведёт следующие уровни метаданных:
• физическое представление данных;
• логическое представление данных.
Описание метаданных выполняется в макросах ассемблера, которые компи-
лируются в загрузочный формат, или с помощью DB2
команд dynamic resource
definition, результат работы которых тот же загрузочный формат.
Физическое представление данных (DBD, Database Description) опи-
сывает формат и порядок хранения данных на диске, описывает связи меж-
ду объектами и определяет соответствующий набор указателей для связы-
вания объектов.Связь объектов между собой на физическом уровне может
быть представлена в виде графа.
Логическое представление данных (PSB, Program Specification Block)
определяет для конкретной программы:
• область видимости данных;
• окончательную vs (и только иерархическую) структуру связи объектов
DB1 между собой, являющуюся подмножеством графа;
• тип разрешённых над данными действий (вставка, удаление, измене-
ние, чтение).
Application Control Block. Для ускорения работы с метаданными DBD
и PSB объединяются в один бинарный модуль, который динамически лин-
куется с IMS.
Таким образом метаданные загружаются и используются во внутреннем
представлении программы, что это позволяет устранить любые задержки
при обращении к метаданным и значительно снизить загрузку процессоров
общего назначения.
Вывод: при использовании DB1 на управление метаданными тратятся
минимальные ресурсы процессоров общего назначения. При использовании
DB2/Z для управления метаданными используются исключительно ресур-
сы процессоров общего назначения.
3.3 Различие в работе с оперативной памятью
DB2/Z использует Buffer Manager, являющийся частью DBAS1, для
управления содержимым пулов оперативной памяти, выделенной под дан-
ные. Эта компонента работает на процессорах общего назначения. Размер
1Database Service Address Space
3

4. страниц для обмена с пулами фиксирован, и составляет 4К, 8К, 16К, 32К,
что может привести к не самому эффективному использованию памяти.
DB1 использует, буферы VSAM, которые управляются канальными
программами, с использованием специализированного процессора вво-
да/вывода,2 не используя ресурсы процессоров общего назначения, что сни-
жает требование к количеству процессоров и лицензий ПО. При использо-
вании OSAM размер блока для обмена с памятью задаётся произвольно в
пределах от 18 до 32768 Bytes, что позволяет более гибко управлять памя-
тью и точно согласовывать размер записи на диске с её логическим содер-
жанием, экономя дисковое пространство DB2
и операции I/O.
Вывод: управление пулами буферов в DB2/Z происходит с использова-
нием ресурсов процессоров общего назначения.Управление памятью в DB1
возможно организовать более гибко, что позволит экономить как дисковое
пространство, так и оперативную память.
3.4 Различие в упреждающем чтении
DB2/Z использует для упреждающего чтения специальный функционал
в составе адресного пространства DBAS, который исполняется на процессо-
рах общего назначения. Динамическое упреждающее чтение выполняется
для данных при выполнении любого индексного доступа, а так же при до-
ступе к индексам. То есть практически всегда.
DB1 позволяет использовать метод доступа OSAM, созданный специ-
ально для IMS, vs который отличается исполнением упреждающего чтения
DB1 на уровне канальной программы, исполняющейся на специализированном
процессоре ввода/вывода. При этом упреждающее чтение выполняется в
случае обнаружения последовательности в работе с данными, и при слу-
чайном доступе к данным не используется.
Вывод: при использовании DB1 для организации упреждающего чтения
не используются ресурсы процессоров общего назначения. Само упреждаю-
щее чтение используется только при фактическом осуществлении последо-
вательного доступа к данным, при случайном доступе к данным упрежда-
ющее чтение не используется, что позволяет не считывать с диска в память
невостребованные данные.
4 Различие в работе с данными
4.1 Различие в адресации данных
Перед началом выполнения любых действий с записью необходимо вы-
полнить адресацию — преобразовать ключ записи в её физический адрес.
Это, пожалуй, самая распространённая операция в СУБД. DB2/Z может
адресовать нужную запись одним из двух методов:
• последовательное сканирование таблицы целиком;
• индексный доступ.
2VSAM Demistified, стр. 154
4

5. Индекс — отдельный самостоятельный объект базы данных.Структура ин-
декса может быть организована по B-Tree структуре (стр 22), или индекс
может быть организован по hash функци.При преобразовании ключа записи
в адрес конкретной записи сперва выполняется доступ к объекту индекса,
затем осуществляется доступ к требуемой записи. В случае древовидного
индекса с ростом количества данных (как самих данных так и размеров
индексов) время доступа к нужному элементу данных не будет оставаться
постоянным, будет расти, в том числе и по причине увеличения глубины
дерева индекса, что будет требовать большего количества операций для
доступа к нужным данным. К тому же индекс требует обслуживания ад-
министратором, как объект базы данных.
DB2
При использовании DB1 в составе OLTP системы не используется ин-
дексный доступ, вместо этого используется модуль рандомизации, для раз-
ных типов баз данных. Одной из очевидных задач этого модуля является
преобразование ключа записи в её физический адрес. Эта операция зани-
мает неизменное время. Размер модуля рандомизации может быть разный,
конкретный размер модуля, использовавшегося в нагрузочном тестирова-
нии карточного процессинга составляет 31 ассемблерную инструкцию, раз-
мер после компиляции и связывания равен 96 байтам. Очевидно, что такой
подход никак не может сравниваться с индексным подходом, применяемым
в РСУБД, в том числе в DB2/Z, с точки зрения эффективности. Это про-
сто несопоставимые сущности. А так как операция адресации применяется
к каждой записи, с которой работает СУБД, хоть на чтение, хоть на изме-
нение, хоть на запись, то есть это самая распространённая операция, то тем
больше разрыв в vs эффективности адресации записи между DB1 и DB2/Z.
DB1 Одна из особенностей модуля рандомизации — неизменность времени адре-
сации.
Но модуль рандомизации может быть чрезвычайно полезным и в дру-
гих случаях, например, в операции закрытия банковского дня. Если дан-
ные в базе разбиты на отдельные разделы (в IMS DB в типе базы DEDB
эти разделы называются Area, аналог в DB2/Z — партиция), то можно ор-
ганизовать параллельную работу программы закрытия банковского дня,
в несколько потоков, когда каждый поток программы работает со своей
партицией. Для этого используют логику работы рандомайзера. В случае
“прямой” работы рандомайзер получает на вход ключ записи, и отдаёт на
выход номер партиции и адрес записи внутри партиции. При закрытии бан-
ковского дня выполняется обратная операция — каждый поток программы
закрытия получает свой номер партиции для работы, и используя логи-
ку, используемую при создании модуля рандомизации выполняет обратное
преобразование номера партиции (Area) в последовательность ключей за-
писей, которые хранятся в этой партиции. Таким образом обеспечивается
работа каждого потока программы закрытия банковского дня в рамках од-
ной партиции, при том обеспечивается самым эффективным образом, без
использования индексного доступа, как в DB2/Z.
В целом такой подход обеспечивает следующие преимущества:
• чрезвычайно высокая скорость работы по адресации записи при чрез-
вычайно низких затратах процессорного времени;
• отсутствие операций ввода-вывода;
• возможность организации параллельного и эффективного исполнения
5

6. таких задач как закрытие банковского дня, при чём на очень больших
объёмах данных в крупнейших банках мира такая операция занимает
порядка минут, или даже одной минуты, в то время как такая же
задача на РСУБД, в том числе на DB2/Z выполняется не менее 4
часов.
Но такой подход имеет и свои недостатки. Если предложение “create table” и
“create index” в DB2/Z может выполнить каждый, то спроектировать и на-
писать модуль рандомизации на HLASM требует навыков системного про-
граммирования и архитектурных знаний.
Вывод: DB1 может гарантировать постоянное DB2
и неизменное время до-
ступа к каждому элементу данных, основанное на неизменности структу-
ры данных и связанной с этим неизменности количество операций, необхо-
димых для извлечения данных.3 При этом затраты ресурсов на доступ к
структуре данных в DB1 не сопоставимы с затратами на доступ к данным
в DB2/Z.
4.2 Доступ к логически связанным элементам
В DB2/Z используется стандартный подход РСУБД, когда список логи-
чески связанных элементов получается методом умножения множеств. Это
всегда происходит с использованием ресурсов процессоров общего назначе-
ния. Существуют разные типы операций для соединения логически связан-
ных таблици разные vs технические реализации (Nested Loop Join, Hash Join,
DB1 Merge Join), но всегда это выполняется на основных процессорах. Зачастую
производительность операций логического соединения данных является уз-
ким местом с точки зрения производительности.
В DB1 логическая связь между данными осуществляется хранением ад-
реса связываемого элемента в префиксе сегмента.Таким образом для полу-
чения логически связанных элементов не используются ресурсы процессо-
ров общего назначения, что снижает требование к аппаратному обеспече-
нию и количеству лицензий ПО.
Вывод: при необходимости работы с логически связанными элементами
DB1 использует исключительно низкие затраты ресурсов процессоров и
обеспечивает низкое время доступа к данным.
3При использовании правильного модуля рандомизации с корректными параметрами.
6