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

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

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

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

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

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

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

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

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

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

Возвращаясь к проблеме нормализации данных, можно сказать, что в системах 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). Асинхронный обмен сообщениями между приложениями, которые могут выполняться на различных платформах. Обмен производится с гарантированной доставкой; при потере соединения операция будет автоматически возобновлена после восстановления.

Началось все с одной истории, которая три года назад случилась в моей профессиональной карьере, когда я работал в Киргизии, в компании, которая представляла собой сеть розничных магазинов. Тогда у меня произошел разговор с моим директором по IT, который сказал: «Денис, у нас одна из важных, критичных операций - это проведение документа «Чек» на кассах. Как мы можем максимально ускорить этот процесс, распараллелить его, при этом получая оперативные остатки?»

Сразу скажу, что у нас на тот момент использовалась платформа 8.1 и автоматические блокировки. И я тогда ему ответил, что да, мы можем перейти на управляемые блокировки и распараллелить этот процесс на уровне номенклатуры. На что он мне задал естественный вопрос: «а что произойдет, если у нас на нескольких кассах одновременно будет проводиться одна и та же номенклатура?» Тогда я на этот вопрос какого-то внятного ответа дать не смог, но надеюсь, сейчас у меня это получится.

Тренды развития аппаратного обеспечения

Если мы посмотрим на развитие индустрии IT за последние несколько лет , мы увидим определенные тренды в аппаратном обеспечении :

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

Тренды развития бизнес-приложений

А что в это время происходит на уровне бизнеса ? Мы наблюдаем: все большее количество пользователей , которые используют все большее количество устройств , на которых выполняется все большее количество программ , и все это в свою очередь генерирует все большее количество данных .

При этом большинство из этих процессов поддерживаются облаками .

Помимо облаков есть еще такая сущность, как мобильность, которая представляет собой сочетание всех мобильных устройств, а также программ и данных, ими генерируемых.

Облака и мобильность всегда были связаны между собой, и именно от взаимодействия этих двух сущностей мы в будущем сможем получать какие-то прорывы. Такое взаимодействие привело к появлению известной на Западе стратегии: Mobile-First - Cloud-First (изначально мобильное и изначально облачное).

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

Соответственно, возникает потребность в специальных технологиях . И, если касаться конкретно In-memory OLTP, то это - всего лишь одна из многих технологий, призванных на данный момент обеспечить дальнейшее развитие IT-индустрии.

Технология In-memory OLTP

Почему появилась технология In-memory OLTP? И почему она важна?

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

Соответственно, In- memory OLTP - это: высокопроизводительный механизм , который отвечает современному аппаратному обеспечению и максимально оптимизирован для работы с памятью .

И, что самое важное, In-memory OLTP - это не какой-то отдельный продукт (не какая-то отдельная лицензия, за которую нужно платить). Начиная с SQL Server 2014 In-memory OLTP - это часть ядра этого продукта, которая доступна в рамках редакции Enterprise .

Здесь вы видите три основных компонента, которые представляют собой технологию In- memory OLTP . Именно они позволяют ей осуществить такой прорывной эффект:

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

Сравнение инфраструктуры взаимодействия (традиционной схемы и In-Memory OLTP)

Если мы посмотрим традиционную схему взаимодействия клиента и СУБД , то тут все очевидно:

• У нас есть клиент со своими клиентскими вызовами ,
• Есть сервер 1С:Предприятие , который вмещает всю бизнес-логику .
• И есть сервер СУБД . Он в традиционной схеме используется в основном для манипуляции с данными (а конкретно - для четырех операций: выборка, накопление, изменение и удаление).

В случае применения схемы In- Memory OLTP в рамках платформы 1С, схема чуть-чуть меняется:

• Остаются те же клиенты со своими клиентскими вызовами .
• Но в данном случае сервер 1С:Предприятие немного трансформируется . В целом полностью остаются все его функции и назначение, но теперь нельзя сказать, что он полностью контролирует всю существующую бизнес-логику. Здесь я его назвал слоем программного сервера. Почему?
  • Потому что появляется дополнительное внешнее прямое соединение к СУБД , с помощью которого осуществляется вызов хранимых процедур , о которых я говорил ранее.
  • Сущность этих хранимых процедур теперь состоит в том, чтобы производить операции с данными в соответствии с той бизнес-логикой , которую вы заложили на уровне СУБД.

