數據同步機制自適應優化的HTAP 數據庫原型系統

俞 融, 楊攀飛, 王清帥, 張 蓉

（1. 華東師范大學 數據科學與工程學院, 上海 200062;2. 工業和信息化部電子第五研究所, 廣州 511300）

0 引 言

近年來, 隨著數據量的快速增長和實際數據應用對實時處理需求的增加, 學術界和工業界對兼具高效事務處理和實時分析處理數據庫系統產品的期望越來越迫切. HTAP (hybrid transactional and analytical processing)數據庫系統是指在同一個系統中同時執行事務處理和分析處理的數據庫系統[1-2], 由于處理的高效性、數據遷移的低代價與運維管理的低成本使其獲得了廣泛關注. 在HTAP 數據庫系統中, 事務處理負載OLTP (online transaction processing, 簡寫為TP)具有短時延、高并發、小規模的特點, 分析處理負載OLAP (online analytical processing, 簡寫為AP)具有長時延、操作復雜、大規模的特點, 它們在數據訪問上的交疊使得資源使用產生競爭, 用戶期望兩類負載間的干擾盡可能少, 從而最大化各自的性能. 因此, 為了最大限度發揮HTAP 數據庫系統的能力和數據處理的實時性優勢, 關鍵的難點在于如何處理數據共享和資源隔離, 從而在實現負載相互干擾最小化的同時,讓AP 讀取的數據版本與TP 生成的大量數據版本保持一致(即高新鮮度), 以完成實時分析決策.

資源隔離與HTAP 數據庫系統架構密切相關: 資源隔離程度越高, TP 和AP 之間數據共享的難度就越大[2]. 不同的數據庫廠商提供了不同的解決方案[3-10], 大致可分為一體式架構的邏輯隔離、分離式架構的緩存隔離和存儲隔離三大類[2,11-12], 通過在存儲層、緩存層、事務層等不同層次的資源隔離,緩解資源競爭, 提升系統性能. 這3 種架構的數據庫隔離處理方案, 雖然能夠減少TP 和AP 之間的性能干擾, 但是影響了TP 向AP 同步數據、共享數據的方式. TP 和AP 之間存在的數據版本差距, 從本質上看, 是由于它們選擇了不同一致性數據共享模型. 在HTAP 數據庫系統中, 根據AP 讀版本與TP 寫版本差異可以分為3 種一致性同步模型. 線性一致性是TP 有更新就發送, AP 客戶端在同一時刻所讀取到的數據都是最新一致的; 順序一致性是TP 更新按批發送, 各 AP 節點在同一時刻讀到的數據一致, 但不保證最新; 會話一致性是不同 AP 端在同一時刻所讀取到的數據既非最新, 也非完全一致, 但會話內的新查詢確保能訪問當前寫入更新版本的數據[2-3]. 因此, 一致性模型的選擇決定了HTAP 數據庫讀寫版本的差距, 較強的一致性往往以犧牲整體性能的下降來換取數據同步對資源利用的提升, 從而提供給AP 任務更新鮮的數據版本.

現有的HTAP 數據庫對于整體架構和一致性模型的選擇往往采用固定模式, 即為了節約成本, 只選擇一種一致性模型進行應用. 然而, 在實際場景中, 用戶的不同應用可能有不同的一致性需求[13]. 例如在旅游應用軟件的購票場景中, 用戶下單購買火車票時需要實時確認最新的余票數量以避免出現超賣, 此時需要TP 與AP 之間保持線性一致性; 對于后臺工作人員分析一小時或是一天購票量的統計, 則僅需要按批同步TP 修改更新, 適合使用順序一致性同步模型; 對于用戶行程、差旅酒店推薦等則只需要符合當前用戶的會話邏輯, 使用會話一致性同步模型即可. 故而用戶多樣的一致性需求與架構采用固定一致性模型的矛盾, 使得數據庫架構人員只能向上兼容, 為負載選擇滿足其最高新鮮度需求的同步模型.

通常情況下, 架構師會選擇保守策略, 使用線性一致性來防止出現用戶需求不滿足的情況, 但是數據版本新鮮的高一致性模型通常以性能為代價換取, 使得HTAP 數據庫系統的整體性能無法實現最大化. 因此, 為了提升HTAP 數據庫系統的性價比, 根據應用自適應選擇一致性同步模型是有必要的. 也就是說, 為了權衡性能與新鮮度, 可以通過調整系統一致性強度, 按需保證數據的同步機制, 提升整體性能.

