IMS DB vs DB2 for z/OS
0 likes447 views
Документ представляет собой сравнение двух систем управления базами данных для платформы z/OS: IMS и DB2, акцентируя внимание на их архитектурных отличиях и эффективности в условиях OLTP. Основное внимание уделяется различиям в доступе к данным, обработке метаданных и управлении оперативной памятью, показывая, что IMS (DB1) обеспечивает большую производительность и эффективность работы с данными по сравнению с DB2 (DB2/z). В итоге документ подчеркивает важность и преимущества использования IMS в финансовых системах, требующих высокой скорости обработки и минимальных затрат на ресурсы.
IMS DB vs DB2 for z/OS
- 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