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

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

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

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

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

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

• < Назад
• Вперёд >

Система оперативной обработки данных (ON LINE TRANSACTION PROCESSING) OLTP рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей. Эти системы требуют защиты от несанкционированного доступа, от нарушения целостности данных, аппаратных и программированных сбоев.

Их характеризует малое время ожидания выполнения запросов.

Сфера применения √ это сфера платежей, учета, резервирования мест, банки и биржевые операции

Транзакция - это некоторое законченное с точки зрения пользователя действие над БД.

Системы аналитической обработки данных (ON LINE ANALIZIS PROCESSING) OLAP- это системы поддержки принятия решений, ориентированны на выполнение более сложных запросов, требующих статистической обработки исторических данных, накопленных за определенный промежуток времени. Аналитические системы включают:

1. средства обработки информации на основе методов искусственного интеллекта

2. средства графического представления данных.

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

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

Приведенные классы систем (OLAP и OLTP), они основаны на использовании СУБД, но типы запросов сильно отличаются.

Обработка транзакций в OLTP системах

Транзакция - неделимая с позиции воздействия на БД последовательность операций манипулирования данными. Это может быть операция чтения, удаления, вставки и т.д.

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

Транзакция должна обладать 4 основными свойствами:

1. атомарность, транзакция должна выполнятся как единая операция доступа к БД, она должна быть выполнена полностью или не выполнена вообще.

2. согласованность , гарантирует взаимную целостность данных.

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

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

Результатом выполнения транзакции может быть ее фиксация и откат.

Фиксация - это действие, обеспечивающее запись в БД всех изменений.

Откат - если нормальное завершение транзакции невозможно, БД возвращается в исходное состояние, все изменения аннулируются.

При откате и фиксации транзакции используется журнал транзакций, в котором сохраняются все изменения.

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

При откате СУБД по журналу транзакций восстанавливает те строки, которые были модифицированы.

Границы транзакции - это первая и последняя, входящая в неё операции. Предполагается, что транзакция начинается с 1-го SQL оператора, следующие операторы составляют тело транзакции и тело может разветвляется:

1. SQL оператором commit work

SQL оператором rollback

2. простым завершением оператора, вызвавшего транзакцию.

Точки сохранения - применяются в длинных транзакциях, т.е. в теле транзакции может быть определены точки, в которых сохраняется состояние БД.

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

Проблемы:

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

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

Для устранения этого используют сериализацию (совместная отработка):

1. транзакция не может получить доступ к незафиксированным данным

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

В современном СУБД сериализация транзакций реализуется через механизм блокировок: на время выполнения транзакции 1 СУБД блокирует часть базы данных к которой транзакция 1 обращается. Блокировка сохраняется до момента фиксации транзакции 1, если в этот момент другая транзакции 2 обращается к блокированным данным, то транзакции 2 приостанавливается до момента завершения транзакции 1

Взаимоблокировка транзакций

Пусть транзакция т1 обновляет отношение - о1. Далее эта транзакция т1 пытается модифицировать отношение о2 , которая была ранее заблокирована транзакцией т2. Транзакция т1 переводится в состояния ожидания пока не снята блокировка с отношения о2; в тот же момент транзакция т2 пытается изменить данные отношения о1, ранее заблокирована транзакцией т1. СУБД вынуждена перевести в состояния ожидания и транзакцию т2 следовательно возникает ситуация взаимоблокировки транзакций.

СУБД периодически проверяет блокировку и если есть взаимоблокировки, то одна из транзакции насильственно прерывается.

Средства восстановления после сбоев

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

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

Обзор ИТ, предназначенных для оперативной и аналитической обработки данных

Успешно изучив материал, Вы будете знать :

понятие и основное назначение OLTP-систем;

понятие и основное назначение OLAP-систем;

классы OLAP-систем;

задачи, решаемые OLTP- и OLAP-системами.

После изучения данной темы Вы будете уметь :

отличать задачи, решаемые OLTP- и OLAP-системами;

ориентироваться в классах OLAP-систем.

После изучения материала Вы будете обладать навыками использования OLTP- и OLAP-системам в работе менеджера.

Основные понятия к теме 7

технологии, ориентированные на оперативную (транзакционную) обработку данных. Эти технологии лежат в основе КИСУ, предназначенных для оперативной обработки данных. Называются подобные системы - OLTP (online transaction processing ) системы ;

технологии, ориентированные на анализ данных и принятие решений. Эти технологии лежат в основе КИСУ, предназначенных для анализа накопленных данных. Называются подобные системы - OLAP (online analytical processing ) системы .