本文期望實現一個能夠根據負載動態自適應調整一致性級別的HTAP 數據庫原型系統, 由于會話一致性利用緩存提升資源的利用率, 在系統中只能作為提升線性一致性和順序一致性系統性能的輔助, 因此首先需要進行兩種一致性同步方式的實現, 以線性一致性為基礎, 向系統輸入用戶指定的負載一致性類型 (新鮮度需求) , 在達到統計指標閾值后向順序一致性切換, 從而提升系統吞吐. 在實現過程中存在以下兩個難點:

(1)切換過程中如何保證數據正確、在高效訪問的同時實現同步粒度的動態調整問題, 將涉及對中間狀態、信息收集維護代價的權衡;

(2)如何根據負載一致性分布構建切換決策代價模型, 實現同步模式的有效切換, 涉及負載一致性要求分布與切換頻率之間的權衡.

本文主要有以下貢獻:

(1)基于數據分片進行了分片順序一致性同步和線性一致性同步自適應切換的設計;

(2)基于用戶指定的查詢一致性需求, 提出了一致性切換算法, 并提供切換前后同步數據的處理策略;

(3)實驗驗證了滿足新鮮度要求的情況下, 采用一致性模型切換的方法能有效提升系統整體性能.

1 相關工作

關于一致性及其切換的研究已經有許多相關工作, 但大多集中在對分布式數據庫復制服務和云服務的探索上, 如表1 所示. 分布式數據庫中的一致性模型要求各物理(或多數)副本內容相同[14], 不關心讀寫版本的差異[2], 大多通過中間件來實現兩種一致性之間連續變化的一致性要求. Lu 等[15]和Yu 等[16]提出了一種在分布式系統的復制服務中能夠根據交互自適應地調整不同對象一致性級別的中間件, 以讀寫操作為粒度發現不一致并進行解決. 對于云服務而言, 數據的一致性是指可伸縮機器之間數據的一致. Gao 等[17]提出了適當放松系統一致性, 改變不同類型對象在服務器之間的復制同步策略換取性能的提升. Kraska 等[13]探索了如何在云存儲上獲得高可伸縮和低成本解決方案, 提出了根據云上應用對一致性需求的強弱分類調整各個節點數據的一致性, 能夠有效實現系統整體吞吐的提升, 并提出根據沖突出現的可能性、系統運行時間長短、數據項的絕對值大小和更新頻率等統計信息決定是否進行系統整體一致性的切換. 而HTAP 數據庫系統中的一致是TP 和AP 數據版本間的一致, 當TP 寫版本和AP 讀版本出現差距時, 需進行有方向的數據同步.

表1 一致性控制的實現對比Tab. 1 Comparison of related work implementation to consistency control

部分現有的開源HTAP 數據庫系統也支持多種一致性. OceanBase[18]在全局線性一致性的同時提供對弱一致性讀的支持, 也支持在提供全局使用最終一致性的基礎上, 給予AP 查詢路由到TP 上進行更新數據讀取的可能, 但不建議使用查詢請求路由到主副本執行的方案, 而是建議在備副本上重試多次失敗后回滾, 避免寫流量高峰和讀流量高峰同時被引流到主節點上, 造成更大的問題. TiDB[19]根據查詢指定到不同的副本上進行讀操作, PolarDB[20]利用其自身物理復制速度快的優點, 將查詢發給已經更新了數據的只讀節點, 減少達成全局最終一致性的長時間等待. 雖然現有的數據庫能夠部分支持根據AP 端不同版本差進行一致性級別的調整, 但還未實現根據動態負載的自適應調整.

2 系統設計

2.1 整體架構

在滿足用戶新鮮度需求的情況下, 控制數據分片對時間戳的控制粒度, 改變底層存儲分片中事務日志的同步方式, 從而改善全系統同時僅支持使用一種一致性帶來的性能局限. 由此, 本文設計了一個能夠自適應調節分片同步方式的HTAP 數據庫原型系統.

2.1.1 系統架構介紹

系統整體架構如圖1 所示, 數據在HTAP 數據庫系統中由TP 端事務并發執行產生, 相關日志由分片對應的日志應用控制器獲取并在AP 端進行回放, 用戶將指定一致性(新鮮度)要求的查詢負載,在對應分片上完成執行. 自適應一致性通過數據分片標簽表存儲并標記數據分片的同步方式. 然后,由事務日志發送控制器、分片同步方式監控器、分片同步方式自適應決策器以及分片查詢執行監控器四大組件協同完成一致性的自適應轉換.

