Open Library - открытая библиотека учебной информации. Многомерное представление данных

OLTP (обработка транзакций в режиме реального времени) участвует в работе конкретной системы. OLTP характеризуется большим количеством коротких онлайновых транзакций (INSERT, UPDATE, DELETE). Основной упор для OLTP-систем заключается в очень быстрой обработке запросов, обеспечении целостности данных в средах с множественным доступом и эффективности, измеряемой количеством транзакций в секунду. В базе данных OLTP есть подробные и текущие данные, а схема, используемая для хранения транзакционных баз данных, - это модель сущности (обычно 3NF). Он включает в себя Запросы, связанные с индивидуальной записью, например "Обновление электронной почты" в базе данных компании.

OLAP (он-лайн аналитическая обработка) имеет дело с историческими данными или архивными данными. OLAP характеризуется относительно низким объемом транзакций. Запросы часто очень сложны и включают скопления. Для систем OLAP время отклика - это показатель эффективности. Приложения OLAP широко используются методами интеллектуального анализа данных. В базе данных OLAP хранятся агрегированные исторические данные, хранящиеся в многомерных схемах (обычно звездообразная схема). Иногда запрос должен получить доступ к большому количеству данных в записях управления, как то, что было прибылью вашей компании в прошлом году.

Очень короткий ответ:

Различные базы данных имеют разные виды использования. Я не эксперт по базам данных. Когда сомневаюсь, я просто использую SQL.

Короткий ответ:

Рассмотрим два примера сценариев:

Сценарий 1:

Вы строите интернет-магазин/веб-сайт, и хотите иметь возможность:

• хранить пользовательские данные, пароли, предыдущие транзакции...
• хранить актуальные продукты, связанную с ними цену.

Вы хотите найти данные для конкретного пользователя, изменить его имя... В основном выполнять операции INSERT, UPDATE, DELETE для пользовательских данных. То же самое с продуктами и т.д.

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

Сценарий 2:

У вас есть интернет-магазин/веб-сайт, и вы хотите вычислить такие вещи, как

• "общие расходы на деньги для всех пользователей"
• "какой самый продаваемый продукт"

Это относится к области аналитики/бизнес-аналитики, поэтому OLAP, вероятно, более подходит.

Если вы думаете в терминах "Было бы хорошо знать, как/что/сколько"... и включает весь "объект" одного или нескольких видов (например, всех пользователей и большинство продуктов чтобы узнать, сколько всего потрачено), тогда OLAP, вероятно, лучше подходит.

Более длинный ответ:

Конечно, все не так просто. Поэтому мы должны сначала поместить маленькие теги, такие как OLTP и OLAP . Каждая база данных должна оцениваться независимо в конце.

Итак, каково может быть принципиальное различие между OLAP и OLTP?

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

Один из способов - сделать книгу, немного похожую на телефонную книгу. На каждой странице книги мы храним информацию о конкретном пользователе. Теперь, когда это приятно, мы можем легко найти информацию для конкретного пользователя! Просто перейдите на страницу! У нас даже может быть специальная страница в начале, чтобы рассказать нам, на какой странице находятся пользователи, если мы хотим. Но, с другой стороны, если мы хотим найти, скажем, сколько денег потратили все наши пользователи, нам пришлось бы читать каждую страницу, т.е. вся книга! Это будет книга/база данных на основе строк (OLTP). Необязательной страницей в начале будет индекс.

