Содержание к диссертации
Введение
ГЛАВА 1. Анализ моделей и способов построения транзакционных информационных систем 16
1.1. Архитектура и информационные процессы транзакционных систем 16
1.2. Анализ альтернативных вариантов построения архитектуры транзакционных систем 27
1.3. Анализ технологий и структуры облачной среды 36
1.4. Эталонная архитектура облачных вычислений 43
1.5. Технологии оптимизации производительности транзакционных систем 50
1.6. Анализ существующих подходов к распределению баз данных в информационных системах 54
1.7. Обзор математических моделей, используемых в транзакционных системах на базе различных архитектурных решений 57
1.8. Обобщенная постановка задачи распределения фрагментов баз данных в транзакционных системах 63
1.9. Выводы по главе 67
ГЛАВА 2. Разработка математических моделей oltp-систем, функционирующих в облачной среде 69
2.1. Модель транзакционной системы для развертывания в облачной среде 69
2.2. Модель транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде 82
2.3. Проблема оптимизации структуры распределенных баз данных для облачных OLTP-систем 87
2.4. Модель для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию минимума среднего объема трафика 90
2.5. Модель для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию минимума стоимости трафика 93
2.6. Модель для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию максимума суммарной ценности реплик фрагментов 96
2.7. Выводы по главе 100
ГЛАВА 3. Разработка алгоритмов оптимизации структуры распределенных баз данных и исследование предложенных моделей и алгоритмов 102
3.1. Разработка алгоритмов решения задачи оптимизации структуры распределенных баз данных 102
3.2. Исследование модели транзакционной системы для развертывания в облачной среде 112
3.3. Исследование модели транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде 119
3.4. Исследование модели для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию минимума среднего объема трафика 124
3.5. Исследование модели для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию минимума стоимости трафика 133
3.6. Исследование модели для оптимизации размещения фрагментов РБД в узлах сети облачной структуры по критерию максимума суммарной ценности реплик фрагментов 138
3.7. Выводы по главе 142
ГЛАВА 4. Программная реализация разработанных моделей и их практическое применение для проектирования архитектуры транзакционных систем 144
4.1. Программная реализация инструментария для построения и исследования облачных транзакционных информационных систем 144
4.2. Структура программных комплексов биллинговых OLTP-систем, разрабатываемых в ООО НПП «ЛТТ» 154
4.3. Оптимизация структуры программных комплексов биллинговых OLTP-систем, разрабатываемых в ООО НПП «ЛТТ» 161
4.4. Построение системы электронного документооборота в облачной инфраструктуре 171
4.5. Сопряжение верхнего уровня АСУ ТП с OLTP-системой на базе облачной инфраструктуры 178
4.6. Выводы по главе 183
Заключение 186
- Анализ технологий и структуры облачной среды
- Модель транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде
- Исследование модели транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде
- Построение системы электронного документооборота в облачной инфраструктуре
Анализ технологий и структуры облачной среды
Большую роль транзакционные системы играют в специализированных отраслевых решениях с массовыми транзакциями - банковских, биллинговых системах, в связи и жилищно-коммунальном секторе, системах продажи билетов на транспорте, ERP-системах, при автоматизации бухгалтерского и складского учета, документооборота, в фиксации посетителей веб-сайта для формирования статистики обращений, в промышленности - регистрация прохождения детали на конвейере и т.д. [17]. Ввиду большого разнообразия существующих OLTP-систем, которые охватывают широкий спектр предметных областей, а также исходя из того, что концепции их построяния достаточно похожи, имеет смысл рассмотреть архитектуру и информационные процессы наиболее востребованных в настоящее время видов транзакционных систем.
Современные тенденции развития рынка БС, связанные с постоянно и быстро растущим многообразием видов предоставляемых услуг и их объемов, ставят перед компаниями все более сложные задачи по организации процесса оказания услуг клиентам: предоставление максимального спектра различных услуг, создание гибкой системы учета и тарификации оказываемых услуг, выставления счетов и учета оплаты, максимальная ориентация на нужды конкретного потребителя, максимально быстрая реакция на запросы клиента, поддержка различных способов оплаты. Исходя из этого, к АСР возникает требование конвергентности и открытости.
Биллинговая система - программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании. К основным задачам, которые решает БС, относятся: сбор информации о потребляемых услугах; аутентификация и авторизация абонентов; контроль денежных средств на счетах абонентов и списание средств в соответствии с действующей тарифной сеткой; пополнение счетов абонентов; внесение изменений в тарифы; предоставление статистики по операциям (клиентская и операторская части). Классическая БС состоит из следующих функциональных подсистем (рис. 1.1): - предварительной обработки данных - выполняет первоначальную обра 17 ботку информации, поступающей в систему, с целью исключения явных ошибок, опечаток и противоречивости исходных данных; - оперативного управления биллингом - обеспечивает доступ к операциям, связанным с выполнением начислений, перерасчетов, приемом оплат абонентов, производит сокращение объемов пользования услугами, отключение и пр.; - оповещения клиентов - имеет функциональные средства для уведомления клиентов о различных изменениях на их лицевых счетах (ЛС) в виде рассылки электронной почты, коротких текстовых сообщений через мобильную связь, ав-тодозвон на номера мобильного или городского телефонов; предоставляет возможность выполнения абонентами сверки учетных данных, просмотра расшифровки начислений по своим ЛС и др.; - продаж, маркетинга - осуществляет контроль основных показателей эффективности работы системы с целью прогноза ситуации и своевременного принятия должностными лицами управленческих решений; - обслуживания - предназначена для ведения картотеки, учета договоров с абонентами и относящейся к ним информации; - администрирования - реализует механизмы аутентификации и разграничения прав доступа пользователей к информации, режимам и отдельным операциям, предоставляет возможность просмотра журнала действий пользователей; - генерации отчетов, генерации счетов - предназначена для формирования статистической, аналитической и управленческой отчетности, документов для абонентов, иных печатных документов; - архивации, складского и бухгалтерского учета - обеспечивает возможность интеграции БС с другими информационными системами предприятия для ведения комплексного учета материальных и финансовых потоков.
Функци энальн ые п одсистемы биллинговой системы Генерации отчетов, генерации счетов Предварительной обработки данных Обслуживания Оперативного управления биллингом Архивации, складского и бухгалтерского учета о Продаж, маркетинга Оповещения клиентов Администрирования Рис. 1.1. Функциональные подсистемы БС Необходимо отметить, что состав и структура БС могут существенно отличаться. В первую очередь это обусловлено спецификой бизнес-процессов, протекающих в рамках той предметной области, в которой функционирует информационная система. Например, БС оператора сотовой связи во многом отличается от той, которая используется предприятиями-поставщиками коммунальных ресурсов. Кроме того, в зависимости от требований, предъявляемых к БС, возможно сужение или расширение ее функциональных возможностей. Поэтому возникает широкое разнообразие БС, предназначенных для удовлетворения нужд конкретной компании.
Проанализировав главные задачи и запросы бизнеса, была составлена внутренняя структура типичной полнофункциональной БС (рис. 1.2), где основными компонентами являются: коллекторы информации о потребленных услугах; система аутентификации абонентов; ядро (бизнес-логика); многоуровневая БД; модуль авторизации; модуль анализа типов услуг; модуль разграничения доступа; модуль статистики; административный интерфейс для управления абонентами; интерфейс управления счетами абонентов и тарифами для отдела продаж.
Модель транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде
В соответствии с [99], определение времени реакции на запрос конкретного As-го пользователя подразумевает применение декомпозиционного подхода, заключающегося в том, что для As -го пользователя определяются возможные схемы
выполнения запросов, соответственно вычисляются составляющие временных задержек, после чего рассчитывается время реакции по всем возможным схемам. Для каждого обслуживающего прибора определяются временные задержки, при-вычислении которых учитываются составляющие интегрированного потока запросов к этому прибору и процедур обслуживания.
С учетом описанного выше порядка обработки запросов в облачной сети, в отличие от предложенной в [99] структуризации потока заявок, в данной работе для Us -го узла выделены лишь две группы потока заявок, определяющие возможные схемы выполнения запросов: - первую группу образуют запросы, инициированные в узле Us, выполне ние которых подразумевает обращение к фрагментам БД, находящимся в других узлах, а окончательная обработка полученной информации производится в Us -м узле. Запросы данной группы формируются пользователями сети с регулярной структурой; - вторую группу образуют запросы, инициированные пользователями дру гих узлов, а в узле Us хранятся фрагменты БД, необходимые для их выполнения.
Такие запросы обрабатываются узлами подсетей, входящими в состав облака, а также серверами управления доставкой.
Режим функционирования системы и характеристики пользовательских запросов определяют процедуру обслуживания заявок. При выполнении запросов первой группы сначала в Us -м узле осуществляется получение данных, которые были предварительно считаны в другом узле, а затем их обработка. Выполнение запросов второй группы, инициированных пользователями других узлов информационной системы, включает чтение и обработку данных, размещенных в узле Us. Для передачи запросов от As -го пользователя к другим узлам и для передачи из Us -го узла данных в другие узлы требуются ресурсы канала. Поэтому введем следующие временные характеристики: - TOKи - время ожидания предоставления ресурсов канала для запросов, сформированных As-м пользователем; - Wusswers - время передачи по каналу связи запросов к коммутатору сети с регулярной структурой (сети пользователей, формирующих запросы) и обработки в нем служебной информации; - TOKsJoud - время ожидания предоставления ресурсов канала для передачи запросов от коммутатора сети с регулярной структурой к основному коммутатору сети облачной структуры; - WZud - время передачи по каналу связи запросов от коммутатора сети с регулярной структурой к основному коммутатору сети облачной структуры и обработки в последнем служебной информации; - Т(У8иГ) - время ожидания запроса в буферной памяти СУД; - WlUD - время декомпозиции запроса пользователя и формирования служебного запроса о размещении требуемых фрагментов БД к СМ; - ТОш - время нахождения запроса в буферной памяти СМ; - WSM - время формирования сервером метаданных ответа о размещении требуемых фрагментов БД для передачи в СУД; - TOPSUD - время пребывания ответа от СМ в буферной памяти СУД; - wfUD - время обработки ответа от СМ и выбора узлов сети облачной структуры, которые будут выполнять исходный запрос пользователя; - TOK AN - время ожидания предоставления ресурсов канала для передачи запросов от коммутатора сети облачной структуры к коммутатору подсети, к которой принадлежит узел, выбранный для обработки пользовательского запроса; - WN - время передачи по каналу связи запросов от коммутатора сети облачной структуры к конкретному узлу подсети, включая время обработки служебной информации коммутатором подсети; - T02s - время нахождения запроса в буферной памяти Us -го узла подсети, который будет обрабатывать запрос; - W2s - время обслуживания запроса в Us -м узле; - TOfUD - время пребывания результатов обработки запроса в буферной памяти СУД; - WD - время формирования сервером управления доставкой окончательного набора данных из результатов обработки запроса узлами; - TOK2z - время ожидания предоставления ресурсов канала для передачи данных в иz -й узел; - ТОъ - время пребывания результатов в буферной памяти Us -го узла, который сформировал исходный запрос; - wls - время окончательной обработки результатов в Us -м узле; - WK2s - время обслуживания каналом запросов второго типа. Введенные временные характеристики позволяют определить время ТАДТ1 выполнения запроса -го пользователя к uz -му узлу следующим образом: TA AJUz = (ТОКъ + WZr, + TOKZud + WZJ) + (TO SUD + Wsuo + TOKZut + wzud ) + +(TO SM + wm + TOK2ud+wzud )+(TO UD + wfUD + TOK ZUJ+wzud+TOK%N+wN ) + +(TO 2Z + w2z + TOKZN+w-N + mKZud+wzud )+(rofUD + wZD + TOKZud+wzud + + TOK2z + WZrS + WK2s) + (TOu +WU) = TOKu + 2WZrs + 6TOKZoud + 6WZud + + TO1 + Wsuo + TOSM + WSM + TO"UD + W"UD + 2TOKN + 2WN + T02z + W2z + TOfUD + + WZD + TOK2z + WK2s + TOu +WU, aaa 5 = \n, z = \n, s z.
В представленном выражении слагаемые имеют следующее значение: - (TOKls + WZrs + TOKZoud + WZud) - время с момента формирования запроса As-м пользователем до момента окончания его записи в буферную память СУД; - (TO SUD + WgUD + TOKZud + WZoud) - время с момента поступления запроса в буферную память СУД до момента окончания его записи в буферную память СМ; - (TOSM + WSM + TOKsZoud + WZud) - время с момента поступления запроса в буферную память СМ до момента окончания записи ответа от СМ в буферную память СУД; - (TO"UD + w"UD + TOKZuj + Kioud + TOKZN + WZN) – время с момента поступления запроса в буферную память СМ до момента окончания записи запроса в буферную память Us -го узла подсети, который будет обрабатывать запрос; - (T02z+w2z+TOKZN + wN + TOKZOUd + Kild) – время с момента поступления запроса буферную память Us -го узла до момента окончания записи результатов обработки запроса в буферную память СУД;
Исследование модели транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде
При оценке адекватности модели как существующей, так и проектируемой системы реально может быть использовано лишь ограниченное подмножество всех возможных значений входных параметров (рабочей нагрузки и внешней среды). В связи с этим для обоснования достоверности получаемых результатов моделирования большое значение имеет проверка устойчивости модели. Под устойчивостью модели понимают ее способность сохранять адекватность при исследовании эффективности системы на всем возможном диапазоне рабочей нагрузки, а также при внесении изменений в конфигурацию системы [136].
Согласно [139, 140], для проверки гипотезы об устойчивости результатов моделирования использован критерий Уилкоксона, который служит для проверки того, относятся ли две выборки к одной и той же генеральной совокупности. С его помощью можно определить, является ли сдвиг показателя в каком-то одном направлении более существенным, чем в другом. Нулевая гипотеза Н0: существенность сдвигов в типичном направлении не превосходит существенности сдвигов в нетипичном направлении. Для проверки устойчивости разработанной модели была проведена серия экспериментов для различных значений входных параметров (аналогично опытам, проведенным выше). Количество экспериментов для каждой из двух выборок п = 8 (объем выборки). Результаты приведены в табл. 3.5.
При одинаковом количестве положительных и отрицательных разностей необходимо вычислить суммы рангов отдельно для положительных и отрицательных разностей: Г =16,5, Т =19,5. За эмпирическое значение критерия т принимается меньшая сумма: 7 =16,5, т.е. более редким знаком (нетипичным сдвигом) является «-». Достоверные различия будут иметь место лишь в том случае, если При уровне значимости 0,05 (т.е. 5 % уровень ошибочности вывода о достоверных различиях) и числе сравниваемых пар п = 8 табличное значение критерия Уилкоксона Т = 5. Поскольку Тетр ткр, то различия недостоверные.
Таким образом, можно принять гипотезу Я0, т.е. время реакции системы имеет в обеих выборках одинаковое распределение, следовательно, исследуемая модель транзакционной системы для развертывания в облачной среде устойчива.
Устойчивость является положительным свойством модели. Однако если из менение входных воздействий или параметров модели (в некотором заданном диапазоне) не отражается на значениях выходных параметров, то польза от такой модели невелика. В связи с этим возникает задача оценивания чувствительности модели к изменению параметров рабочей нагрузки и внутренних параметров самой системы. Анализом чувствительности модели называют процедуру оценки влияния допусков входных параметров на ее выходные характеристики [141]. Практическая сторона анализа состоит в том, что устанавливается степень зависимости выходных параметров от входных характеристик. Эту степень влияния затем можно проранжировать и выявить наиболее значимые параметры. Такую оценку проводят по каждому параметру модели в отдельности. Основана она на том, что обычно диапазон возможных изменений параметра известен. В частности, для рассматриваемой модели в качестве входных параметров приняты те же характеристики, что и при определении ее адекватности. В ходе проведения серии экспериментов для различных значений входных параметров (значения остальных параметров модели были приняты такими же, как и в опытах выше) получены результаты, приведенные в табл. 3.6. отношение величины относительного приращения наблюдаемой переменной к величине относительного среднего приращения соответствующего параметра /1
Поскольку пара значений (Ахг;Ау.) характеризует чувствительность модели по параметру х,, то в результате проведенного исследования можно сделать следующие выводы: Модель транзакционной системы для развертывания в облачной среде обладает наибольшей чувствительностью к интенсивности формирования запросов. Модель менее чувствительна к количеству узлов облака и скорости передачи данных по каналу связи.
Исследование модели транзакционной системы с репликацией фрагментов базы данных для развертывания в облачной среде
Для проверки адекватности программно реализованной модели транзакционной системы с репликацией фрагментов БД для развертывания в облачной среде, были проведены соответствующие эксперименты и выполнен анализ их результатов. Эксперимент проводился для следующей конфигурации: облачная ВС состоит из одной подсети; число узлов п е [10;20] (в том числе 1 СУД и 1 СМ); число пользователей п є [10;20]; число независимых фрагментов РБД т = 50 ; - интенсивность формирования запросов, инициированных в узле Us, \ є [1;10] запросов/с, s = u; количество запросов g = 10; объем 7-го фрагмента VPj є[50000;150000] КБ, j = 1, і\ скорость считывания в s -том узле Ws є [60000;100000] КБ/с, s = 1,п; скорость записи в оперативную память s-го узла VDs є[1х107;3х107] КБ/с, - скорость передачи данных по каналу связи в є[1000;10000] КБ/с; постоянная задержка при передаче по каналу в0 = 3 х 10" с; постоянная задержка при обработке в узле а0 = 3 х 10 6 с; производительность процессора s-го узла PUS є[2,5х109;3,5х109] опера ций/с, s = 1,n\ - вероятность формирования запросов пользователями fAQ є[0;1], i = 1,n, объем считываемой информации bAFj є[1;1000] КБ, і = й, j = 1, \ количество процессорных операций brAFj є [1000;10000], i = 1,n, j = 1,m\ распределение копий j -го фрагмента РБД xF/Js = {0;1}, j = 1,m, s = 1ji; количество реплик каждого фрагмента РБД RC є [1;2]; прикрепление пользователей к конкретным копиям фрагментов РБД на уровне отдельных запросов задается матрицей z=zAgpu , zAQFU ={0;1}, i = 1,n,
В данном параграфе в качестве характеристики эффективности рассматривается среднее время реакции системы для всех пользователей. Отличие от исследования, проведенного в параграфе 3.2, состоит в том, что данной модели существенное влияние имеет количество реплик фрагментов РБД. Поэтому входными независимыми переменными (факторами) являются: х1 - интенсивность формирования запросов; х2 - скорость передачи данных по каналу связи; х3 – количество узлов облака; х4 - количество реплик каждого фрагмента РБД. Выходным параметром является у - время реакции системы. Требуется определить степень влияния параметров х1, х2, х3, х4 на среднее значение выходной переменной. По причине простоты анализа в качестве уравнения регрессии выбрана линейная зависимость у = а0 + а1х1 + а2х2 + а3х3 + а4х4. Для сокращения числа опытов использовался дробный факторный эксперимент 241, в котором тройное взаимодействие заменяется дополнительным фактором х1х2х3=х4 (табл. 3.7).
Построение системы электронного документооборота в облачной инфраструктуре
Архитектура представленной транзакционной системы имеет следующие преимущества: обеспечивается полная масштабируемость и эластичность на всех уровнях. Каждый запрос может направляться любому серверу (связке «Web-сервер/сервер приложений/сервер БД»), так что на этом уровне достигается полная масштабируемость. Кроме того, на уровне хранения данные реплицируются и могут разделяться, так что масштабируемость поддерживается и на этом уровне; система хранения данных отделена от серверов БД, которые параллельно и автономно обращаются к совместно используемым данным, содержащимся в системе хранения, что повышает быстродействие системы в целом; результаты запросов к БД сохраняются специальными серверами кэширования в своей основной памяти, а доступ к кэшу оказывается настолько быстрым, насколько это возможно; для повышения уровня масштабируемости и надежности системы используется механизм репликации данных; на всех уровнях можно использовать дешевую аппаратуру, что приводит к использованию большого числа машин, каждая из которых работает с данными довольно небольшого объема, чтобы иметь возможность выдержать нагрузку.
Такая архитектура полностью отвечает требованиям технологии Cloud Computing. Необходимо отметить, что кэширование способствует реализации потенциала данной технологии в отношении стоимости и масштабируемости, поскольку для кэширования также можно использовать недорогие компьютеры. Причем число кэширующих машин может тривиальным образом увеличиваться и уменьшаться в любой момент времени.
Учитывая изменение архитектуры БС, была также перепроектирована структура ее ПО. Клиентская часть ПК представляет собой приложение, реализованное в среде Microsoft Visual Studio 2010 на базе технологии WPF и работающее под управлением операционной системы Microsoft Windows. Это приложение устанавливается на компьютерах операторов, обслуживающих посетителей, и позволяет производить те действия, которые разрешены им правами (ввод показаний приборов учета, корректировка учетных данных, выполнение начислений, перерасчетов, обработка входных реестров и т.д.). Однако функционал, доступ ный абонентам, сильно ограничен (по сравнению с операторами), поскольку для изменения учетных сведений, выполнения перерасчетов абоненты должны явиться в офис с необходимыми документами. Исходя из этого, абонентам нецелесообразно скачивать и устанавливать на своем компьютере полноценное приложение, но с ограниченными правами. Кроме того, это повышает уязвимость системы, в которой обрабатываются персональные данные. Еще одним фактором является зависимость WPF-приложений от операционной системы, так как невозможно предугадать, на какой платформе работает то или иное устройство удаленного пользователя (персональный компьютер, смартфон и пр.). Поэтому для организации доступа абонентов на Web-сервере центрального офиса разворачивается Web-сайт, написанный на языке ASP.Net и работающий под управлением IIS. Тогда абонентам необходимо иметь лишь браузер и доступ в Интернет. Такое решение является гибким, независимым от платформы и не угрожает безопасности данных, хранящихся в системе.
Следующим слоем архитектуры рассматриваемой системы является уровень Web-серверов и серверов приложений. На сервере приложений функционируют WCF-сервисы, посредством которых осуществляется выполнение тех или иных процедур и функций, вызываемых клиентской частью приложения в процессе работы пользователей. Эти сервисы являются связующим звеном между клиентом и сервером БД. Web-сервер предназначен для организации Web-доступа пользователей к системе. На нем разворачивается IIS и Web-сайт, который в свою очередь вызывает WCF-сервисы сервера приложений. Благодаря такому решению достигается универсальность и изолированность подсистем, что является важным преимуществом ПК «Биллинговая система» перед ПК «Абонентский отдел. Физические лица». Стоит отметить, что Web-сервер и сервер приложений могут физически располагаться как на одном, так и на отдельных серверах (в зависимости от нагрузки). Такая возможность положительным образом сказывается на масштабируемости данного слоя архитектуры ПК.
Все длительные и ресурсоемкие операции в ПК «Биллинговая система» реализованы в виде процедур и функций сервера приложений. Хранимые процедуры и функции БД написаны на языке TSQL (Transact-SQL), который является расширением стандарта SQL-92, и на языке C# (CLR-проект) и подключены к БД в виде сборки.
Важным преимуществом ПК «Биллинговая система» является наличие системы обновления ПО, которая упрощает процесс администрирования приложения. Система обновления реализована на базе технологии Click-Once, позволяющей максимально автоматизировать данный процесс и существенно уменьшить трудоемкость этой операции. Данная система является автономной и может использоваться и в других системах, построенных на платформе, аналогичной ПК «Биллинговая система». Все пакеты обновлений загружаются в отдельную БД обновлений ПО и при подключении пользователей к системе им автоматически отправляются актуальные клиентские модули ПО.
Рассматриваемый ПК «Биллинговая система» реализован с использованием технологии Entity-Framework, т.е. в программном модуле обращение идет не к таблицам БД, а к объектной модели, построенной на основе структуры БД (модель данных). Такой подход значительно упрощает процесс разработки и изменения ПО, а также способствует повышению структурированности ПО. Непосредственное взаимодействие с БД осуществляется при помощи провайдера данных, который зависит от источника данных (Microsoft SQL Server, Oracle, Firebird и др.).
На рис. 4.8 изображена модифицированная структура ПО ПК «Биллинговая система». Основные модификации, отличающие предложенную структуру ПО БС от известных решений, состоят в следующем. Введена подсистема централизованного управления, предназначенная для организации взаимодействия компонентов ПК на основе регламентированных интерфейсов. Подсистема распараллеливает задачи, что, во-первых, дает возможность более эффективного использования вычислительных ресурсов облака, а во-вторых, позволяет пользователю продолжить работу в приложении, не дожидаясь окончания выполнения длительной и ресурсоемкой операции (при условии, что данная операция не является критичной и допускает выполнение в фоновом режиме). Следующим отличием является наличие подсистемы обновления ПО и отдельной БД, содержащей пакеты обновлений. Кроме того, для организации доступа к данным, находящимся в облаке, предлагается использовать слой модели данных БД. При переходе на другую облачную платформу такая реализация позволит минимизировать модификацию ПО, заменив лишь драйвер для доступа к БД.