圖1 系統整體架構Fig. 1 System operation process architecture diagram

事務日志發送控制器: 該組件控制事務日志向AP 端同步的頻率, 控制器向分片標簽表發起詢問,查看所在分片的數據同步模型, 若是按照線性一致性的方式, 則每隔最小的時間間隔發送日志到對應AP 副本的緩沖區后, 再繼續進行下一個單位的同步; 若是以順序一致性的方式, 則同一時間間隔內的日志以批為單位進行同步和應用.

分片同步方式監控器: 該組件監控數據分片同步標簽表內容是否發生變化, 在同一分片標簽頻繁發生變化時, 及時獲知并進行示警.

自適應決策器: 該組件完成代價評估與決策判定, 通過綜合判斷各個分片上查詢的一致性壓力與分片本身同步壓力的情況, 決策出各個分片是否需要進行TP 端數據同步方式的修改, 若需要變動,則由該組件對分片標簽表對應內容進行修改, 支持分片同步方式的自適應調整.

分片查詢執行監控器: 在AP 端, 用戶查詢以帶有新鮮度要求的一致性標簽方式, 將查詢分發到其對應的分片上, 該組件的功能是對各分片上不同一致性需求查詢執行的監控和統計.

2.1.2 分片設計

為了更好地應對大規模數據和高并發負載, 避免集中式架構可能面臨的性能瓶頸和可擴展性限制, HTAP 數據庫系統多采用分布式架構, 將數據分布式地存儲到不同的節點, 使得不同類型的負載請求能夠互不干擾地進行并行處理. 現有HTAP 數據庫系統同步模式的管理是以日志或數據為單位進行的, 對整個數據庫實行全局統一管理. 數據的分片存儲和管理能夠使得系統在同步時, 提升同步的效率. 本文基于采用分片策略的HTAP 數據庫系統, 設計一致性同步和變換.

如圖2 所示, 情況1 表示當大量順序一致性需求的查詢執行在基于線性一致性同步的分片上時,為了降低同步代價和提升響應速度, 將該分片的同步模式從線性同步轉變為順序同步模式; 情況2 表示當負載需要滿足線性一致性需求同時訪問分片B 和C 的數據時, 分片C 根據同步代價做出是否進行同步模式切換的決策.

圖2 基于數據分片的一致性切換示意Fig. 2 Synchronization switching on data sharding

2.1.3 查詢格式

輸入的查詢需要確定其與用戶需求新鮮度之間的關聯關系, 用戶對負載的一致性需求決定了查詢返回的數據新鮮度, 即查詢讀取版本和事務最新寫版本之間的差距. 本文通過設定特定結構體實現對輸入查詢的一致性需求進行指定, 圖3 展示了查詢請求格式樣例. 在實現中, 通過使用向量的方式完成對輸入查詢一致性的指定, 同時, 由于使用分片的方式管理數據, 每個機器上可能保存部分數據和備份. 給定一個分片, 查詢以哪種一致性協議進行分片訪問體現在向量的取值中. 假設qi表示第i個查詢的執行向量, 數據庫系統具有k個分片(即向量維度), 其中每個維度的取值ci ∈{-1,0,1}, 其中, –1 表示查詢需要線性一致性, 1 表示查詢需要順序一致性, 0 表示查詢不掃描該分片的數據.

圖3 查詢請求格式Fig. 3 Query request format

qi的執行向量:

負載集W的執行向量可以表示為

當用戶對查詢的一致性需求發生變化時, 負載向量的取值可能會變化, 權衡切換分片帶來的數據同步壓力與系統整體性能的提升情況最終產生執行向量.

2.2 切換策略

在HTAP 數據庫系統中, 實現對分片數據同步方式的自適應切換, 關鍵在于尋找系統中性能和一致性模型切換代價的權衡點, 并做出合適的決策判斷, 即根據模型切換代價的估算, 確定數據分片的同步方式. 通過對切換后分片上查詢負載性能提升量和分片進行轉換時查詢等待時間的估計, 根據所獲得的正向收益數值大小決定是否進行分片同步方式的轉變.

2.2.1 代價建模

在HTAP 數據庫系統運行過程中, 同一分片上可能運行著多個不同一致性需求(新鮮度)的查詢,分片同步方式的切換會引起分片上不同類型查詢在新鮮度和查詢響應代價上的變化.