Другой способ использовать большой лист бумаги - сделать бухгалтерскую книгу. Я не бухгалтер, но представьте себе, что у нас будет страница для "расходов", "покупок"... Это хорошо, потому что теперь мы можем очень быстро запросить такие вещи, как "дать мне общий доход" (просто прочитайте "покупки" "). Мы также можем попросить более интересные вещи, такие как" дать мне десятку продуктов, проданных" и все еще иметь приемлемую производительность. Но теперь подумайте, насколько болезненно было бы найти расходы для конкретного пользователя. Вам придется пройти весь список всех расходов и отфильтровать данные этого конкретного пользователя, а затем суммировать их. В основном это означает "прочитать всю книгу". Это будет база данных на основе столбцов (OLAP).

Из этого следует, что :

• Базы данных

OLTP предназначены для использования во многих небольших транзакциях и обычно служат "единственным источником правды".

С другой стороны, базы данных

OLAP более подходят для аналитики, интеллектуального анализа данных, меньше запросов, но обычно они больше (они работают с большим количеством данных).

Это немного более активное участие, чем это, конечно, и что 20 000 футов обзор того, как базы данных отличаются, но это позволяет мне не заблудиться в море акронимов.

Говоря об аббревиатурах:

Разница довольно проста.

OLTP (обработка транзакций в режиме on-line).

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

OLAP (он-лайн аналитическая обработка)

OLAP является частью более широкой категории бизнес-аналитики, которая также включает реляционную базу данных, запись отчетов и интеллектуальную обработку данных. Типичные приложения OLAP включают бизнес-отчетность для продаж, маркетинга, управленческой отчетности, управления бизнес-процессами (BPM), бюджетирования и прогнозирования, финансовой отчетности и аналогичных областей.

OLTP (O n- L ine T ransaction P обработка) vs OLAP ( O n- L ine A nalytical P ) p >

Мы можем разделить IT-системы на транзакционные ( OLTP ) и аналитические ( OLAP ). В общем случае можно предположить, что OLTP системы предоставляют исходные данные хранилищам данных, тогда как системы OLAP помогают анализировать его.

В следующей таблице приведены основные различия между дизайном системы OLTP и OLAP.

Режим оперативной обработки транзакций OLTP (On-Line Transaction Processing) применяется в информационных системах организационного управления для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную нишу.

OLTP

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

В OLTP системах над целевыми БД исполняются целевые транзакции (например, занесение в таблицу записи с параметрами выписанного счета, оприходованной фактуры или любого другого факта), которые изменяют состояние БД и приводят их в соответствие текущему состоянию того фрагмента реального мира, который моделирует БД. Таким образом, основным назначением целевых БД является обработка транзакций.

Подобные системы предназначены для ввода, структурированного хранения и обработки информации в режиме реального времени. OLTP-системы позволяют сформулировать запросы типа: сколько, где и т.п. Предоставляя данные из постоянно синхронизируемых (обновляемых) БД, операционные системы не отслеживают динамику изменения процессов на больших временных промежутках, практически не производят обработку данных (за исключением определенных расчетов) и, что самое важное, не формируют выводы по имеемым данным, оставляя эту функцию лицу, принимающему решение.

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

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

Информационные системы класса OLTP характеризуются следующими особенностями.

Характеристики ИС - информационных систем - класса OLTP

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

Исторически такие системы возникли в первую очередь, поскольку реализовывали потребности в учете, скорости обслуживания, сборе данных и пр. Однако вскоре пришло понимание, что сбор данных - не самоцель и накопленные данные могут быть полезны: из данных можно извлечь информацию.

Стратерия разработки систем

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

• построение отдельных АРМ, предназначенных для обработки групп функционально связанных документов, и тиражирование готовых АРМ на места,
• построение полнофункциональных параметризуемых систем с тиражированием и настройкой по местам. Однако получаемые таким способом системы имели невысокие адаптационные возможности по преодолению динамики предметных областей. Они предъявляли высокие требования к эксплуатационному персоналу и требовали больших накладных расходов на сопровождение.

Относительно недавно начала применяться новая, третья стратегия разработки информационных систем класса OLTP. Ее суть состоит в следующем: тиражируются не готовые системы, а некоторые заготовки и технологический инструмент, позволяющие непосредственно на месте быстро построить/достроить систему с необходимой функциональностью и далее с помощью этого же инструмента ее модифицировать в соответствии с динамикой предметной области

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

Сильно нормализованные модели данных хорошо подходят для OLTP-приложений – On-Line Transaction Processing (OLTP) – приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета͵ заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически всœе запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединœения отношений и от скорости выполнения которых существенно зависит работа приложений.

Другим типом приложений являются OLAP-приложения – On-Line Analitical Processing (OLAP) – приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений – Decision Support System (DSS), хранилищ данных – Data Warehouse, систем интеллектуального анализа данных – Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу «что если…» и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками:

Добавление в систему новых данных происходит относительно редко крупными блоками, к примеру, один раз в месяц или квартал;

Данные, добавленные в систему, как правило, никогда не удаляются;

перед загрузкой данные проходят различные подготовительные процедуры, связанные с приведением их к определœенным форматам;

Запросы к системе являются нерегламентированными и достаточно сложными;

скорость выполнения запросов важна, но не критична.

Базы данных OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся значения этих данных. Физически гиперкуб может быть построен на основе специальной многомерной модели данных – Multidimensional OLAP (MOLAP) или представлен средствами реляционной модели данных – Relational OLAP (ROLAP).

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

Сравнение нормализованных и ненормализованных моделей

Анализ критериев для нормализованных и ненормализованных моделей данных

Соберем воедино результаты анализа критериев, по которым мы хотели оценить влияние логического моделирования данных на качество физических моделей данных и производительность базы данных:

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

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

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

Можно выделить некоторые классы систем, для которых больше подходят сильно или слабо нормализованные модели данных.

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP-приложений (On-Line Transaction Processing (OLTP )- оперативная обработка транзакций ). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В". Проблема заключается в том, что, во-первых, транзакций очень много, во-вторых, выполняются они одновременно (к системе может быть подключено несколько тысяч одновременно работающих пользователей), в-третьих, при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В). Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. В этом случае можно пожертвовать нормализацией для ускорения выполнения подобных запросов.

Другим типом приложений являются так называемые OLAP-приложения (On-Line Analitical Processing (OLAP ) - оперативная аналитическая обработка данных ). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (Decision Support System - DSS ), хранилищ данных (Data Warehouse ), систем интеллектуального анализа данных (Data Mining ). Такие системы предназначены для нахождения зависимостей между данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей), для проведения анализа "что если…". OLAP-приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми их электронных таблиц или из других источников данных. Такие системы характеризуются следующими признаками:

• Добавление в систему новых данных происходит относительно редко крупными блоками (например, раз в квартал загружаются данные по итогам квартальных продаж из OLTP-приложения).
• Данные, добавленные в систему, обычно никогда не удаляются.
• Перед загрузкой данные проходят различные процедуры "очистки", связанные с тем, что в одну систему могут поступать данные из многих источников, имеющих различные форматы представления для одних и тех же понятий, данные могут быть некорректны, ошибочны.
• Запросы к системе являются нерегламентированными и, как правило, достаточно сложными. Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного в результате предыдущего запроса.
• Скорость выполнения запросов важна, но не критична.

Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"

Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP ) или построен средствами реляционной модели данных (ROLAP - Relational OLAP ).

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

Оперативная обработка транзакций (OnLine Transaction Processing - OLTP) - важнейшее средство взаимодействия с информацией, находящейся в внутри «умных» железяк. Между тем, построение сложных, высокопроизводительных OLTP-систем - непростая задача. Многообразие технологий, модные веяния зачастую ставят разработчика в тупик при выборе конкретного решения или заставляют «натягивать» известные технологии на поставленную задачу, что порой ведет к непредсказуемым результатам. Когда в одном проекте фигурирует несколько платформ, задача становится на порядок сложнее.

С точки зрения прикладных задач любая интерактивная система имеет три основных уровня: хранение данных; прикладная логика; представление (интерфейс с конечным пользователем). Соответственно, с точки зрения реализации, система может включать сервер данных, сервер прикладной логики (сервер приложения) и набор интерфейсов для представления информации конечному пользователю. В качестве основы для сервера данных, как правило, используют СУБД SQL-типа, файловые структуры или специальные источники данных. С интерфейсными формами тоже все понятно: можно реализовывать графические интерфейсы, текстовые «зеленые экраны», Web-интерфейсы и т.п. А вот вопрос реализации сервера приложения не так прост, как может показаться на первый взгляд. Если посмотреть на существующие отечественные реализации систем, можно выделить две тенденции:

• логика размещается вместе с интерфейсами («толстый» клиент);
• логика размещается на стороне сервера данных (встречается гораздо чаще).

В последнем случае, как правило, используются СУБД SQL-типа, которые наделены некоторыми функциями поддержки сервера приложения в виде механизма хранимых процедур. Трехзвенная схема при реализации трансформируется в двухзвенную клиент-серверную архитектуру. Для небольших систем это вполне приемлемое решение, однако такой архитектуре присущ ряд недостатков, в том числе ограниченная масштабируемость. Ее реализация, даже на мощных платформах класса S/390, позволяет достичь пиковой производительности не более 200 транзакций в секунду .

В некоторых реализациях разработчики выделяют сервер приложений в самостоятельный компонент. Но эти реализации, как правило, представляют лишь набор прикладных программ, которые не опираются на какие-либо специальные службы, а пользуются стандартными механизмами операционной системы, что, вообще говоря, не выводит систему на иной качественный уровень по сравнению с двухзвенной архитектурой. Это справедливо практически для любой платформы, за исключением AS/400 и VM/ESA, где сами операционные системы являются транзакционным сервером. На других платформах подобная функциональность может быть достигнута только при помощи дополнительных специальных продуктов, которые в числе прочих и будут затронуты в данной статье.

Мозаика технологий

Начиная с платформы ПК, используя на начальных этапах технологии Borland и Microsoft, наша компания реализовала несколько проектов в двухзвенной архитектуре. По мере роста размеров проектов, включения в них нескольких платформ, встал вопрос поиска и оптимизации применяемых технологий для построения систем с необходимыми потребительскими свойствами.

Опробовав различные технологии и инструменты, мы остановили свой выбор на технологиях IBM, предоставляющей широкий спектр открытых аппаратно-программных решений. Учитывая, что мы реализуем OLTP-проекты для заказчиков, которые часто уже применяют технологии Microsoft, Oracle и других компании, возможность совместного использования решений IBM и альтернативных поставщиков была весьма кстати (рис. 1).

Для реализации особо тонких системных моментов мы прибегаем также к программированию на языках С++ или Кобол, однако это занимает не более 1-2% от общего объема работ.

Монитор транзакций IBM CICS

Монитор транзакций CICS (Custom Information Control System), имеющий богатую историю, более чем за 30 лет своего существования стал в своей области лидером. Именно программное обеспечение промежуточного слоя является надежным хребтом для построения OLTP-систем.

