Поделиться через

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

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

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

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

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

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

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

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

Данные транзакций, как правило, имеют следующие признаки.

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

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

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

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

Сложности

Система OLTP может создать несколько проблем:

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

  • При проведении аналитики и отчетности по высоконормализованным данным запросы, как правило, будут сложными, так как большинству запросов необходимо денормализовать данные, используя соединения. Повышенная нормализация может затруднить запросы бизнес-пользователей без помощи администратора базы данных (DBA) или разработчика данных.

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

OLTP в Azure

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

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

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

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

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

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

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

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

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

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

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

  • Требуется ли для рабочей нагрузки гарантированная транзакция ACID? Если вы работаете с нереляционными данными, рассмотрите azure Cosmos DB, которая обеспечивает гарантии ACID с помощью транзакционных пакетных операций в логическом разделе.

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

  • Требуется ли ваше решение распределенных транзакций? Если да, рассмотрите возможность эластичных транзакций в Базе данных SQL Azure и Управляемом экземпляре SQL. Управляемый экземпляр SQL также поддерживает традиционные вызовы через координатора распределенных транзакций (MSDTC).

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

  • Last updated on