線上交易處理 (OLTP)

2025-04-24

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

交易資料

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

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

事務資料庫可以使用各種鎖定策略來支援交易的強一致性，例如悲觀鎖定，以確保在企業環境中，所有使用者和程序的所有數據都保持高度一致。

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

事務數據的典型特性

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

需求	描述
正規化	高度正規化
模式	寫入時套用的架構，嚴格執行
一致性	強式一致性，ACID 保證
完整性	高完整性
使用交易	是的
鎖定策略	悲觀或樂觀
可更新	是的
可擴充	是的
工作負載	繁重寫入、適度讀取
編製索引	主要和次要索引
Datum 大小	中小型
模型	關聯式
數據圖形	表格化
查詢彈性	高度彈性
規模	小型（MB）到大型（幾個TB）

使用此解決方案的時機

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

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

挑戰

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

雖然有例外狀況，例如規劃良好的 SQL Server 型解決方案，但 OLTP 系統不一定適合處理大量數據的匯總。針對依賴數百萬個個別交易匯總計算的數據進行分析，對於 OLTP 系統來說非常耗用資源。執行速度可能會很慢，而且會封鎖資料庫中的其他交易，而導致速度變慢。
對高度正規化的數據進行分析和報告時，查詢通常會很複雜，因為大部分的查詢都需要使用聯結來取消正規化數據。此外，OLTP 系統中資料庫物件的命名慣例通常很簡潔。由於正規化增加及簡潔的命名慣例，商務使用者在沒有 DBA 或資料開發人員協助的情況下，很難查詢 OLTP 系統。
視儲存的交易數目而定，無限期地儲存交易歷程記錄，並將太多數據儲存在任何一個數據表中，可能會導致查詢效能變慢。常見的解決方案是在 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 資料庫	Azure 虛擬機器中的 SQL Server	適用於 MySQL 的 Azure 資料庫	適用於 PostgreSQL 的 Azure 資料庫
是受控服務	是的	無	是的	是的
在平台上執行	N/A	Windows、Linux、Docker	N/A	N/A
可程式性 ¹	T-SQL、.NET、R	T-SQL、.NET、R、Python	SQL	SQL、PL/pgSQL、PL/JavaScript （v8）

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

延展性功能

能力	Azure SQL 資料庫	Azure 虛擬機器中的 SQL Server	適用於 MySQL 的 Azure 資料庫	適用於 PostgreSQL 的 Azure 資料庫
資料庫實例大小上限	4 結核病	256 TB	16結核病	16結核病
支援容量集區	是的	是的	無	無
支援叢集向外延展	無	是的	無	無
動態延展性（向上擴展）	是的	無	是的	是的

分析工作負載能力

能力	Azure SQL 資料庫	Azure 虛擬機器中的 SQL Server	適用於 MySQL 的 Azure 資料庫	適用於 PostgreSQL 的 Azure 資料庫
時間表	是的	是的	無	無
記憶體內部（記憶體優化）資料表	是的	是的	無	無
欄式儲存支援	是的	是的	無	無
自適性查詢處理	是的	是的	無	無

可用性功能

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

安全性功能

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