HTAP 數據庫系統中TP 端事務的寫入較快, 版本號通常快于AP 端. 在線性一致的同步方式中,AP 選擇全局最大的時間戳號進行讀取, 需要保持最強的一致性和最高的新鮮度, 因此在AP 端, 查詢會等待應讀版本前發生的所有TP 寫日志同步到AP 端并完成回放之后才開始執行, 這部分的同步時間開銷對查詢的響應時間產生了較大的影響, 但保證了查詢的一致性(新鮮度)需求. 在順序一致的同步方式中, TP 端的更新按批實現同步, AP 端的查詢選擇AP 當前可讀且最小(已完整同步)的epoch 號版本進行讀取, 因此AP 端查詢無需進行數據版本同步的延遲等待, 雖然讀取的數據版本與當時TP 端的寫入版本相比有一定的落后, 但是查詢響應時間較快.

因此, HTAP 數據庫系統需要根據代價情況進行建模, 并制定合理的分片切換策略, 從而實現新鮮度與性能之間的權衡. 查詢響應代價是指從查詢發起到查詢結果返回所耗費的時間, 新鮮度代價是指查詢真實執行版本與查詢發起時TP 端最新寫版本之間的版本差距. 為了使得新鮮度和查詢響應在同一維度具有可比較性, 需要將它們統一成可比較的時間延遲或者版本差距. 在AP 端保持恒定日志應用速度的前提下, 新鮮度的版本差距使用版本同步所耗費的等待時間來表征.

由于查詢負載是用戶指定的, 每個查詢的一致性(新鮮度)要求以及執行查詢的分片是由負載指定的, 很容易出現分片同步方式和分片查詢一致性需求不一致的情況, 數據庫存儲通過感知負載的一致性自適應調整同步方式, 分片的同步方式是否轉換由兩部分代價之間的大小關系決定, 即性能或新鮮度的延遲提升量和分片切換等待時間. 分片的同步方式決定了分片上查詢執行的讀寫版本差距, 順序一致同步下的查詢返回給AP 端當前已完整的最小可讀版本, 線性一致同步下的查詢則是等待最大應讀版本同步完成后返回給AP 端, 它們和查詢本身的一致性要求是存在差異的, 只需在用戶可容忍的新鮮度閾值范圍內則是可接受的. 因此, 在保證新鮮度滿足閾值的情況下, 可以通過代價模型判定是否切換分片的同步方式, 即是否在可行范圍內降低某些查詢的新鮮度換取分片上所有查詢響應時間的縮短, 圖4 展示了查詢延遲與分片一致性切換等待權衡示意圖.

圖4 查詢延遲與分片一致性切換等待權衡示意Fig. 4 Query latency changing vs. slice consistency switching latency

以單個分片為例, 查詢的一致性需求與分片同步方式不一致的情況共有兩種. 一種是存在部分順序一致性需求的查詢在線性同步分片上執行, 它們執行在線性一致新鮮度的數據版本上, 高于順序一致性的需求, 存在新鮮度過剩的現象, 而且由于這種同步方式需要等待分片完成所需版本的同步之后才能繼續讀取, 延長了順序查詢的響應時間. 因此, 若分片同步方式從線性轉變成順序, 那么在滿足一定新鮮度犧牲范圍內, 順序一致性要求的查詢響應延遲將顯著降低, 當分片切換對齊等待的代價小于查詢響應時長提升的收益時, 推薦進行分片同步方式的切換. 另一種是部分線性查詢在順序同步分片上執行時, 它們的執行返回版本是順序一致批同步已完成的最小版本, 雖然查詢響應的時間非常短,但是降低了線性查詢的一部分新鮮度. 若分片同步方式從順序變成線性, 那么線性查詢執行的版本新鮮程度將顯著提高, 少量順序一致性需求的查詢在線性同步分片的執行延遲會有一定上升, 當分片切換等待所付出的延遲代價小于分片上所有查詢引起的延遲提升收益時, 推薦切換.

由于分片同步方式切換引起分片上所有查詢整體時延的變化, 定義查詢時延變化量=新鮮度變化量 + 同步等待延遲變化量, 查詢一致性轉變性能提升代價與當前分片的同步類型以及分片上不同類型查詢的數量有關; 分片同步模型切換時面臨時間戳號 (或epoch 號) 對齊的問題, 由此產生了分片切換等待代價.

當AP 負載中查詢的一致性需求發生變化或是分片上存在部分查詢與存儲分片同步方式不一致時, 需要判定分片的同步方式是否需要發生變化, 而判定的關鍵在于估計分片上查詢在底層同步方式變化后可以獲得的查詢整體時延提升量.Qi表示查詢i從線性同步切換成順序同步時的讀版本的等待時間,Q′i表示查詢i從順序同步切換成線性同步時的查詢等待時間, 因此, 式(1)和式(2)分別表示22 個查詢線性同步和順序同步切換的向量.

