Продолжение. Часть 1. Часть 2. Часть 3. Часть 4. 5 Сравнение программного обеспечения промежуточного слоя.На окончательный выбор варианта централизации однотипных систем в ходе укрупнения вычислительных центров может оказать значительное влияние выбор используемого программного обеспечения. При прочих равных, различия в ПО могут оказаться решающим фактором. Основное значение при выборе ПО будут иметь средства исполнения бизнес-логики, и в особо значительной степени СУБД, как наиболее нагруженные и сложно масштабируемые элементы вычислительной инфраструктуры. Основным и самым нагруженным средством в ИТ инфраструктуре является сервис хранения и обработки данных, с него и имеет смысл начать рассмотрение. 5.1 РСУБД.Основным и самым распространённым средством хранения и обработки данных являются различные Реляционные СУБД, РСУБД, например, IBM DB2. РСУБД имеют ряд общеизвестных преимуществ, заслуженно получили свою долю на рынке баз данных, и считаются универсальной СУБД, в равной степени пригодной для решения любых типов задач. Некоторая степень унификации по работе с данными, присущая РСУБД, позволила упростить процесс создания ПО, способного работать с разными базами данных на разных платформах, и упростить процесс адаптации прикладных систем под другую базу данных. Но несмотря на наличие стандартов на язык доступа к данным SQL, диалекты этого языка от разных производителей существенно отличаются, что по-прежнему требует затрат на адаптацию прикладных систем к разным базам данных. В то же время разные способы воплощения реляционной теории в целом и языка SQL в частности, привело к сильному расхождению в способах администрирования различных СУБД. 5.1.1 Причина возникновения РСУБД. РСУБД возникли как попытка дать возможность конечным пользователям работать с данными без привлечения программиста. Реляционная теория и алгебра позволили реализовать программный слой — оптимизатор СУБД — который принимал бы от конечного пользователя декларативный запрос на доступ к данным, и превращал его в программу доступа к данным. Использование РСУБД предполагает бльшую простоту работы с данными, и бльшую скорость создания программ по работе с данными, по сравнению с дореляционными базами. Декларативность языка доступа к данным и независимость его от физической структуры данных позволяют упростить создания программ доступа к данным, в идеале до уровня возможности работы конечного пользователя без программиста. Само по себе появление РСУБД позволили возникнуть целому новому направлению обработки данных — оперативному анализу (OLAP), который был бы чрезвычайно затратен, или даже невозможен, без возможностей оптимизатора по составлению программ доступа к данным и их обработке, в противном случае это означает большие трудозатраты на программирование. 5.1.2 Проблемы реализации больших OLTP систем на РСУБД. Простота РСУБД. Возможности реляционних баз данных в целом, и их конкретных реализаций, в виде оптимизаторов и диалектов языка доступа к данным, оказались настолько широкими, что это затрудняет пользователям работу с реляционными СУБД. При одной и той же структуре данных в РСУБД зачастую существует более одного способа извлечения нужных данных, которые могут значительно различаться по производительности. Иногда возможности SQL по доступу к данным в различных структурах оказываются настолько гибкими, а структуры данных настолько сложными, что сложность создаваемых запросов значительно превышает уровень конечного пользователя. В результате появился целый класс прикладных программистов по составлению запросов к РСУБД. В целом можно сказать, что при использовании РСУБД принцип составления запросов к данным и работы оптимизатора состоит в оптимизации входящего запроса применительно к существующей структуре данных. Относительная простота языка доступа к данным приводят к появлению цикличности при создании систем работы с РСУБД, при которой разработка структуры и запросов сменяется настройкой производительности выполнения запросов, которая приводит к изменению структуры, запросов, и связанных с ними приложений. Подробнее цикл описан в приложении . Некоторые системы, построенные на основе РСУБД, успели пройти в своём развитии несколько таких циклов, и процесс продолжается. Универсальность РСУБД. К тому же, стоит иметь в виду, что универсальность РСУБД, и попытка в одной системе решить разные типы задач, зачастую приводят к противоречивым требованиям со стороны разных подсистем к степени нормализации данных. OLTP подсистемы с их предопределёнными запросами к малым порциям данных в случайном порядке требуют одних структур данных, оптимизированных под такую нагрузку, а OLAP подсистемы, с их случайными запросами к большим порциям данных в последовательном порядке требуют других структур данных. Как правило это приводит к неудовлетворительной производительности универсального решения. Иногда системы в своём развитии проходят несколько циклов нормализации/денормализации структуры данных, как произошло и с ПТК. Каждый раз новый цикл требует новой постановки задачи, новой разработки, создания новых запросов, их оптимизации, изменения приложений, их тестирования, наладки, и сдачи в эксплуатацию. По опыту ПТК длительность одного такого цикла может составлять более года. Для максимально возможного избегания таких ситуаций происходит разделение систем по типу генерируемой нагрузки к базе данных, на OLTP и OLAP системы, с некоторой степенью интеграции данных между ними. Плата за преимущества РСУБД. Возможности и удобства, предоставляемые РСУБД, достигаются за счёт непроизводительных накладных расходов, присущих в силу их архитектуры (источник накладных расходов описан в приложении ). На эти накладные расходы затрачивается некоторая вычислительная мощность сервера, которой в большинстве случаев можно пренебречь. Но если рассмотреть централизацию всех систем всех департаментов, то происходящий в таком случае лавинообразный рост количества обрабатываемых данных и количество обслуживаемых пользователей приводит к очень значительной доле непроизводительных накладных расходов. Это приводит к неоправданному перерасходу ресурсов, и к повышению совокупной стоимости системы. И если в условиях OLAP это неизбежные расходы, являющиеся платой за саму возможность проводить оперативный анализ данных, при котором в условиях отсутствия оптимизатора РСУБД пришлось бы программировать доступ к данным для каждого аналитического запроса заново, что было бы ещё более затратно, то в условиях OLTP, с присущими им стабильностью и неизменностью запросов, стабильностью связей между объектами, и особенно в связи с гораздо бльшей частотой вызовов запросов по сравнению с OLAP, эти расходы совсем не являются неизбежными, и их сокращение способно привести к общему снижение затрат на создание и сопровождение систем. В условиях OLAP систем время эксплуатации запроса к данным невелико по сравнению с OLTP, а время его составления может быть значительным по сравнению с временем использования, и выгодно сократить затраты на программирование короткоживущих вновь создаваемых аналитических запросов, даже за счёт роста затрат на вычислительные мощности. В условиях OLTP, где время эксплуатации запросов на доступ к данным в некоторых случаях может исчисляться десятилетиями, при создании структур данных и запросов к ним можно допустить увеличение затрат на создание, которые принесут большую экономию ресурсов и средств в период длительной эксплуатации. 5.1.3 Применимость РСУБД в качестве платформы для централизованных OLTP систем национального масштаба. В условиях особо крупных и ответственных OLTP систем, обрабатывающих большое количество данных и обслуживающих большое количество пользователей, уже упоминавшиеся в пункте проблемы со специалистами, способными проектировать, разрабатывать, настраивать производительность и сопровождать крупные и ответственные системы, усугубляют проблемы, связанные с накладными расходами, присущими РСУБД в силу их принципиальных особенностей. Происходит переход количества в качество, рост количественных характеристик систем приводит к изменению их качественных характеристик в худшую сторону, и это приводит к неоправданному росту затрат на создание и обслуживание таких систем. Для решения этих проблем не подходят количественные изменения, выраженные в увеличении количества серверов, или их мощности, так как это ведёт к ещё большему удорожанию систем, не меняя ситуации, требуются качественные изменения, приводящие к изменению подхода к разработке и эксплуатации систем и применяемых платформ. 5.2 Возможные альтернативы РСУБД.Несмотря на архитектурные различия РСУБД DB2 под разные платформы, которые обусловлены стремлением более полного использования уникальных возможностей каждой платформы, происходит значительная унификация программ по средствам доступа к данным, которая в случае с DB2 для z/OS не позволяет использовать все свойства платформы в полной мере. Тем не менее, на этой платформе уже очень большой период времени создаются и эксплуатируются очень крупные OLTP системы высокой степени надёжности и доступности, с использованием всех аппаратных и программных возможностей, предоставляемых системой. В том числе в среде z/OS существуют и другие базы данных. Есть даже вариант без использования СУБД, при котором используется VSAM для хранения данных, и набор приложений CICS для работы с ними. В этом случае, при удовлетворительных показателях производительности, резко возрастают расходы на создание, сопровождение и изменение таких систем, так как отсутствие СУБД приводит к необходимости обеспечивать ссылочную и логическую целостность данных программным способом. Этот подход не имеет практической ценности. Особого внимания заслуживает IBM IMS, которая фактически является монополистом в сфере особо крупных OLTP систем (см. приложение ), в частности финансово-учётных систем, к которым и принадлежит ПТК. По данным IBM около 80% крупнейших банков мира построили свои финансово-учётные системы с использованием IMS. 5.3 IMS.На российском ИТ пространстве сложилось убеждение, что IMS в частности, и дореляционные базы вообще, являются устарелыми и не пригодными к использованию в современных условиях. Это можно объяснить сравнительно малым размером OLTP систем, создающихся и эксплуатирующихся в России. Систем, в которых из-за их небольшого масштаба накладные расходы, связанные с особенностью РСУБД не проявляют себя в достаточной мере. В то же время значительное число зарубежных аналитиков в отрасли баз данных уверены в необходимости применения IMS, примеры можно прочитать в приложении . Российские специалисты признают превосходство IMS перед любой РСУБД в производительности на OLTP нагрузке, но выражают уверенность в её: • сложности; • негибкости; • отсутствию современных интерфейсов доступа; • необходимости программировать обход иерархических деревьев при навигационном доступе к данным; • необходимость программно поддерживать синхронность иерархических структур между собой; И всё это якобы приводит к невозможности её использования в современных условиях. Для выяснения реальной ситуации с возможностью использования IMS требуется рассмотреть архитектуру IMS и способы её использования. 5.3.1 Особенности работы с IMS. В IMS данные о бизнес-объектах хранятся в сегментах, связанных между собой непосредственными ссылками в иерархические структуры. Использование непосредственных ссылок от сегмента к сегменту, а не сравнение элементов множеств по ключевым полям, и является основой производительности систем, недостижимой на основе РСУБД. При этом приложения используют простой язык доступа к данным DL/I, который состоит из основных операций типа «Получить сегмент», «Заменить сегмент», «Вставить сегмент». Обработка данных происходит на основе отдельных сегментов, минимально возможной к обработке порции информации, что позволяет чрезвычайно экономно расходовать ресурсы в условиях OLTP систем. Приложения, используя DL/I, могут получать все взаимосвязанные элементы с очень высокой скоростью, с точно определяемым количеством операций ввода/вывода, за предсказуемое определённое время, с использованием только минимально необходимых ресурсов. Различные иерархии связываются между собой ссылками-связями, позволяя приложениям извлекать связанные данные, переходя между разными иерархиями абсолютно прозрачным для приложений способом, и без накладных расходов. Это позволяет строить чрезвычайно сложные и развитые структуры сетевого вида, и иметь к ним простой и быстрый доступ, к любому необходимому элементу. Отсутствие необходимости программировать обход деревьев. Язык доступа к данным IMS — DL/I — был первым языком, реализовавшим парадигму разграничения кодирования доступа к данным от кодирования бизнес-логики, воплощённую позже и в SQL. Также как и в SQL в языке DL/I присутствует декларативность — программист не должен указывать как именно получить данные, он определяет какие данные должны быть получены. Вообще между SQL и DL/I существует определённая аналогия. Как и в SQL в DL/I • присутствует аналог предложения SELECT, который позволяет указать, какие данные необходимо вернуть; • существует аналог предложения FROM, который позволяет указать, из каких структур должны быть получены данные; • есть аналог предложения WHERE, который позволяет задать критерии выбора данных. Работа с языком доступа к данным в IMS похожа в этом отношении на операцию Fetch из курсора при работе с РСУБД. Также как приложение получает по одному строки из курсора, также возвращаются сегменты из IMS. Задав все условия поиска, и выполнив вызов, программа получает первый искомый сегмент. Далее, по аналогии с операцией Fetch в SQL программа может получить следующий сегмент данных, удовлетворяющий условиям поиска. А может получить следующий сегмент в порядке иерархической подчинённости — аналога этой возможности в SQL нет. С этой точки зрения DL/I позволяет программе более гибко и с меньшими накладными расходами получать только нужные данные, пропуская ненужные, что приводит к сокращению задействованных расходов и совокупной стоимости системы. Пример сравнения получения одних и тех же данных при работе с РСУБД и при работе с IMS можно прочитать в приложении . Простота работы с IMS. Чрезвычайно простой язык DL/I, имеет в своём составе набор всех необходимых операторов для обработки данных. В то же время его однозначность и простота, в отличие от SQL с его неоднозначностью и сложностью на сложных структурах, не оставляют места для ошибки программисту. В самой сложной структуре IMS, доступ осуществляется последовательно к каждому требуемому сегменту, даже если он находятся в очень сложной и разветвлённой взаимосвязи с другими сегментами. Существует утверждение, что проектирование структур IMS является чрезвычайно сложным делом, особенно если сравнить это с РСУБД. Но как было уже рассмотрено в пункте , эта кажущаяся простота приводит в конечном итоге завышению сроков разработки, ошибках в настройке производительности, завышению совокупной стоимости, если речь идёт о системах национального масштаба. Действительно, моделируя реляционную структуру основной вопрос, на который отвечают — как связаны элементы бизнес-объектов между собой? Ответ на этот вопрос является необходимым и при проектировании структуры в IMS, но не является достаточным. Вторым необходимым вопросом при проектировании структур IMS является — как будут запрашиваться данные? Для построения структуры IMS, из которой приложения могли бы извлекать данные, вначале необходимо определить, какие данные в каком порядке приложения будут извлекать. В IMS просто невозможно создать структуру, не определив порядок извлечения данных, в РСУБД это не только вполне возможно, но и происходит, в силу упоминавших ся причин. Созданная структура полностью соответствует приложениям, для которых она создавалась. Если в случае РСУБД оптимизатор занимается адаптацией запроса под существующую структуру, то в случае с IMS проектировщик выполняет адаптацию структуры под требуемый запрос. С этой точки зрения действительно присутствует дополнительная сложность. Но в результате на выходе сразу же получается структура, из которой приложения извлекают данные самым эффективным способом, без накладных расходов. Цикличность, присущая РСУБД в попытках оптимизировать структуру/запрос, в IMS заменяется предварительным планированием и проектированием. Всё вместе это резко сокращает возможность ошибок, и чрезвычайно упрощает работу программиста. Но справедливо это только в условиях OLTP приложений, когда все бизнес-функции и присущие им запросы на доступ к данным известны заранее. Учитывая относительную частоту вызова этих запросов, а в IMS системах это может доходить до десятков тысяч запросов в секунду, длительность эксплуатации, исчисляемую годами и десятилетиями, и чрезвычайную важность систем, занимающихся, к примеру, учётом финансов, дополнительные затраты на предварительное проектирование, позволяющие сократить возможность ошибок и получить эффективно работающую структуру сразу же, являются вполне оправданными. Изменчивость систем, использующих IMS. Существует утверждение о чрезвычайной сложности изменения структур баз данных в IMS. Поскольку обычно это утверждения выдвигают безотносительно к конкретным приложениям и базам данных, остаётся дать такие же абстрактные ответы. • Изначально IMS используется для создания систем, реализующий базовый набор бизнес-функций организации, на основе которого строятся всевозможные автоматизированные рабочие места и другие системы. В каждой области деятельности существует неизменный набор примитивных, но очень чрезвычайно важных операций, к выполнению которых предъявляются особые требования в плане надёжности, изолированности, производительности. Время жизни, то есть период использования этих базовых операций может составлять десятилетия. А на основе набора основных операций строится всё богатство бизнес функционала. Пример из финансовой области можно прочитать в приложении . • Мнимая простота изменения структур РСУБД обязательно сопровождается полным циклом разработки, от постановки задачи, до финального тестирования изменённых приложений. Этот срок может занимать очень значительное время, несопоставимое с собственно процессом изменения. К тому же, как было показано ранее, за счёт этапа предварительного проектирования, для систем на IMS такое частое изменение структур данных не актуально, как для систем на РСУБД. Общее время изменения структуры даных состоит из нескольких слагаемых, из которых собственно изменение структуры является наименьшим. • IBM очень внимательно относится к нуждам и запросам клиентов. Разработана Dynamic Resource Definition facility, позволяющая проводить процесс изменения структур данных по принципу, аналогичному существующему в РСУБД. • IBM предоставляет графичиский инструмент на основе платформы Eclipse для упрощения работы с IMS в том числе для создания и изменения структур. Пример изменения структуры данных можно прочитать в приложении. Отсутствие необходимости в самостоятельной поддержке синхронности иерархических структур данных между собой. При работе с IMS, так же как и при работе с РСУБД, вся работа по обеспечению согласованного изменения различных структур данных, связанных между собой, выполняется СУБД, то есть, IMS. К этим структурам относятся Secondary Indexes, позволяющие выполнять поиск по необходимому полю, и получать доступ к сегменту, содержащему это поле, минуя корневой сегмент, и Logical References, позволяющие связывать между собой разные иерархии в сетевую структуру. Наличие современных разнообразных интерфейсов доступа. На текущий момент для работы с IMS наряду с традиционными интерфейсами предоставляется широкий перечень современных, в который входят и SOAP, и Java, и XQuery/XPath, что позволяет использовать IMS в условиях SOA, при разработке приложений и систем на основе современных средств. 5.3.2 IMS в качестве ядра OLTP систем национального массштаба. На основе функциональных и нефункциональных характеристик IMS, а также на основе мирового опыта построения крупных OLTP систем национального и над-национального масштаба, а также при рассмотрении проблем, стоящих перед Россией в целом, и ИТ отраслью в частности, и задач, выдвигаемых руководством страны, в плане повышения эффективности существующих систем, создания новых эффективных систем, в том числе и Национальной платёжной системы, можно предположить, что наиболее оптимальным способом решения множества проблем и стоящих задач будет использование IBM IMS. Применение этой платформы позволит выйти на новый уровень качества услуг, предоставляемых ИТ индустрией, в плане надёжности, безопасности и эффективности, что позволит снизить стоимость этих услуг, и в целом осуществить более глубокий охват услугами автоматизации сфер человеческой деятельность. 5.4 Программное обеспечение исполнения бизнес логики.В настоящее время в рамках z/OS есть множество средств исполнения бизнес-логики. С одной стороны использование нескольких мест исполнения бизнес-логики усложняют систему, затрудняя её сопровождение и развитие, что приводит к удорожанию системы. Но с другой стороны, неиспользование уникальных возможностей, предоставляемых каким-либо средством исполнения бизнес-логики, также способны увеличить затраты ресурсов системы, понизить качество предоставляемых услуг, и привести к удорожанию системы. С целью выяснения вопросов применимости разных средств бизнес логики в проектах централизации однотипных систем есть смысл уяснить их принципиальные различия. 5.4.1 Сравнение средств исполнения бизнес-логики. К средствам исполнения бизнес логики в z/OS можно отнести и пакетные задания, и Хранимые процедуры DB2, и транзакции (в терминах IBM процесс изменения состояния источников данных называется UoW (Unit of Work), а приложение/процедура по выполнению бизнес-ориентированных действий называется транзакцией, по аналогии с финансовой транзакцией) CICS, и транзакции IMS, и приложения J2EE под управлением WebSphere Applicaton Server (WAS), которые взаимно перекрываются по предоставляемому функционалу. И если вопрос применимости Хранимых Процедур DB2, или WAS, практически не вызывает затруднений в виду широкого распространения этих технологий, то позиционирование таких важных компонент платформы z/OS как CICS и IMS в качестве средств исполнения бизнес логики вызывают значительные затруднения. • CICS. • Предназначен для исполнения бизнес-логики, реализованной на компилируемых языках, в среде Language Runtime Environment (LRE), целью которого является предоставление возможности сборки приложения из модулей, компилированных с разных языков и компиляторов. • Транзакции-приложения исполняются в регионах (адресных пространствах z/OS), при чём все экземпляры одной транзакции исполняются в одном регионе. • Имеет возможность построения длительных по времени исполнения бизнес-процессов с помощью Business Transactional Services (BTS). • Диспетчеризация задач на выполнение происходит по push принципу (выталкивания). • IMS TM. • Предназначен для исполнения бизнес-логики, реализованной на компилируемых языках, в среде LRE. • Транзакции-приложения исполняются в адресных пространствах z/OS, причём каждый экземпляр транзакции выполняется в своём отдельном адресном пространстве, изолированно от других экземпляров этой же транзакции. • Имеет подсистему исполнения пакетных приложений, имеющих ряд преимуществ по эффективному использованию ресурсов, и применяющихся в том числе и для построения статистических отчётов, и тому подобное. • Имеет свой диспетчер очереди выполнения, кардинально отличающийся от других в составе z/OS, в том числе и от CICS, отличается чрезвычайно высокой эффективностью, что позволяет достигать наивысших показателей в производительности среди других сред исполнения бизнес-логики. Диспетчеризация задач выполняется по принципу queue and pull (постановки в очередь и выборки из неё). • В связи с тем, что в не используется многозадачность исполнения в одном адресном пространстве, администрирование и программирование под IMS проще, чем под CICS. • Интерфейс настройки IMS для работы с базами данных, что со своей, что с DB2, гораздо проще и эффективней, чем у CICS, по архитектурным причинам, прежде всего, однозадачности исполнения приложения в адресном пространстве. • WebSphere Application Server. • Предназначен для исполнения бизнес-логики, реализованной на языке Java, в среде J2EE, предоставляемой виртуальной Java машиной. • Все приложения исполняются в среде одной виртуальной Java машины, которая является отдельным адресным пространством. Есть возможность запускать несколько экземпляров одинаковых сред, выполняющих одинаковые приложения. 5.4.2 Позиционирование средств исполнения бизнес-логики. Некоторое время назад, многоплатформенность CICS и его сетевые возможности делали его прекрасным средством DCE (Distributed Computing Environment). Но с развитием стандарта J2EE, который поддерживает все эти возможности, поставили CICS в невыгодное положение на платформе z/OS. Всё то, что по функционалу пересекается на IMS — может быть реализовано в IMS с лучшим качеством, с меньшим потреблением ресурсов, лучшей производительностью, лучшей изоляцией. Всё то, что пересекается по функционалу с J2EE, выключая BPM (Business Process Management) — может быть лучше реализовано именно в J2EE, WAS и Process Server, который имеет развитые средства моделирования, тестирования, отладки, контроля исполнения бизнес-процессов (Modeler, Monitor, и другие развитые средства). Исходя из вышесказанного и отличительных характеристик продуктов: • для реализации и исполнения критически важных функций бизнес-логики, которая составляет основу функционирования системы, и к которой предъявляются особые требования по защищённости, изолированности, производительности, целесообразно использовать IMS TM. В этом случае каждый отдельный запрос на исполнение выполняется абсолютно изолированно от остальных запросов такого же класса, или других классов, с наивысшей доступной производительностью, и минимальными затратами. IMS TM по назначению и функциональному составу можно охарактеризовать как «хранимые процедуры на стероидах». Он уникально подходит для реализации архитектурного слоя доступа к данным, в котором должны быть сосредоточены все важные участки бизнес-логики по управлению данными; • для реализации элементов общей логики, некритичных по времени исполнения и по уровню изоляции, подверженных относительно частым изменениям, например, в составе уровня представления, целесообразно применять WebSphere Application Server, Process Server, со всеми средствами моделирования, отладки, и контроля исполнения. В случае такого применения разных средств исполнения бизнес-логики есть возможность добиться компромисса между различными нефункциональными требованиями, такими, как время отклика, уровень изоляции, возможности интеграции, изменения, и так далее. |
