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

  • Статья

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

Транзакционные данные

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

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

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

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

Стандартные характеристики данных о транзакциях

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

Требование Description
нормализация Высокая степень нормализации
Схема Схема при записи (строгое соблюдение)
Согласованность Строгая согласованность (гарантии ACID)
Целостность Высокая степень целостности данных
Использование транзакций Да
Стратегия блокировки Пессимистическая или оптимистическая
Возможность обновления Да
Возможность добавления Да
Рабочая нагрузка Большое число операций записи, среднее число операций чтения
Индексирование Первичный и вторичные индексы
Размер данных Небольшой и средний размер
Модель Реляционная
Форма представления данных табличный
Гибкость запросов Высокая гибкость
Масштабировать Небольшой (МБ) и большой (несколько ТБ)

Когда следует использовать это решение:

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

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

Сложности

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

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

OLTP в Azure

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

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

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

Основные критерии выбора

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

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

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

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

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

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

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

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

Матрица возможностей

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

Общие возможности

Возможность База данных SQL Azure SQL Server на виртуальной машине Azure. База данных Azure для MySQL База данных Azure для PostgreSQL
Управляемая служба Да No Да Да
Запуск на платформе Н/П Windows, Linux, Docker Неприменимо Неприменимо
Программируемость 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

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

Масштабируемость

Возможность База данных SQL Azure SQL Server на виртуальной машине Azure. База данных Azure для MySQL База данных Azure для PostgreSQL
Максимальный размер экземпляра базы данных 4 ТБ 256 ТБ 16 ТБ 16 ТБ
Поддержка пулов емкости Да Да No No
Поддержка горизонтального увеличения масштаба кластеров No Да No No
Динамическая масштабируемость (увеличение масштаба) Да No Да Да

Возможности для поддержки аналитических рабочих нагрузок

Возможность База данных SQL Azure SQL Server на виртуальной машине Azure. База данных Azure для MySQL База данных Azure для PostgreSQL
Темпоральные таблицы Да Да No No
Таблицы в памяти (оптимизированные для памяти) Да Да No No
Поддержка columnstore Да Да No No
Адаптивная обработка запросов Да Да No No

Возможности доступности

Возможность База данных SQL Azure SQL Server на виртуальной машине Azure. База данных Azure для MySQL База данных Azure для PostgreSQL
Вторичные реплики, доступные для чтения Да Да Да Да
Георепликация Да Да Да Да
Автоматический переход на вторичный ресурс Да No No No
Восстановление на определенный момент времени Да Да Да Да

Возможности системы безопасности

Возможность База данных SQL Azure SQL Server на виртуальной машине Azure. База данных Azure для MySQL База данных Azure для PostgreSQL
Безопасность на уровне строк Да Да Да Да
Маскирование данных Да Да No No
Прозрачное шифрование данных Да Да Да Да
Ограничение доступа для определенных IP-адресов Да Да Да Да
Ограничение доступа для разрешения доступа только к виртуальной сети Да Да Да Да
Проверка подлинности Microsoft Entra Да No Да Да
Проверка подлинности Active Directory No Да No No
Многофакторная проверка подлинности Да No Да Да
Поддержка функции Always Encrypted Да Да No No
Частный IP-адрес No Да No No

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Следующие шаги