由于每個查詢在不同分片上并行執行, 負載集執行向量W的每一項ci,k決定了查詢i是否在第k個分片上執行, m ax{Qi×ci,k}表示查詢i在k個分片中最長的同步切換耗時, 從線性到順序切換時該值為正, 而從順序到線性切換時該值為負,?表示向量運算, 可得到各個查詢的同步耗時結果C.

由于在線性向順序切換的過程中, 線性一致性需求的查詢以滿足新鮮度為前提, 其新鮮度變化量不計入, 查詢延遲變化量以同步等待延遲為主; 而順序向線性切換的過程中, 順序一致性需求的查詢同步等待代價與新鮮度提升量相比, 數量級很小, 可忽略不計. 因此, 分片上所有查詢整體延遲變化量Tlatency為式(3)向量C中各維不為零的同步延遲量之和.

分片切換等待的時間Twait與本地時間戳完成對齊所需的等待時間有關, 即等待遞增的本地時間戳計數器Elocal按照原方式(線性間隔或順序epoch 間隔)增加至Eseq(或Elinear)的整數倍,E′表示對齊完成的時間戳計數器.

式中:t(E′-Elocal) 表示一個t() 函數.

2.2.2 跨分片讀

當某類一致性需求的查詢涉及多個不同同步類型分片時, 同步策略需要進行基于查詢負載的協商, 如圖5 所示, 上下兩張圖分別表示順序一致性查詢和線性一致性查詢運行在不同同步方式分片時可能的兩種協商方式, 具體需要根據2.2.1 節中提及的代價模型計算分片上查詢的切換前后獲得的正負收益情況后得出.

圖5 跨分片查詢協商示意Fig. 5 Cross-shard query negotiation diagram

2.2.3 切換等待對齊策略

在底層存儲分片的同步方式發生轉變時, 由于線性一致同步的時間戳粒度遠小于順序一致同步的時間戳粒度, 因此, 在切換時, 需要進行時間戳號的對齊, 算法示意圖見圖6, 具體細節見算法1.

圖6 切換等待對齊算法示意Fig. 6 Schematic diagram of switching wait alignment algorithm

epoch 通常是指時間戳粒度, TP 端以epoch 大小的時間間隔發送日志給AP 端. 算法1, 首先獲取開始時間(行1), 對分片同步方式監聽的程序持續運行(行2), 算法根據分片標簽值確定不同分片采用多大的時間戳間隔進行信號的發送, 由于每到達一次同步時間間隔, 程序將僅為指定一致性同步方式的序號增加一次計數 (線性一致性同步版本由線性同步時間戳計數器E0指示, 線性同步間隔為Ilinear,順序一致性同步版本由順序同步時間戳計數器E1指示, 順序同步間隔為Iseq) . 如果當前分片為順序一致性同步方式(行3), 首先需要判定本地Elocal號與順序同步E1號是否一致(行4), 若一致, 則以順序一致的時間間隔向對應AP 副本所在機器發送日志(行16—21); 若不一致, 說明當前分片上一次epoch 號的發送是通過線性一致性同步發送的, 需要以線性一致性的間隔完成未到達下一個順序epoch 號的剩余線性一致時間戳日志的發送來實現對齊, 直到本地時間戳計數器Elocal到達順序一致性的間隔號整數倍位置(行12), 避免出現正確性問題(行6—11).

反之, 當前分片則是以線性一致性同步的方式進行時(行22), 同理首先需要判定本地Elocal號與線性同步E0號是否一致(行23), 若一致, 則以線性一致性的時間間隔向AP 副本所在機器發送日志(行27—32); 若不一致, 則說明分片同步方式剛從順序一致同步方式中切換過來. 在這種方式下, 由于線性一致時間戳的粒度為1, 僅需使本地時間戳計數增加一次計數即可實現對齊(行23—26).

算法1 分片切換后時間戳連續性保證的一致性間隔對齊算法輸入: 線性同步時間間隔Ilinear順序同步時間間隔Iseq分片本地epoch 號計數器Elocal線性同步時間戳計數器E0

3 實 驗

3.1 實驗設置