Монитор транзакций - достаточно сложный продукт, который привносит функции контроля целостности данных при выполнении операций . Сложная OLTP-система может иметь несколько источников данных (СУБД, файлы и т.д.); монитор транзакций позволяет прикладной программе работать с ними одновременно и изменять их состояние. При этом, если в рамках транзакции хотя бы один источник данных не будет переведен в последующее состояние, то и остальные источники будут возвращены в состояние до начала транзакции. Это гарантирует целостность данных, предотвращает рассогласование данных в источниках. Такая служба отсутствует в большинстве операционных систем. При этом источники данных могут быть как локальными, так и распределенными, находясь на различных серверах и платформах. Если в системе используется монитор транзакций, то со стороны разработчика не требуется ощутимых затрат для поддержки функций контроля целостности на уровне прикладной логики.

Будучи реализован практически для всех основных платформ, CICS позволяет построить сложную распределенную гетерогенную транзакционную среду. CICS использует интерфейс X/Open XA для взаимодействия с различными менеджерами ресурсов и организации интерфейсов с продуктами основных производителей СУБД. Применение монитора транзакций делает систему более масштабируемой по сравнению решениями, «в центр» которых помещена СУБД. Так, на базе стандартных редакций CICS можно строить системы с пиковой производительностью 500 транзакций в секунду, а при помощи специальных версий (например, ПО Transaction Processing Facility, применяемое в системах оперативного резервирования авиабилетов) и с более высокими пиковыми нагрузками.

Заметим, что TPC, отраслевые тесты на пиковую производительность СУБД (www.tpc.org ), проводятся с применением мониторов транзакций, что позволяет получить наилучшие показатели. Почему? Монитор транзакций играет роль «турбонаддува» для СУБД, помимо прочего, ускоряя выполнение SQL-запросов из-за особенностей конструкции как своего ядра, так и интерфейса с СУБД (интерфейс в двухзвенной клиент-серверной архитектуре очень ограничен по производительности). Это позволяет минимизировать время на диспетчеризацию запроса перед его обработкой ядром СУБД. Кроме того, в мониторах транзакций лучше, чем в СУБД, решен вопрос с балансировкой нагрузки .

CICS поддерживает пять типов высокоуровневого взаимодействия между серверами, которые могут быть организованы поверх любых сетевых протоколов (TCP/IP, SNA, NetBIOS и др.).

• Function Shipping (FS). Изменение источников данных (файлов), которые являются удаленными по отношению к локальному серверу CICS. При обращении из транзакции на локальном сервере CICS к такому источнику, он автоматически перенаправляет запрос к тому серверу, который владеет этим источником данных. Обеспечивается целостность данных в случае каких-либо сбоев.
• Transaction Routing (TR). Перенаправление вызова транзакции между серверами CICS. Можно «переселять» транзакцию с сервера на сервер, при этом требуется лишь переопределить ссылку на сервере CICS без изменения кода программы.
• Asynchronous Processing (AP). Асинхронный запуск транзакции на другом сервере CICS. Новая транзакция начинает «жить» самостоятельно, а управление немедленно возвращается в вызвавшую транзакцию.
• Distributed Program Link (DPL). Вызов удаленной транзакции с возвратом управления после окончания работы вызванной транзакции. Этот тип взаимодействия в прикладных системах используется наиболее часто.
• Distributed Transaction Processing (DTP). Диалог в оперативном режиме двух транзакций, работающих на разных серверах CICS. С точки зрения разработки и отладки это наиболее экзотический и сложный тип взаимодействия.

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

Транзакционный сервер очередей MQSeries

Концепция работы программного обеспечения промежуточного слоя типа MOM, в частности MQSeries, довольно проста. Прикладная программа кладет некоторую структуру данных (сообщение) в очередь на локальном сервере MQSeries и заканчивает работу. Сохраненное сообщение из локальной очереди передается канальным агентом MQSeries (channel agent) на удаленный сервер MQSeries и сохраняется там во входной очереди. При этом из локальной очереди сообщение удаляется. MQSeries гарантирует транзакционность передачи - сообщение не будет потеряно или передано дважды (это основное преимущество перед почтовыми системами, которые нередко используются для реализации функций распределенной обработки). После получения сообщения на удаленном сервере прикладная программа может прочитать его в любой удобный момент и выполнить необходимые действия; пока приложение не прочтет это сообщение, оно будет храниться в MQSeries.

MQSeries может быть подключен к монитору транзакций CICS наравне с СУБД. В этом случае CICS выступает как внешний координатор транзакций (External Transaction Coordinator - ETC), что исключает ситуации, когда при каком-либо сбое данные в СУБД были изменены, а сообщение не отправлено или наоборот - данные не изменились, а сообщение об изменении было отправлено. Это, в конечном счете, приводит к ситуации рассогласования данных на распределенных узлах OLTP-системы. Использование монитора транзакций позволяет избежать таких ситуаций.

