線上交易處理 (OLTP)

  • 發行項

使用計算機系統管理事務數據稱為在線事務處理（OLTP）。 OLTP 系統會在組織的日常作業中記錄商務互動，並支援查詢此數據來進行推斷。

交易資料

事務數據是追蹤組織活動相關互動的資訊。 這些互動通常是商業交易，例如從客戶收到的付款、向供貨商付款、通過庫存、訂購或交付的服務行動的產品。 交易事件，代表交易本身，通常包含時間維度、某些數值，以及其他數據的參考。

交易通常需要不可 部分完成 且 一致。 不可部分完成表示整個交易一律會成功或失敗為一個工作單位，而且永遠不會處於半完成狀態。 如果交易無法完成，資料庫系統必須回復已做為該交易一部分的任何步驟。 在傳統的 RDBMS 中，如果無法完成交易，就會自動進行此復原。 一致性表示交易一律讓數據保持有效狀態。 （這些是不可部分完成性和一致性的非正式描述。這些屬性有更正式的定義，例如 ACID。

事務資料庫可以使用各種鎖定策略來支援交易的強式一致性，例如悲觀鎖定，以確保所有使用者和進程在企業內容中所有數據都非常一致。

使用事務數據的最常見部署架構是 3 層架構中的數據存放區層。 3 層架構通常由表示層、商業規則層和數據存放區層所組成。 相關的部署架構是 多層 式架構，其可能會有多個仲介層處理商業規則。

事務數據的典型特性

事務數據通常具有下列特性：

需求 描述
正規化 高度正規化
結構描述 寫入上的架構，強式強制執行
一致性 強式一致性，ACID 保證
完整性 高完整性
使用交易 Yes
鎖定策略 悲觀或樂觀
可更新 Yes
可附加 Yes
工作負載 大量寫入、中度讀取
編製索引 主要和次要索引
Datum 大小 中小型
模型 關聯式
數據圖形 表格式
查詢彈性 高度彈性
調整 小型 （MB） 到大型 （少數 TB）

使用此解決方案的時機

當您需要有效率地處理和儲存商務交易，並立即以一致的方式提供給用戶端應用程式時，請選擇 OLTP。 當任何有形的處理延遲會對企業的日常作業產生負面影響時，請使用此架構。

OLTP 系統的設計目的是要有效率地處理和儲存交易，以及查詢事務數據。 OLTP 系統有效率地處理和儲存個別交易的目標，部分是透過數據正規化來完成，也就是說，將數據分成較少備援的較小區塊。 這支援效率，因為它可讓 OLTP 系統獨立處理大量交易，並避免在備援數據存在時維護數據完整性所需的額外處理。

挑戰

實作和使用 OLTP 系統可能會造成一些挑戰：

  • 雖然有例外狀況，例如規劃良好的 SQL Server 型解決方案，但 OLTP 系統不一定適合處理大量數據的匯總。 針對依賴數百萬個個別交易匯總計算的數據進行分析，對於 OLTP 系統來說非常耗用資源。 執行速度可能會很慢，而且會封鎖資料庫中的其他交易，而導致速度變慢。
  • 對高度正規化的數據進行分析和報告時，查詢通常會很複雜，因為大部分的查詢都需要使用聯結來取消正規化數據。 此外，OLTP 系統中資料庫物件的命名慣例通常很簡潔。 加上 terse 命名慣例的增強正規化，讓商務使用者難以查詢 OLTP 系統，而不需要 DBA 或數據開發人員的協助。
  • 視儲存的交易數目而定，無限期地儲存交易歷程記錄，並將太多數據儲存在任何一個數據表中，可能會導致查詢效能變慢。 常見的解決方案是在 OLTP 系統中維護相關的時間範圍（例如目前的會計年度），並將歷程記錄數據卸除至其他系統，例如數據超市或 數據倉儲。

Azure 中的 OLTP

應用程式，例如裝載在 App Service Web Apps中的網站、在App Service 中執行的REST API，或行動或傳統型應用程式，通常是透過 REST API 媒介與 OLTP 系統通訊。

實際上，大部分的工作負載並非純粹是 OLTP。 也有分析元件。 此外，實時報告的需求也會增加，例如針對操作系統執行報表。 這也稱為 HTAP（混合式交易和分析處理）。 如需詳細資訊，請參閱 線上分析處理 （OLAP） 。

在 Azure 中，下列所有資料存放區都會符合 OLTP 的核心需求和管理事務數據：

索引鍵選取準則

若要縮小選擇範圍，請從回答下列問題開始：

  • 您要受控服務，而不是管理自己的伺服器嗎？

  • 您的解決方案是否具有 Microsoft SQL Server、MySQL 或 PostgreSQL 相容性的特定相依性？ 您的應用程式可能會限制您可以根據支援與資料存放區通訊的驅動程式來選擇的數據存放區，或它針對使用哪一個資料庫所做的假設。

  • 您的寫入輸送量需求特別高嗎？ 如果是，請選擇提供記憶體內部數據表的選項。

  • 您的解決方案是否為多租使用者？ 如果是，請考慮支援容量集區的選項，其中多個資料庫實例會從彈性資源集區中繪製，而不是每個資料庫的固定資源。 這可協助您更妥善地將容量分散到所有資料庫實例，並讓您的解決方案更具成本效益。

  • 您的數據是否需要在多個區域中以低延遲讀取？ 如果是，請選擇支援可讀取次要複本的選項。

  • 您的資料庫是否需要跨地理圖形區域具有高可用性？ 如果是，請選擇支援地理複寫的選項。 也請考慮支援從主要複本自動故障轉移到次要複本的選項。

  • 您的資料庫是否有特定的安全性需求？ 如果是，請檢查提供數據列層級安全性、數據遮罩和透明數據加密等功能的選項。

功能矩陣

下表摘要說明功能的主要差異。

一般功能

功能 Azure SQL Database Azure 虛擬機器中的 SQL Server 適用於 MySQL 的 Azure 資料庫 適用於 PostgreSQL 的 Azure 資料庫
是受控服務 是 無 .是 Yes
在平台上執行 N/A Windows、Linux、Docker N/A N/A
可程式性 1 T-SQL、.NET、R T-SQL、.NET、R、Python SQL SQL、PL/pgSQL、PL/JavaScript （v8）

[1] 不包括用戶端驅動程序支援，這可讓許多程式設計語言連線並使用 OLTP 資料存放區。

延展性功能

功能 Azure SQL Database Azure 虛擬機器中的 SQL Server 適用於 MySQL 的 Azure 資料庫 適用於 PostgreSQL 的 Azure 資料庫
資料庫實例大小上限 4 TB 256 TB 16 TB 16 TB
支援容量集區 Yes .是 無 No
支援叢集向外延展 No .是 無 No
動態延展性 （相應增加） 是 無 .是 Yes

分析工作負載功能

功能 Azure SQL Database Azure 虛擬機器中的 SQL Server 適用於 MySQL 的 Azure 資料庫 適用於 PostgreSQL 的 Azure 資料庫
暫存資料表 Yes .是 無 No
記憶體內部 （記憶體優化） 資料表 Yes .是 無 No
資料行存放區支援 是 .是 無 No
自適性查詢處理 Yes .是 無 No

可用性功能

功能 Azure SQL Database Azure 虛擬機器中的 SQL Server 適用於 MySQL 的 Azure 資料庫 適用於 PostgreSQL 的 Azure 資料庫
可讀取次要 Yes .是 .是 Yes
地理複寫 Yes .是 .是 Yes
自動故障轉移至次要 是 無 無 No
還原時間點 Yes .是 .是 Yes

安全性功能

功能 Azure SQL Database Azure 虛擬機器中的 SQL Server 適用於 MySQL 的 Azure 資料庫 適用於 PostgreSQL 的 Azure 資料庫
資料列層級安全性 Yes .是 .是 Yes
資料遮罩 Yes .是 無 No
透明資料加密 Yes .是 .是 Yes
限制對特定IP位址的存取 Yes .是 .是 Yes
限制存取以只允許 VNet 存取 Yes .是 .是 Yes
Microsoft Entra 驗證 是 無 .是 Yes
Active Directory 驗證 No .是 無 No
多重要素驗證 是 無 .是 Yes
支援 Always Encrypted Yes .是 無 No
私人 IP No .是 無 No

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

下一步