實驗基于Vegito[21]代碼進行擴展和改造, 在3 臺96 核雙路Intel Xeon 處理器, 374 GB 內存、x86_64 架構的計算機上進行, 每臺計算機配置有MLNX_OFED_LINUX-5.8-1.0.1.1 版本驅動的ConnectX722 10GbE 的IB 網卡, 操作系統為CentOS 7.9, 每組實驗使用8 個TP 線程和6 個AP 線程運行60 s 得到, 所使用的HTAP 負載由5 個TPC-C 事務和22 個改裝的TPC-H 負載組成.

3.2 實驗結果及分析

3.2.1 不同一致性同步的差異對比

實驗部分, 首先驗證了適配TPC-C 表模式后的22 個查詢在不同同步模式下的計算和同步的時間, 如圖7 所示, 堆疊圖中黃色柱狀部分表示查詢的計算時間, 藍色部分表示該查詢經歷的同步時間,全柱高表示查詢的響應時間. 從圖7 中, 可以發現線性一致的同步延遲明顯高于順序一致的同步延遲,順序一致同步時長的數量級為10–3, 幾乎可忽略不計.

圖7 分片使用不同一致性同步時查詢的計算延遲與同步延遲對比Fig. 7 Computational latency versus synchronization latency of queries when sharding uses different consistency synchronization

通過對各查詢的多次運行, 統計發現不論使用何種同步模式, 查詢的計算執行延遲數值均相近.同時結合圖7 分析, 在AP 負載運行20 s 后進行分片同步模式從線性到順序的切換, 并統計了平均值的統計, 結果如表2 所示, 將該表的值作為每個查詢預估的同步模式轉變的性能提升值, 同理, 分片同步模式從順序到線性切換的平均延遲結果如表3 所示.

表2 查詢負載一致性需求從線性到順序切換的平均代價表Tab. 2 Average cost table for query load consistency demand switching from linear to sequential

表3 查詢負載一致性需求從順序到線性切換的平均代價表Tab. 3 Average cost table for query load consistency demand switching from sequential to linear

3.2.2 自適應策略的有效性

對于分片同步方式從線性到順序自適應策略的有效性, 設計了表4 所示3 組變化的負載進行驗證, 實驗得到的查詢延遲結果和同步時間情況對比如圖8 所示.

圖8 分片同步方式從線性到順序自適應的3 個實驗結果Fig. 8 Three experimental results of adaptive shard synchronization from linear to sequential

表4 查詢負載從線性到順序自適應切換的結果Tab. 4 Results of query workload consistency adaptive switching from linear to sequential

根據負載設計, 僅第3 組實驗的負載不會引起分片同步模式的改變, 從圖8(a)的結果中發現該組查詢的響應時間均比前兩組長, 但確實是其對性能和一致性進行權衡后的選擇. 在對其同步延遲更細致的分析中, 實驗組3 延用線性一致的同步方式, 相對前兩組實驗的同步延遲略高, 符合預期. 更進一步, 從圖8(b)中可見, 實驗組3 由于未進行分片同步方式的切換, 有著比其他兩組明顯更高的同步延遲.

同理, 通過對分片同步方式從順序到線性的自適應策略有效性設計了表5 所示的負載進行驗證,第一組為不開啟自適應策略的對照組, 實驗結果如圖9 所示.

圖9 分片同步方式從順序到線性自適應的4 個實驗結果Fig. 9 Four experimental results of adaptive shard synchronization from sequential to linear

表5 查詢負載從順序到線性自適應切換的結果Tab. 5 Results of query workload consistency adaptive switching from sequential to linear

根據表5 中第2、3、4 組切換的預期結果與實際結果可知, 系統的自適應策略是正確且符合預期的, 從圖9(a)的結果中可見, 與對照組相比, 大部分查詢實現查詢延遲比不使用自適應策略小或者絕對數值變化小, Q16 查詢延遲的提升相對較為明顯, 圖9(b)中每個查詢均有4 個圖柱, 其中實驗組1 和實驗組4 的同步實驗數值很小, 而在同步延遲結果對比中可見, 同步方式從順序向線性切換時的對齊代價明顯小于從線性向順序切換, 但與不切換相比, 分片切換等待的延遲是不可小視的.

4 結束語

本文通過構建權衡性能與新鮮度的代價模型, 實現了在順序一致性同步與線性一致性同步上, 自適應調整數據分片的一致性同步方式, 提升了整體性能, 實現自適應調整一致性級別的HTAP 原型系統, 提出了一致性切換算法和切換前后同步數據的處理策略, 最后通過實驗進行了自適應切換的有效性驗證.