Возглавляя рынок MOM (более 70%), MQSeries дополняет CICS возможностью построения сложной гетерогенной распределенной транзакционной среды с асинхронным типом взаимодействия.

DB2 Universal Database

DB2 - флагманская СУБД корпорации IBM. Ее применение в качестве основы сервера данных OLTP-систем позволяет реализовать сложную обработку данных и хранение больших массивов. Эти функции перекладываются на сервер данных, разгружая сервер приложения. Но если необходимо сделать систему, где хранение и обработка данных не очень сложны, а требования к производительности и минимизации ресурсов выходят на первый план (код ядра СУБД требует значительных ресурсов), то можно использовать файловые структуры, подключенные к транзакционному серверу CICS. Например, многие известные крупные западные OLTP-системы для мэйнфреймов S/390 построены на базе CICS и VSAM.

WebSphere Application Server

Семейство программных продуктов, обозначаемых маркой WebSphere Application Server, включает три версии - Standard, Advanced и Enterprise. Если говорить о поддержке транзакционности, то версия Standard этой службы не имеет, версия Advanced поддерживает службу Java Transaction Service (JTS), равно как и спецификации Enterprise JavaBeans, а версия Enterprise содержит специальные коннекторы для взаимодействия с «полноприводными» транзакционными системами наподобие CICS.

Говоря о WebSphere, часто имеют в виду только Internet-составляющую этого продукта - Application Server , мощный кросс-платформный сервер приложений, поддерживающий практически все известные спецификации и протоколы.

В реальных проектах мы избегаем программирования бизнес-логики средствами языка Java, поскольку реализация сервера приложения, например, в формате Enterprise JavaBeans, приводит к значительному снижению производительности приложения и заставляет вести разработку на языке третьего поколения, что менее эффективно по сравнению с инструментарием VisualAge Generator. Однако применение Web-браузеров на рабочих местах дает определенные преимущества для интерактивных систем: не надо платить за дополнительные лицензии для клиентских машин; имеется возможность отображать графическую информацию; нет необходимости копировать приложение по клиентским местам.

Обеспечение соединения браузеров с мощными системами «заднего плана» (back-end) требует применения Internet-серверов. WebSphere Application Server можно рассматривать как своего рода адаптер, который позволяет коду из браузера через вызов сервлета (servlet) обратиться к транзакции в CICS и, получив результат, возвратить его в браузер, создав на ходу интерфейсную HTML-страницу.

Заметим, что для OS/390 поддерживается интерфейс CICS Web Support, посредством которого браузер может напрямую подсоединиться к серверу CICS. Но для унификации архитектуры между платформами и, учитывая, что средство разработки приложений VisualAge Generator строит системы с использованием WebSphere Application Server, мы применяем этот продукт и на S/390. Это помогает решить проблемы переноса кода таких приложений между платформами.

Разработка на VisualAge Generator

VisualAge Generator - средство быстрой разработки приложений. Именно этот продукт является тем «клеем», который позволяет достаточно просто соединить все перечисленные выше технологии в единую картину.

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

Цикл разработки приложения средствами VisualAge Generator выглядит несколько иначе (рис. 3). В основе этой среды разработки лежит универсальная виртуальная машина Universal Virtual Machine (UVM), которая является базой для таких сред разработки, как VisualAge for Smalltalk и VisualAge for Java, поверх которых устанавливается VisualAge Generator.

Для запуска и отладки приложения нет необходимости производить компиляцию и сборку приложения. Для отладки работы логики и интерфейсных форм пользуются «малым» циклом (операции 1 и 2), что сокращает время разработки и не требует наличия целевой платформы. В этом цикле производится 80-90% работ и можно обойтись компьютером с Windows NT или OS/2, на котором может быть установлен VisualAge Generator Developer.

После того, как приложение отлажено, можно перейти к созданию кода времени выполнения (runtime) как для серверных, так и для клиентских платформ. При этом целевая платформа нужна только на момент выполнения операции 3. Замечу, что хотя в VisualAge Generator можно создавать приложения любой архитектуры, основное его предназначение - это разработка многоуровневых систем с четким разделением сервера данных, сервера приложения и уровня представления. В качестве клиентских интерфейсов поддерживаются графические, текстовые и Web-ориентированные интерфейсы. Цикл генерации исполняемого кода клиента значительно короче, чем для серверных компонентов. Фактически эта генерация производится в один этап, в результате которого создаются все необходимые компоненты для запуска приложения на клиентской стороне.

В качестве целевой платформы для сервера приложения поддерживаются более 20 платформ, включая CICS и MQSeries. После создания серверного кода времени исполнения его можно отлаживать из среды VisualAge Generator, т.е. проверить работоспособность окончательного кода (большой цикл из операций 3, 4, 5, 6).

В составе VisualAge Generator отсутствуют инструменты для разработки и программирования серверов данных, например, СУБД. Но, имея готовую структуру базы данных, можно автоматически создать всю структуру приложения, включая серверные и клиентские компоненты при помощи средства VisualAge Generator Templates (VAGT), которое входит в поставку. Предопределив некоторые условия, можно автоматически создать практически полную инфраструктуру приложения, что составляет до 80% работ по программированию. Это избавляет разработчика от «ручного» создания таких элементов, как серверные программы, процессы, бизнес-объекты, элементы форм, обработчики исключительных ситуаций и т.д. Учитывая, что в реальных проектах такие элементы исчисляются сотнями и тысячами, VAGT значительно сокращают время создания кода приложения. Далее необходимо лишь наполнить приложения соответствующей бизнес-логикой, которая пишется на языке 4GL.

«Обобщающее обобщение»

На рис. 4 показана общая архитектура распределенной OLTP-системы, которая базируется на описанных технологиях.

Основой системы является CICS (CICS A, например, на платформе Windows NT, CICS B - на платформе S/390). Два этих транзакционных сервера могут взаимодействовать как синхронно (TR, AC, FS, DPL, DTP), так и асинхронно, через MQSeries (менеджеры MQ1 и MQ2 для соответствующих платформ). Менеджеры очередей подсоединены к соответствующим серверам CICS через интерфейс XA. Также к серверам CICS подсоединены различные источники данных (на Windows NT - DB2 и/или СУБД Oracle и Microsoft SQL Server, на S/390 - DB2 и файловые структуры VSAM, которые определены в CICS через Resource Definition Online).

WebSphere Application Server (WSAS) играет роль конвертора вызовов от Web-клиентов к системе «заднего плана» (транзакции P1, P2, P3), написанной на VisualAge Generator.

VisualAge Generator Server (VAGen Srv) - платформнозависимый продукт, необходимый для запуска программ, разработанных на VisualAge Generator.

Возможны прямые соединения с CICS для клиентов с графическим или текстовым интерфейсом пользователя. При этом программы P1, P2 в CICS A могут быть определены как удаленные, тогда их вызовы в CICS A будут автоматически перенаправлены методом TR в CICS B и там запущены. P3 - локальная транзакция в CICS A, которая может посылать сообщения в CICS B через MQSeries.

Надо сказать, что экземпляры CICS, подобные CICS A и CICS B (в CICS их обозначают термином «регион») могут находиться не только на разных машинах, но и на одном сервере или в кластере. Работа регионов изолирована и «падение» одного из них не влияет на работу других. Это так же дает преимущества в масштабируемости, позволяя разделить задачи по регионам с точки зрения специализации. Такой подход наиболее часто практикуется на системах S/390, особенно в кластерах Sysplex. Реальные системы имеют несколько сотен регионов и десятки тысяч транзакций.

Однако сама по себе технология без соответствующих инструментов не дает ожидаемого «выхлопа». Скажем, CICS очень хорош, но если вы попробуете реализовать систему на С++ или Коболе, то это потребует от разработчика бизнес-логики хорошего знания как языка программирования, так и API-интерфейсов CICS, которые сродни API-интерфейсам операционных систем. Масса времени будет потрачена на создание инфраструктурных элементов (описание функций, переменных и т.д.) и отладку такого проекта. Но если взять VisualAge Generator, это избавит разработчика бизнес-логики от необходимости знать CICS, позволив ему сосредоточиться на своих прямых задачах. Конечно, для реализации сложных проектов требуется владение CICS, но это требование уже распространяется не на всех разработчиков, а на двух-трех специалистов, отвечающих за среду выполнения приложения.

«Сплав» технологий и инструментов как раз и дает оптимальный результат; рассмотрение же отдельных продуктов вне системного прикладного контекста для разработчиков сложных не «коробочных» решений не имеет большого смысла. Точно так же мало проку судить о СУБД вне рамок прикладной задачи. Скажем, вы большой поклонник Oracle. Но что делать, если заказчик требует приложение для целевой платформы AS/400? Или у вас большая любовь к DB2, а прикладная система заказчика на S/390 использует VSAM и заказчика полностью устраивает, и речь идет лишь о замене «зеленого» экрана на Web-браузер, чтобы, к примеру, показывать не только алфавитно-цифровые данные.

Реализация OLTP-системы для Внешторгбанка

Сложность этого проекта была не столько в объеме написанного кода (код прикладной логики предоставил заказчик), сколько в знании технической глубины работы различных механизмов транзакционных систем. Этот проект характеризуется как широким спектром платформ и технологий, так и необходимым знанием работы специфических механизмов, необходимым для интеграции с некоторыми готовыми прикладными пакетами.

