Сравнение оперативной обработки транзакций и поддержки принятия решений

Оперативная обработка транзакций

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

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

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

Вопросы проектирования оперативной обработки транзакций

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

• Хорошее размещение данных

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

• Короткие транзакции для минимизации долгосрочных блокировок и улучшения параллелизма

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

• Резервное копирование в оперативном режиме

  Системы OLTP зачастую отличаются постоянным выполнением операций с практически полным отсутствием простоев, то есть они работают 24 часа в сутки, 7 дней в неделю. Хотя SQL Server Database Engine позволяет производить резервное копирование и во время работы базы данных, его следует назначать на время минимальной активности, чтобы снизить влияние на скорость работы пользователей.

• Высокая нормализация базы данных

  Следует уменьшать избыточность данных, чтобы повысить скорость обновления и улучшить параллелизм. Уменьшение объемов данных также повышает скорость резервного копирования, так как уменьшается затрачиваемое на него время.

• Минимизация исторических и статистических данных или полное их отсутствие

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

• Аккуратное использование индексов

  Обновления индексов производятся каждый раз при добавлении или изменении строк. Чтобы избежать переиндексирования часто обновляемых таблиц, делайте индексы как можно более «узкими». Для проектирования индексов рекомендуется пользоваться помощником по настройке ядра СУБД.

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

Поддержка принятия решений

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

Вопросы проектирования систем поддержки принятия решений

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

• Обильное индексирование

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

• Денормализация базы данных

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

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