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

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

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

Обычно транзакции должны быть атомарными и согласованными. Атомарность означает, что транзакция всегда полностью завершается успешно либо неудачно как одна элементарная операция и никогда не остается в состоянии частичной завершенности. Если не удается выполнить транзакцию, система базы данных должна откатить все шаги, которые уже выполнены в рамках этой транзакции. В традиционной системе управления реляционными базами данных (RDBMS) этот откат происходит автоматически, если транзакция не может быть завершена. Согласованность означает, что после выполнения транзакции данные всегда остаются в допустимом состоянии. (Это очень неофициальные описания атомарности и согласованности. Существуют более формальные определения этих свойств, таких как ACID.)

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

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

Как правило, данные о транзакциях имеют следующие характеристики:

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

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

При реализации и использовании системы OLTP могут возникнуть некоторые сложности:

• Системы OLTP не всегда хорошо обрабатывают агрегаты по большим объемам данных, хотя существуют исключения, такие как хорошо запланированное решение на основе SQL Server. Анализ данных, которые основаны на статистических вычислениях более миллиона отдельных транзакций, является очень ресурсоемким для системы OLTP. Он может медленно выполняться и привести к снижению производительности из-за блокировки других транзакций в базе данных.

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

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

Такие приложения, как веб-сайты, размещенные в веб-приложениях службы приложений, REST API, работающие в службе приложений, или мобильные или классические приложения взаимодействуют с системой OLTP, как правило, через посредника REST API.

На практике большинство рабочих нагрузок не являются исключительно OLTP. Как правило, также имеется аналитическая составляющая. Кроме того, растет потребность в создании отчетов в режиме реального времени, например создание отчетов в операционной системе. Это также называется гибридной транзакционной или аналитической обработкой (HTAP) (гибридная транзакционная и аналитическая обработка). Дополнительные сведения см. в разделе "Интерактивная аналитическая обработка" (OLAP).

Все следующие хранилища данных в Azure соответствуют основным требованиям к OLTP и управлению данными о транзакциях:

• База данных SQL Azure
• SQL Server в виртуальной машине Azure
• База данных Azure для MySQL
• База данных Azure для PostgreSQL

Чтобы ограничить количество вариантов, сначала ответьте на следующие вопросы:

• Вы хотите использовать управляемую службу, а не управлять собственными серверами?

• Зависит ли ваше решение от совместимости с Microsoft SQL Server, MySQL или PostgreSQL? Количество вариантов для хранилищ данных может быть ограничено приложением из-за драйверов, поддерживаемых для взаимодействия с хранилищем данных, или на основе предположений касательно используемой базы данных.

• Выдвигаются ли особенно высокие требования к пропускной способности операций записи? Если да, выберите вариант с поддержкой таблиц в памяти.

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

• Нужно ли обеспечить чтение данных с низкой задержкой в нескольких регионах? Если да, выберите вариант, который поддерживает чтение вторичных реплик.

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

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

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

[1] Без поддержки клиентского драйвера, что позволяет подключать различные языки программирования и использовать хранилище данных OLTP.

• Общие сведения о таблицах Memory-Optimized
• In-Memory обзор и сценарии использования OLTP
• Оптимизация производительности с помощью технологий в памяти в Базе данных SQL Azure и Управляемом экземпляре SQL Azure
• Распределенные транзакции между облачными базами данных

• Руководство по архитектуре данных Azure
• Обработка транзакций IBM z/OS в Сети в Azure