В качестве центрального узла OLTP-системы используется S/390; возможно использование кластера Sysplex. В качестве «банковской машины» применяется пакет от Altel, реализованный на базе CICS TS, VSAM и имеющий «зеленый» интерфейс формата 3270. Кроме центрального узла банк имеет несколько десятков периферийных узлов, в которых используются серверы AS/400 и Windows NT (рис. 5).

Взаимодействие серверов осуществляется посредством MQSeries. Для того чтобы разработчики прикладной логики были изолированы от механизмов вызова транзакций из серверных процессов, написанных на 4GL в VisualAge Generator, была использована методика и набор программ («оборачивающие» транзакции), при помощи которых можно обращаться к функциям из 4GL. Стремясь унифицировать интерфейсы доступа к данным и снизить расходы на рабочие места, заказчик выдвинул требование использования Web-интерфейсов. При этом работа через Web-браузер должна вестись не по принципу «один к одному», как через терминалы 3270, а через HTML-страницу, создаваемую несколькими экранами 3270. При этом необходимо было обеспечить совместимость с системой безопасности. Все это порождало ряд проблем, которые пришлось решать в комплексе.

Проблема № 1. Для вызова транзакции CICS, которая работает с «зеленым экраном», используется протокол EPI (External Presentation Interface), работающий с потоком 3270. При активизации такой транзакции CICS использует терминальное устройство - структуру, которая идентифицирует соединение и является основным атрибутом для транзакции. Так, эта структура содержит четырехсимвольное поле TERMID (идентификатор терминала), которое используется транзакциями для собственной системы безопасности. Такой тип соединения в CICS называют терминальным.

Однако соединение, которое строится для работы Web-браузера, НЕ является терминальным, т. е. для этого соединения НЕ существует такой структуры (в понимании транзакции 3270), что сразу приведет к сбою выполнения транзакции.

Для вызова транзакций 3270 из нетерминальных соединений или из других транзакций CICS, которые были вызваны через протокол ECI (External Call Interface), в мониторе CICS для OS/390 был реализован механизм, называемый 3270 Bridge. Была добавлена новая команда EXEC CICS START BREXIT и при активизации транзакции 3270 через эту команду, CICS создает специальную структуру, называемую Bridge Facility, так называемый суррогатный терминал, который «предъявляется» транзакции 3270 в момент ее инициализации. Но при создании суррогатного терминала CICS самостоятельно генерирует идентификатор для поля TERMID по своей внутренней логике. Этот сгенерированный TERMID никак не связан с реальным идентификатором пользовательского соединения. Это и порождает проблему № 2.

Команда EXEC CICS START BREXIT не поддерживается и со стороны VisualAge Generator - нельзя установить такие параметры, чтобы он сгенерировал команду вызова, так как она появилась только в последних версиях CICS (начиная с версии 1.3). Для решения этой проблемы на Коболе была написана программа, принимающая необходимые параметры и активизирующая транзакцию через эту новую команду. Это пример использования Кобола как языка третьего поколения для реализации тонких системных функций. Программу на Коболе можно вызывать из прикладных транзакций, написанных на 4GL в VisualAge Generator.