OLAP-системы

Основное назначение OLAP-систем : динамический многомерный анализ исторических и текущих данных, стабильных во времени; анализ тенденций; моделирование и прогнозирование будущего. Такие системы, как правило, ориентированы на обработку произвольных, заранее не регламентированных запросов. В качестве основных характеристик этих систем можно отметить следующие :

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

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

автоматическое отображение логической структуры данных во внешние системы;

динамическая обработка разряженных матриц эффективным способом.

Термин OLAP часто отождествляют с системами поддержки принятия решений DSS (Decision Support Systems). А в качестве синонима термина «решения» используют Data Warehousing - «хранилища (склады) данных» . Под этим понимается набор организационных решений, программных и аппаратных средств для обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников.

«Склады данных» позволяют обрабатывать данные, накопленные за длительные периоды времени. Эти данные являются разнородными (и не обязательно структурированными). Для «складов данных» присущ многомерный характер запросов. Огромные объемы данных, сложность структуры как данных, так и запросов - все это требует использования специальных методов доступа к информации.

В других источниках понятие Системы Поддержки Принятия Решений (СППР) считается более широким. Хранилища данных и средства оперативной аналитической обработки могут служить одними из компонентов архитектуры СППР.

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

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

поддержку нескольких пользователей, редактирующих БД.

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

прогнозирование, выявление тенденций и статистический анализ.

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

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

OLAP-системы можно разбить на три класса.

1 класс. Наиболее сложными и дорогими из них являются основанные на патентованных технологиях серверы многомерных БД . Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для анализа данных внешние программы работы с электронными таблицами. Продукты этого класса в наибольшей степени соответствуют условиям применения в рамках крупных информационных хранилищ. Для их обслуживания требуется целый штат сотрудников, занимающихся как установкой и сопровождением системы, так и формированием представлений данных для конечных пользователей. Обычно подобные пакеты довольно дороги. В качестве примеров продуктов этого класса можно привести систему Essbase корпорации Arbor Software, Express фирмы IRI (входящей теперь в состав Oracle), Lightship производства компании Pilot Software и др.

2 класс OLAP-систем - реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP-системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат на обслуживание специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ/Vision корпорации IQ Software, DSS/Server и DSS/Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage.

ROLAP-средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

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

иметь мощный оптимизированный для OLAP генератор SQL-выражений, позволяющий применять многопроходные SQL-операторы SELECT и/или коррелированные подзапросы;

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

генерировать SQL-выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

3 класс OLAP-систем - инструменты генерации запросов и отчетов для настольных ПК , дополненные OLAP-функциями или интегрированные с внешними средствами, выполняющими такие функции. Эти весьма развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на ПК конечного пользователя. Указанный подход, позволяющий обойтись как без дорогостоящего сервера многомерной БД, так и без сложного промежуточного слоя метаданных, необходимого для ROLAP-средств, обеспечивает в то же время достаточную эффективность анализа. Эти средства для настольных ПК лучше всего подходят для работы с небольшими, просто организованными БД. Потребность в квалифицированном обслуживании для них ниже, чем для других OLAP-систем, и примерно соответствует уровню обычных сред обработки запросов. В числе основных участников этого сектора рынка - компания Brio Technology со своей системой Brio Query Enterprise, Business Objects с одноименным продуктом и Cognos с PowerPlay.

OLTP-системы

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

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

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

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

Задачи, решаемые OLTP- и OLAP-системами

Задачи, эффективно решаемые каждой из систем, определим на основе сравнительных характеристик OLTP- и OLAP-систем (табл. 7.1, 7.2).

В области ИТ управления существуют два взаимно дополняющих друг друга направления:

• технологии, ориентированные на оперативную (транзакционную) обработку данных - OLTP (online transaction processing) системы;

  технологии, ориентированные на анализ данных и принятие решений - OLAP (online analytical processing) системы.

Основное назначение OLAP-систем - динамический многомерный анализ исторических и текущих данных, стабильных во времени, анализ тенденций, моделирование и прогнозирование будущего.

OLAP-системы можно разбить на три класса.

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

2 класс. Реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной.

3 класс. Инструменты генерации запросов и отчетов для настольных ПК, дополненные OLAP-функциями или интегрированные с внешними средствами, выполняющими такие функции. Эти системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на ПК конечного пользователя.

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

Data Warehousing - «хранилища (склады) данных». Под этим понимается набор организационных решений, программных и аппаратных средств для обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников.