在 Azure SQL 資料庫 中使用記憶體內部技術來優化效能
記憶體內部技術可讓您改善應用程式的效能,並可能降低資料庫的成本。
何時使用記憶體內部技術
藉由使用記憶體內部技術,您可以透過各種工作負載來達成效能改善:
- 交易 式 (OLTP)是大部分要求讀取或更新較小的數據集,例如建立/讀取/更新/刪除 (CRUD) 作業。
- 分析 (在線分析處理 (OLAP)),其中大多數查詢都有複雜的計算,以用於報告目的,也會定期排程執行負載(或大量載入)作業和/或將數據變更寫入現有數據表。 OLAP 工作負載通常會定期從 OLTP 工作負載更新。
- 混合 式交易/分析處理 (HTAP)會在相同數據集上執行 OLTP 和 OLAP 查詢。
記憶體內部技術可以藉由保留應該處理到記憶體的數據、使用查詢的原生編譯,或進階處理,例如基礎硬體上可用的批處理和 SIMD 指令,來改善這些工作負載的效能。
概觀
Azure SQL 資料庫 支援下列記憶體內部技術:
- 記憶體內部 OLTP 會增加每秒的交易數目,並減少事務處理的延遲。 受益於記憶體內部 OLTP 的案例包括:高輸送量的事務處理,例如交易和遊戲、事件或 IoT 裝置的數據擷取、快取、數據載入,以及臨時表和數據表變數案例。
- 叢集數據行存放區索引 可減少記憶體使用量(最多10倍),並改善報告和分析查詢的效能。 您可以將它與數據超市中的事實數據表搭配使用,以容納資料庫中更多數據並改善效能。 此外,您可以將它與作業資料庫中的歷程記錄數據搭配使用,以封存,且最多可以查詢 10 倍的數據。
- HTAP 的非叢集數據行存放區索引 可協助您透過直接查詢操作資料庫來即時深入解析業務,而不需要執行昂貴的擷取、轉換和載入 (ETL) 程式,並等候數據倉儲填入。 非叢集數據行存放區索引允許在 OLTP 資料庫上快速執行分析查詢,同時降低對作業工作負載的影響。
- HTAP 的記憶體優化叢集數據行存放區索引 可讓您執行快速的交易處理,並 同時 對相同數據執行分析查詢。
數據行存放區索引和記憶體內部 OLTP 分別於 2012 年和 2014 年引進 SQL Server。 Azure SQL 資料庫、Azure SQL 受控執行個體 和 SQL Server 共用記憶體內部技術的相同實作。
注意
如需詳細的逐步教學課程,以示範記憶體內部 OLTP 技術的效能優勢,使用AdventureWorksLT
範例資料庫和ostress.exe,請參閱 Azure SQL 資料庫 中的記憶體內範例。
記憶體內部技術的優點
由於查詢和事務處理更有效率,記憶體內部技術也協助您降低成本。 您通常不需要升級資料庫的定價層,以達到效能提升。 在某些情況下,您甚至可以減少定價層,同時仍會看到記憶體內部技術的效能改善。
藉由使用記憶體內部 OLTP,仲裁商務解決方案能夠將其工作負載加倍,同時將 70% 的 DTU 改善。 如需詳細資訊,請參閱 Azure SQL 資料庫 中的記憶體內部 OLTP。
注意
記憶體內部技術可在 Azure SQL 資料庫 的 進階版 層和 業務關鍵 層中使用。
本文說明 Azure SQL 資料庫 特有的記憶體內部 OLTP 和數據行存放區索引層面,也包含範例:
- 您會看到這些技術對記憶體和數據大小限制的影響。
- 您將瞭解如何管理在不同定價層之間使用這些技術的資料庫移動。
- 您會看到兩個範例,說明如何使用記憶體內部 OLTP,以及資料行存放區索引。
如需 SQL Server 中記憶體內部的詳細資訊,請參閱:
- 記憶體內部 OLTP 概觀和使用案例 (包括客戶案例研究的參考和入門資訊)
- 記憶體內部 OLTP 的檔
- 資料行存放區索引指南
- 混合式交易/分析處理 (HTAP),也稱為即時作業分析
記憶體內部 OLTP
記憶體內部 OLTP 技術藉由將所有數據保留在記憶體中,提供極快速的數據存取作業。 它也會使用特製化索引、查詢的原生編譯,以及無閂鎖的數據存取,以改善OLTP工作負載的效能。 有兩種方式可組織記憶體內部 OLTP 數據:
記憶體優化的數據列存放區 格式,其中每個數據列都是個別的記憶體物件。 這是針對高效能 OLTP 工作負載優化的傳統記憶體內部 OLTP 格式。 記憶體優化資料表有兩種類型可用於記憶體優化數據列存放區格式:
- 長期數據表 (SCHEMA_AND_DATA)會在伺服器重新啟動後保留放置於記憶體中的數據列。 這種類型的數據表的行為就像傳統數據列存放區數據表,具有記憶體內部優化的額外優點。
- 無法還原的數據表 (SCHEMA_ONLY),其中數據列在重新啟動後不會保留。 這種類型的數據表是針對暫存數據而設計的(例如,取代臨時表),或您需要先快速載入數據的數據表,再將其移至某些保存數據表(稱為臨時表)。
記憶體優化的數據行存放 區格式,其中數據會以單欄格式組織。 此結構是針對 HTAP 案例所設計,您必須在 OLTP 工作負載執行所在的相同數據結構上執行分析查詢。
注意
記憶體內部 OLTP 技術是針對可完全位於記憶體中的數據結構所設計。 由於記憶體內部數據無法卸除至磁碟,請確定您使用的資料庫具有足夠的記憶體。 如需詳細資訊,請參閱 記憶體內部 OLTP 的數據大小和記憶體上限。
- 記憶體內部 OLTP 的快速入門: 快速入門 1:記憶體內部 OLTP 技術,以提升 T-SQL 效能。
記憶體內部 OLTP 的數據大小和記憶體上限
記憶體內部 OLTP 包含記憶體優化數據表,可用來儲存用戶數據。 這些數據表必須符合記憶體。 因為您直接在 SQL 資料庫 中管理記憶體,所以我們有用戶數據的配額概念。 這個想法稱為 記憶體內部 OLTP 記憶體。
每個支援的單一資料庫定價層和每個彈性集區定價層都包含一定數量的記憶體內部 OLTP 記憶體。
下列項目計入記憶體內部 OLTP 記憶體上限:
- 記憶體優化數據表和數據表變數中的作用中用戶數據列。 舊數據列版本不計入上限。
- 記憶體優化數據表上的索引。
- ALTER TABLE 作業的作業額外負荷。
如果您達到上限,您會收到配額不足的錯誤,且無法再插入或更新數據。 若要減輕此錯誤,請刪除資料或增加資料庫或集區的定價層。
如需監視記憶體內部 OLTP 記憶體使用率和設定警示的詳細數據,請參閱 監視記憶體內部記憶體內部記憶體。
關於彈性集區
使用彈性集區時,記憶體內部 OLTP 記憶體會跨集區中的所有資料庫共用。 因此,一個資料庫中的使用方式可能會影響其他資料庫。 這兩個風險降低措施如下:
Max-eDTU
針對低於整個集區之 eDTU 或虛擬核心計數的資料庫設定 或MaxvCore
。 此上限會將集區中任何資料庫中的記憶體內部 OLTP 記憶體使用率上限為對應至 eDTU 計數的大小。Min-eDTU
設定 大於 0 的 或MinvCore
。 此最低保證集區中的每個資料庫都有對應至所設定Min-eDTU
或vCore
的可用記憶體內部 OLTP 記憶體數量。
變更使用記憶體內部 OLTP 技術之資料庫的服務層級
您一律可以將資料庫升級至較高層級,例如從一般用途(虛擬核心)升級至 業務關鍵,或將標準 (DTU) 升級至 進階版。 可用的功能和資源只會增加。
但降級層級可能會對您的資料庫造成負面影響。 當您的資料庫包含記憶體內部 OLTP 物件時,從 業務關鍵 降級至一般用途(或 進階版 為標準或基本)時,影響特別明顯。 您可以輕鬆地 在資料庫中尋找記憶體內部物件。
降級之後無法使用記憶體優化數據表(即使它們仍保持可見)。 當您降低彈性集區的定價層,或將具有記憶體內部技術的資料庫移至一般用途、標準或基本彈性集區時,適用相同的考慮。
重要
一般用途或 Azure SQL 資料庫 的標準或基本 DTU 層不支援記憶體內部 OLTP。 因此,無法將具有任何記憶體內部 OLTP 對象的資料庫移至這其中一層。 降級資料庫之前,請移除所有記憶體優化數據表和數據表類型,以及所有原生編譯的 T-SQL 模組,或將它們轉換成數據列型物件。
業務關鍵 層中的相應減少資源:記憶體優化數據表中的數據必須符合與資料庫層相關聯的記憶體內部 OLTP 記憶體,或可在彈性集區中使用。 如果您嘗試相應減少階層,或將資料庫移至沒有足夠的記憶體內部 OLTP 記憶體的集區,作業會失敗。
判斷記憶體內部物件是否存在
有一種程式設計方式可瞭解指定的資料庫是否支援記憶體內部 OLTP。 您可以執行下列 Transact-SQL 查詢:
SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');
如果查詢傳 1
回 ,則此資料庫中支援記憶體內部 OLTP。
下列查詢會識別所有需要移除的物件,才能將資料庫降級為一般用途、標準或基本:
SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1
記憶體內部數據行存放區
記憶體內部資料行存放區技術可讓您在資料表中儲存和查詢大量數據。 數據行存放區技術會使用以數據行為基礎的數據儲存格式和批次查詢處理,以在傳統數據列導向記憶體的 OLAP 工作負載中取得高達 10 倍的查詢效能。 相較於未壓縮的資料大小,您也可以將資料壓縮提升高達 10 倍。
有兩種類型的數據行存放區模型可用來組織數據:
- 以單欄格式組織數據表中所有數據的叢集數據行存放區。 在此模型中,數據表中的所有數據列都會以單欄格式放置,可高度壓縮數據,並可讓您在數據表上執行快速分析查詢和報表。 視數據的性質而定,您的數據大小可能會減少 10x-100x。 叢集數據行存放區模型也可讓您快速擷取大量數據(大量載入),因為大於100,000個數據列的大型批次會在儲存在磁碟上之前壓縮。 此模型是傳統數據倉儲案例的絕佳選擇。
- 非叢集數據 行存放區,其中數據會儲存在傳統數據列存放區數據表中,而且數據行存放區格式中有索引用於分析查詢。 此模型可啟用混合式交易分析處理(HTAP):能夠在交易式工作負載上執行高效能的即時分析。 OLTP 查詢會在數據列存放區數據表上執行,該數據表已針對存取一小組數據列進行優化,而 OLAP 查詢則會在數據行存放區索引上執行,以較適合用於掃描和分析。 查詢優化器會根據查詢動態選擇數據列存放區或數據行存放區格式。 非叢集數據行存放區索引不會減少數據的大小,因為原始數據集會保留在原始數據列存放區數據表中,而不會有任何變更。 不過,其他數據行存放區索引的大小應該小於對等 B 型樹狀結構索引的大小。
注意
記憶體內部數據行存放區技術只會保留記憶體中處理所需的數據,而無法放入記憶體中的數據會儲存在磁碟上。 因此,記憶體內部數據行存放區結構中的數據量可能會超過可用的記憶體數量。
數據行存放區索引的數據大小和記憶體
數據行存放區索引不需要放入記憶體中。 因此,索引大小的唯一上限是整體資料庫大小上限,記載於 以 DTU 為基礎的購買模型 和 以虛擬核心為基礎的購買模型 文章中。
當您使用叢集數據行存放區索引時,會針對基表記憶體使用單欄式壓縮。 此壓縮可大幅減少用戶數據的記憶體使用量,這表示您可以在資料庫中容納更多數據。 使用單欄封存壓縮可以進一步增加 壓縮。 您可以達成的壓縮量取決於數據的本質,但壓縮的10倍並不罕見。
例如,如果您的資料庫大小上限為 1 TB(TB),而且使用資料行存放區索引達到壓縮的 10 倍,則資料庫中總共可以容納 10 TB 的用戶數據。
當您使用非叢集數據行存放區索引時,基表仍會以傳統的數據列存放區格式儲存。 因此,儲存空間節省不如叢集數據行存放區索引那麼重要。 不過,如果您要以單一資料行存放區索引取代許多傳統非叢集索引,您仍然可以在數據表的記憶體使用量中看到整體節省。
變更包含數據行存放區索引的資料庫服務層級
如果您的目標層低於 S3,則可能無法將單一資料庫降級為基本或標準 。 數據行存放區索引僅支援 業務關鍵/進階版 定價層和標準層、S3 和更新版本,而不是基本層。 當您將資料庫降級至不支援的階層或層級時,數據行存放區索引會變成無法使用。 系統會維護數據行存放區索引,但永遠不會使用索引。 如果您稍後升級回支援的階層或層級,則數據行存放區索引會立即準備好再次使用。
如果您有 叢集數據 行存放區索引,整個數據表會在降級之後變成無法使用。 將資料庫降級至不支援的階層或層級之前,請先卸除所有 叢集數據 行存放區索引(並以數據列存放區叢集索引取代 )。
相關內容
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應