Проблема № 2. Для вызова транзакции 3270 используется механизм 3270 Bridge, который создает суррогатный терминал. Но некоторые поля, включая TERMID, CICS инициализирует сам, никак не привязываясь к клиентскому соединению, из которого вызывается эта транзакция. CICS для каждого такого вызова ставит TERMID в значение из интервала с?{AAA? по?{999?, увеличивая его последовательно. Использует стратегию безопасности, которая пришла еще со времен до эпохи SQL - каждому клиенту присваивается для входа через VTAM (Virtual Telecommunication Access Method) восьмисимвольный идентификатор, называемый LU (Logical Unit), который проверяет VTAM. Четыре последних символа из LU берутся для генерации TERMID. Транзакция, отвечающая за идентификацию пользователя, принимает с клавиатуры имя пользователя и его пароль, берет TERMID и смотрит в свой внутренний файл, в котором ищет соответствие имени пользователя и TERMID. Это гарантирует, что данный пользователь может обращаться к системе только с определенного компьютера, так как при конфигурировании SNA-соединения на стороне сервера прописывается и MAC-адрес сетевой платы клиентского компьютера. Но web-соединения идут в обход VTAM и не имеют терминального устройства. Каким образом передавать TERMID или нечто, заменяющее его, чтобы минимизировать переделку транзакций?

Эта проблема была решена путем задействования пользовательской области терминала (Terminal Control Table User Area - TCTUA), нашей собственной транзакции 3270 первичной аутентификации пользователя и инициализации TCTUA, написанной на VisualAge Generator. Это привело к минимизации переделок в транзакции, которая свелась к замене слова?TERMID? на?TCTUA? в «кобольных» текстах.

Помимо этого, были проблемы с реализацией вызова последовательности 3270-транзакций в рамках одной 4GL-транзакции с промежуточной обработкой результатов: было необходимо обрабатывать и передавать параметры («экраны») для каждого вызова 3270.

Распределенная OLTP-система с интеграцией унаследованных программ

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

Компания Panasonic использует программу PSI для AS/400 и для Windows NT. При этом на AS/400 программа использовала в качестве структуры данных собственные таблицы и таблицы из ERP-системы J.D. Edwards, работающей на этом сервере. Сервер AS/400 находится в Хельсинки, а серверы NT - в Москве и Киеве, причем связаны между собой не очень надежными линиями. Между тем, логика работы программы PSI должна обеспечивать доставку информации к узлам через сервер AS/400. Существующая версия использовала механизм репликации баз данных, что в условиях плохих линий связи было неприемлемо.

Для решения этой проблемы была предложена модель транспортной системы между серверами на базе MQSeries. При этом не требовалось изменять код существующего приложения PSI, которое отвечало за взаимодействие с конечным пользователем, а предлагалось задействовать триггерные механизмы баз данных. Т. е., на необходимые таблицы «подсаживались» триггеры, которые для каждой операции (вставка, удаление, редактирование) посылали соответствующие сообщения в систему MQSeries. Эти сообщения, попав на AS/400, рассылались во все остальные узлы системы.

Это решение поддерживает использование нескольких баз данных (в среде NT) и библиотек (в среде AS/400) для возможности отладки или других целей. При этом при помощи специальных утилит можно назначить, откуда и куда будут передаваться данные для конкретной таблицы. Набор и структура таблиц в базе данных жестко заданы. Для реализации этого проекта были задействованы как MQSeries и VisualAge Generator, так и программирование на C++. На NT были реализованы триггерные мониторы MQSeries в виде служб NT, а на AS/400 - триггеры DB2.

В данном проекте, на первом этапе, каждая операция в базе порождала одно сообщение с соответствующим кодом операции (I - insert, D - delete, U - update), которое расшифровывалось на удаленных узлах. Но в реальности оказалось, что программа PSI изменяет ключевые поля, что вообще-то не рекомендуется. Это делает невозможным выполнение операции U («изменить») на удаленном узле, так как записи с измененным ключевым полем там еще не существует и СУБД не может ее найти. Вставить в структуру таблиц собственные ключевые поля было нельзя, так как использовались таблицы приложения J.D. Edwards, структуру которых менять нельзя. После анализа ситуации, с тем, чтобы решить проблему с минимальными переделками, было предложено вместо одного сообщения с кодом U соответствующий триггер стал посылать пару сообщений: первое - с кодом D («удалить») и старым значением ключа; второе - с кодом I («вставить») и новым значением ключа.

Эта система пропускает в сутки около 60 тыс. сообщений средней длины около 2 Кбайт. Проект был реализован за 8 недель силами 4 инженеров.

Литература

Masaharu Murozumi, A Challenge To A High Transaction Volume Client/Server DB2 Data Shared OLTP System. IBM, 2000

Г. Ладыженский, Технология «клиент-сервер» и мониторы транзакций. «Открытые системы», 1994, № 3

М. Рузинкевич, А. Цикоцки, Определение и выполнение потоков транзакций. «СУБД», 1995, № 2

E. Cobb, J. Hamilton, G. Sharman, Do I Need A Transaction Processing Monitor and a Database? IBM, 1996

Николай Игнатович, IBM MQSeries: архитектура системы очередей сообщений. «Открытые Системы», 1999, № 9-10

Николай Игнатович, Интеграция технологий управления данными в DB2. «Открытые системы», 2001, № 7-8

P. Wakelin, S. Day, S. Read, F. McKenna, CICS Transaction Gateway V3.1. The WebSphere Connector for CICS. SG24-6133-00, IBM, 2001

Илья Афанасьев ([email protected]) - генеральный директор компании «Диджитал Эмпайр», (Москва).

Основные типы программного обеспечения промежуточного слоя

• Монитор распределенной обработки транзакций (distributed transaction processing monitor). Контроль выполнения интенсивного потока транзакций в системах оперативной обработки транзакций в многоплатформенной среде.
• Удаленный вызов процедур (remote procedure call - RPC). Синхронизация взаимосвязи процессов, путем их удаленного вызова. Транзакционность не поддерживается.
• Взаимосвязь баз данных (database connectivity). SQL-запрос, направленный через это программное обеспечение, может обработаться несколькими СУБД от разных производителей.
• Обработчик объектных запросов (object request broker - ORB). Обмен программными объектами между различными платформами и по различным протоколам.

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

ПО промежуточного слоя, основанное на передаче сообщений (message oriented middleware - MOM). Асинхронный обмен сообщениями между приложениями, которые могут выполняться на различных платформах. Обмен производится с гарантированной доставкой; при потере соединения операция будет автоматически возобновлена после восстановления.