Яркий пример того, как физический слой «протек» на слой логический.

Основное преимущество In-Memory OLTP

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

Тестовый сценарий для проверки работы технологии In-Memory OLTP в рамках платформы 1С

Анализируя те возможности, которые дает технология In-memory OLTP, я решил реализовать достаточно простой тестовый сценарий для проверки работы этой технологии в рамках платформы 1С. Демонстрационная среда , которая у меня получилась в результате, выглядела следующим образом :

• Я взял очень простую конфигурацию с одним регистром накопления , в котором учитывались остатки по номенклатуре в разрезе количества.
• Также в этой конфигурации было два документа - Приход и Расход , в которых была реализована следующая бизнес-логика:
  • Документ Приход обеспечивал поддержку минимального остатка.
  • А при проведении документа Расход контролировалось отсутствие нулевых остатков.
• Для того чтобы сымитировать конкурентную многопоточную нагрузку при проведении этих документов, я использовал стандартный подход с фоновыми процессами , которых для проведения документа Расход было подавляющее большинство.
• Также следует отметить, что я в своей демонстрационной сети использовал две виртуальные машины :
  • Одну - для сервера 1С:Предприятие ,
  • А другую - для SQL-сервера .

Но обе виртуальные машины находились в рамках одного хоста виртуализации .

Первый замер - базовый показатель

После того, как эта схема была реализована, я провел контрольный замер базовых показателей для стандартного, традиционного проведения документов средствами 1С с использованием управляемых блокировок. Что я получил в результате первого замера?

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

Второй замер - миграция в In-Memory только таблиц

Следующим шагом я решил сделать миграцию структур, в которых хранились стандартные данные, в In- memory-таблицы . И после того, как я их мигрировал, я запустил свой стандартный тест. В нем происходило все то же самое: средствами платформы 1С проводились документы, но только теперь они уже хранились в In-Memory-таблицах (сама платформа об этом не знала).

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

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

Третий замер - миграция в In-Memory и таблиц, и бизнес-логики

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

• Формирования документов и их табличных частей;
• Их записи;
• Формирования движений документов;
• И изменения текущих остатков.

В итоге был получен результат 250 документов в секунду . По сути, по отношению к базовому показателю 120 и 250 - это выигрыш чуть больше, чем в два раза.

Тут можно немного посмеяться и сказать, что мы же можем взять железо в два раза мощнее и получить примерно тот же результат. Но все объясняется, если посмотреть на загрузку процессоров в этом случае:

• Сервер 1С:Предприятия полностью загружен ;
• В то время как сервер SQL занят только на треть .

Мне удалось выяснить, что данная нагрузка на сервер 1С:Предприятие показывала, что он просто не успевал сгенерировать это количество документов на лету, а также не успевал их отдавать на проведение SQL-серверу, чтобы полностью его загрузить.

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

Четвертый замер - передача 15 документов для проведения за один вызов

Четвертый замер я сделал в надежде на то, что удастся все-таки за один сетевой вызов отдавать на SQL-сервер побольше работы. Для этого бизнес-логика была переписана таким образом, чтобы за один вызов отдавать на проведение сразу 15 документов . В результате скорость выросла до 550 документов в секунду .

При этом, как видно на графиках, сервер 1С:Предприятие был все так же полностью загружен, а SQL-сервер продолжал «отдыхать» .

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

Пятый замер - запуск подготовленной нагрузки на стороне SQL Server

Следующим шагом я решил сгенерировать всю нагрузку предварительно . Эта нагрузка выглядела в виде 64 сформированных файлов SQL-скриптов на 700 мегабайт . Я перенес их на SQL-сервер , и с помощью известной утилиты OStress, которой можно «скормить» эти файлы, чтобы запустить параллельную нагрузку, получил следующий результат.

• По загрузке процессора - получившееся время отработки поместилось в стандартное окошко диспетчера задач: есть начало нагрузки, потом полностью все процессоры почти
• В результате нагрузки было создано 112 тысяч документов, при этом полностью сохранялись все те процессы, которые были при проведении документов «Расход»: контролировались все остатки, выполнялись все действия.
• Нагрузка заняла 53 с лишним секунды .
• Если сделать определенные вычисления, получится, что среднее время проведения одного документа составило менее половины миллисекунды ,
• а средняя скорость проведения документов составила больше 2000 документов в секунду .

Когда я первый раз получил этот результат - не мог поверить. Просто представьте себе, какие объемы вам теперь доступны, вы теперь можете мыслить в совсем других категориях. И теперь я могу ответить своему бывшему директору по IT, как мы можем ускорить проведение документов «Чек» на кассах. И даже если при этом у нас будут какие-то конфликты, блокировки, сам процесс теперь пройдет очень быстро.

Методология миграции

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

• Например, если сравнить стеки выполнения (традиционный и In-Memory OLTP), то на уровне сетевого взаимодействия ничего не поменялось . Поэтому, если ваша программа (ваше приложение) очень «разговорчивое», обменивается с сервером СУБД очень большим количеством сообщений, то вам технология In-Memory совсем не поможет - здесь нет никаких улучшений.
• Также, если мы посмотрим на уровень журнала регистрации базы данных , то тут тоже особо ничего не поменялось . Хотя размер журнала регистрации при операциях In-memory OLTP сокращается, минимальная задержка транзакций при записи в этот журнал остается той же.
• Основную выгоду вы сможете получить только на уровне выполнения запросов и доступа к данным .

Преимущество технологии In- memory OLTP не в том , что данные располагаются в памяти. Хотя технология и называется In-memory, выигрыш происходит не от этого - ускорение происходит за счет того, что меняется инфраструктура самой базы данных :

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

И, если мы посмотрим на стандартную систему, то в случае добавления в нее большого количества потоков, они со временем начинают друг другу мешать, тем самым пропускная способность вашей системы уменьшается. В то же время при использовании технологии In-memory OLTP система при увеличении количества пользователей продолжает масштабироваться, поскольку нет блокировок (используются новые структуры данных, которые их лишены), а также применяются быстрые, предварительно скомпилированные хранимые процедуры.

Что можно сказать по поводу самого процесса миграции в In- memory ? Он в целом состоит из двух шагов , которые поочередно повторяются:

• Первый шаг - это миграция структур данных .
• И второй шаг - это миграция вашей критичной .

Решение проблемы записи в In-Memory из 1С

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

С чем связана такая ошибка? Стандартная схема выполнения поддерживает пять уровней изоляции, а механизм In-memory OLTP - только три уровня. При этом платформа 1С по умолчанию использует уровень изоляции ReadCommited, которому как раз нет соответствия в механизме In- Memory OLTP . Соответственно, возникает проблема согласованности между этими уровнями изоляции.

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

В самом SQL Server 2014, в котором как раз и появилась технология In-Memory, есть такое свойство базы данных , как is_ memory_ optimized_ elevate_ to_ snapshot_ on . По умолчанию, оно неактивно, выключено - это можно проверить запросом, который показан на слайде.

Соответственно, если вы выполните команду, которая активирует это свойство , то проблем с согласованностью уровней изоляции у вас не будет .

При этом вы поднимете уровень изоляции, который СУБД использует по умолчанию, и он как раз будет соответствовать уровню изоляции Snapshot, по умолчанию использующийся для таблиц In-Memory. Таким образом, проведя небольшие манипуляции на стороне СУБД, у вас в In-Memory-таблицы будут записываться любые документы и любые данные.

Общая схема миграции бизнес-логики на сторону СУБД

Что же можно сказать по поводу общей схемы миграции самой бизнес-логики на сторону СУБД ?

Она включает в себя два объекта :

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

Вот примерная схема реализация «обертки» . Здесь AddOutcome - это внешний StandardT-SQL-(обертка). Внутри цикла располагается процедура, уже непосредственно скомпилированная в машинные коды. Видно блок TRY (Retry). Соответственно, если возникает конфликт, то происходит исключение, в котором вы, как разработчик, закладываете какой-то период ожидания, чтобы конфликтующая транзакция успела выполниться, а затем, соответственно, выполнится ваша.

Заключение

Ну и в заключение можно сказать, что миграция в таблицы In- Memory OLTPприменительно к 1С потребует задействовать :

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

*****************

Приглашаем вас на новую конференцию .

OLTP и 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 -приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками:

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

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

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

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

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

Сравнение OLTP и OLAP