一種實時數據庫的分布式存儲方法①

周 淳,李賢慧

(南瑞集團有限公司(國網電力科學研究院有限公司),江蘇瑞中數據股份有限公司,南京 211106)

數據庫技術產生于20 世紀年代后期,其理論與技術發展極為迅速,應用也日益廣泛,數據庫技術的一個重要分支：實時數據庫是采用實時數據模型建立起來的數據庫,實時數據庫技術是實時系統和數據庫技術相結合的產物[1],作為解決關系型數據庫實時處理能力等問題而產生的一種數據庫技術,實時、高效、穩定是實時數據庫最關鍵的指標.

實時數據庫在數據通信、數據存儲、數據檢索、數據訪問、數據處理、數據展現等方面的專業化及產品化,為構建基于大容量實時歷史數據之上的分析應用提供了便捷穩定的數據支撐,使應用系統可以從更高更深層次充分利用寶貴的生產實時歷史數據.而隨著網絡技術迅速發展,實時系統產生的數據量呈指數級增長,且各業務應用對海量數據的管理和應用的實時性提出了越來越高的要求,現有的單機實時數據庫技術不論在理論還是實際應用中都存在很大的局限性,已不能完全適應當前需求.

目前業界使用實時數據庫基本仍使用單核心集中部署[2,3],分布式計算和存儲技術思想的引入則可以很好的解決單機實時數據庫遇到的這些瓶頸,但如何設計一個滿足事務應用處理時效性以及事務吞吐率的需求的分布式實時數據庫是一個難點,本文通過對分布式實時數據庫部分關鍵技術(數據分布、數據一致性、數據重分布)的研究,設計了一種分布式實時數據庫管理系統,可以為實時數據庫應用發展提供技術支撐.

1 概述

1.1 總體架構設計

分布式實時數據庫部署架構如圖1所示.

圖1 分布式實時數據庫系統部署架構

在部署架構中,管理節點是整個分布式實時數據庫的管理者,主要存儲系統元數據信息,包括數據分布方式、各節點狀態、主備節點一致性狀態等關鍵信息.

調度節點屬于分布式訪問層,統一的訪問接口使得應用能夠將分布式的實時數據庫視為一個完整的邏輯整體進行訪問；同時調度節點也屬于分布式定位層,是數據的分布和收集者,主要負責數據的分發,查詢結果的收集匯總以及任務調度.在分布式查詢訪問多個節點上的數據時,并發式的訪問處理能夠實現多路數據請求在多個存儲節點上的并行處理,從而實現了高效的分布式數據訪問.

數據節點屬于分布式存儲層.每一個數據節點運行和管理一個數據庫實例.數據節點負責整個數據庫系統數據的實際存儲,接收來自調度節點的數據,執行經分解的查詢任務,執行結果通過調度節點返回給應用程序.數據節點的數量僅受限于以太網帶寬、機房物理條件等硬性條件.各數據節點只存儲屬于相應分區的數據,邏輯上是對等的.主備數據節點實現數據在節點間的冗余互備.

1.2 元數據表

實時數據庫可以簡單地理解為由標簽點信息庫、值數據庫兩個部分組成[4].如圖2所示.

標簽點信息庫含有測點基本信息的一張表,以標簽點標簽(point_name)作為關鍵字,一條記錄包含一個標簽點的基本配置信息,如標簽點描述、壓縮算法等.用戶可從此標簽點信息庫中查詢標簽點的基本信息.值數據庫包含了實時值緩存和歷史數據存儲,每條記錄反映了某標簽點產生的實時數據的時間戳、數值、質量等信息.用戶可從值數據庫中查詢實時數據值.因此實時數據庫最主要的兩個維度即標簽點和數據時間.若需要將實時數據庫所有數據分布到多個節點中,則應該從這兩個維度入手.

圖2 標簽點表和數據值表

元數據存儲：標簽點表作為元數據表,存儲在調度節點,每個調度節點擁有一份完整的標簽點信息,多個調度節點互為備份,通過管理節點控制調度節點狀態,使用同步線程做異常恢復.

1.3 數據流

數據接入數據流如圖3,數據由應用服務器或客戶端發往調度節點,由調度節點根據分布規則,將數據發送到不同數據主節點,數據主節點在存儲過程中會將數據轉發給對應備份節點.

數據查詢數據流如圖4,查詢請求和查詢條件由應用服務器或客戶端發往調度節點,由調度節點根據查詢條件中涉及到的標簽點和時間范圍,通過分布規則,篩選相關的數據節點,拆分并重新組織多個子查詢請求分配到多個數據節點,多個數據節點并行處理查詢,完成后將結果返回調度節點,調度節點待所有已分配的子查詢返回結果后做聚集處理.將結果反饋到應用服務器或客戶端.

這里涉及到分配主備節點的問題,每一個子查詢只可能被發送到某一個數據主節點或者備份節點,除非查詢異常才會繼續由調度節點發往另一個節點做查詢(同時需要向管理節點匯報節點狀態),調度節點可以通過判斷主備節點的繁忙程度來選擇分配節點,數據節點定時向管理節點匯報當前活動狀態以及繁忙程度,調度節點也會定時從管理節點同步所有數據節點狀態,繁忙程度的度量[5]可以從CPU 平均使用率、平均網絡使用率、當前磁盤使用率、當前內存占用率等方便綜合測算.

圖3 數據接入的數據流

圖4 數據查詢的數據流

2 數據分布設計

2.1 分布規則

設計分布規則時,既要考慮到標簽點數據的關聯性(如果能夠將部分查詢運算放在數據節點內部直接處理,顯然要比將數據傳輸到調度節點后再集中做運算性能要高的多),又要考慮分布式架構并行處理帶來的效率提升.

可以考慮將連續的一批標簽點,一個時間段的數據分布在同一個數據節點中,可以考慮通過自定義的Hash 函數實現,Hash 函數類似如下格式：其中slice_id為最后函數確定分配的分片號,通過函數前部計算結果對一個設定的Hash_Bucket取模獲得,hash_str(point_name)和day_time(time)分別是對標簽點名和時間段的一個量化函數,考慮到標簽點或時間區域內數據的關聯性,設計b1 和b2 控制標簽點或某相鄰時間段內的數據分散程度.w1 和w2 為系數,或者稱之為未標準化權重,例如極端情況下設置w2 為0,則表示完全按照標簽點來分布數據,每個標簽點的所有時間的數據都存放在同一個數據分片或其備份分片上；同樣的,若設置w1 為0,則表示完全按照時間段來分布數據,每個時間段的所有標簽點的數據都存放在同一個數據分片或其備份分片上.

可以看到,該等式是以point_name和time為自變量,slice_id為因變量的函數,根據函數定義,說明任意一組已知的point_name和time,可以唯一確定一個slice_id,也就是說根據接入的數據中的標簽點名和數據時間戳,我們可以分布到一個確定的數據分片.

考慮到系統實際運行中,節點可能會有調整變動,若Hash_Bucket設為初始節點數,且每個slice_id對應一個節點,則節點變動會導致Hash_Bucket變動,繼而會使得整個數據重分布涉及到系統所有數據文件,因為需要對每條數據值使用新Hash 函數計算對應數據節點,這種方式只能通過提高Hash 運算以及數據傳輸的并行度來提高重分布效率.

借鑒一致性Hash 算法[6]可以有效解決該問題,管理節點存儲一個大小為Hash_Bucket的數組(分片映射表),每個元素存儲該元素下標對應數據分片所在的數據節點,該映射關系可以通過人工設定或者按node_num(數據節點數)取模的方式自動分配.

圖5顯示了數據是如何根據分布規則分布到不同節點上的,分布規則包含自定義的Hash 函數和分片映射表,通過自定義的Hash 函數和分片映射表可以將標簽點以及數據分布到不同數據節點,分布規則需要在標簽點寫入之前確定,且分布規則一旦確定后,直到數據節點變動需要重分布才會改變,且只能改變分片映射表.

若整個分布式實時庫系統啟動前沒有預先設置分布規則,則啟動后分片映射表根據數據節點數自動生成,接入標簽點和數據前,仍需要通過管理客戶端設置Hash 函數相關參數,該分布規則直接交由管理節點保存,調度節點在分配標簽點和數據前需要從管理節點預先獲取分布規則.調度節點首次獲取到分布規則后會存儲到內存中,無需在每次分配數據時重新獲取分配規則,若系統擴容或縮容等有數據節點的變動,需要修改分布規則時,則需要調度節點重新初始化并獲取分布規則.

圖5 數據分布規則

2.2 數據重分布設計

隨著數據庫內數據總量的變動,可能需要考慮數據節點的擴容或縮容.數據節點的變動必然需要考慮數據均衡和數據重分布.

前文設計的實時庫系統,采用的分片映射表和Hash 分布2 層分布的方式,重分布策略可以設計為Hash 函數不做改變,而只改變分片映射表,例如重新按照新的節點數自動取模生成新的映射表,調度節點通過對比新舊分片映射表的差異,設置每個數據節點相應的分片移動路徑并分配到各個數據節點,數據節點按完整分片目錄做數據遷移.這樣以分片為最小移動單位,無需做數據解壓和Hash 運算,極大減少CPU 運算和磁盤IO 以及網絡IO 的開銷.

一個更高效的做法即根據整個數據庫系統中數據總量做均分,圖6是一個擴容過程,將數據總量大于平均數據量的數據節點中的部分分片向少于平均數據量的數據節點移動,這樣可以使得數據重分布需要移動的總吞吐量達到最小.

3 單機實時數據庫存儲設計

實時數據庫存儲設計盡可能沿用已有的單機實時庫設計,即設計滿足單個數據庫實例既可以作為獨立個體運行,也可以作為分布式架構中一個數據節點運行,也就是說單個數據節點需要包含實時庫所有模塊：網絡收發模塊、數據緩存模塊、數據處理模塊、數據存儲模塊(包含索引).

圖6 數據節點擴容時數據分片的移動

這里主要考慮數據存儲模塊,數據緩存模塊、數據處理模塊都是建立在該模塊之上,而網絡收發模塊只和設計的通信協議有關,和數據邏輯相對獨立.

數據存儲按照分片管理,如圖7所示,每個分片號(slice_id)對應一個文件目錄,若作為單獨數據庫實例運行,該實例包含所有分片號,若作為分布式架構中一個節點,該實例包含分片映射表中部分分片,每個分片文件目錄下按時間段區分數據文件組存儲數據塊,文件組和時間段一一對應,每個文件組和分片目錄各自存儲一個版本號(version),每次寫和修改更新版本號,查詢不做版本號更新[7].

圖7 單數據節點基本存儲結構

從整個個分布式系統角度看,數據節點是系統中最基本的存儲和計算單元,從數據完整性角度來看,數據節點內部數據文件組是最小粒度的具有自描述性的存儲單元,也是最基本的自恢復和同步單元.

4 數據冗余備份和一致性處理

分布式數據庫的一個難點就是如何處理存儲數據的一致性,包括元數據和數據的同步以及異常處理.

4.1 管理節點數據一致性

管理節點一般需要配置多個節點來保障高可用性,主要存儲的是分布規則等關鍵配置,以及各主備節點狀態等小顆粒信息,適合基于corosync 或zookeeper 類似架構實現,保證信息同步有序一致,對于這一類場景目前已經有廣泛的應用實踐,例如文獻[8].

4.2 調度節點元數據一致性

調度節點除了定時從管理節點同步各節點狀態到內存外,主要存儲標簽點元數據信息,對標簽點的增刪改查以事務方式執行,需要保證單次操作的原子性和強一致性,即每次在某一調度節點的操作,需要保證成功同步到其他所有正常調度節點,若低于1/2 的調度節點同步失敗,管理節點將失敗的節點做異常標記,等待后續同步恢復；若超過1/2 的節點同步失敗,則在已執行成功節點上執行撤銷操作,若撤銷失敗,同樣做異常標記,等待后續同步恢復.

調度節點元數據信息被劃分區塊,因為所有操作具有強一致性,因此正常節點每個區塊以及區塊順序都應該是完全一致的.管理節點定時檢測異常的調度節點并進行同步恢復操作.

4.3 數據冗余備份和一致性

通過冗余的鏡像機制來保證集群的高可用特性,設計需要考慮實時性和容錯性,對于主備數據節點數據一致性的選擇,最簡單的做法首選強一致性,但CAP 理論[9]告訴我們一致性、可用性和網絡分區三者不可兼得,弱一致性也有其適用范圍,特別是在實時性要求較高而對及時一致性要求較低的場景.

主備數據節點的狀態由管理節點監控,調度節點通過管理節點獲取主備數據節點的狀態,可以指派數據寫入和查詢節點,同時實時任務處理過程中數據節點狀態異常也實時反饋給管理節點.前面已經提到數據寫入和查詢的的數據流,寫入時調度節點數據直接寫入主節點,由主節點將數據往鏡像節點做自動轉發同步,不保證主備節點數據的強一致性,只保證數據的最終一致性,查詢時主庫鏡像庫分擔查詢壓力,由調度節點按負載情況分派查詢任務.

4.4 數據異常處理

主庫節點若發生異常,備節點會由管理節點指派升級為主節點,異常節點恢復后會作為備份節點繼續運行,管理節點會在檢測到異常數據節點時啟動一致性檢測,通過兩層版本號檢測和文件級同步的方式可以使恢復操作對實時處理性能影響最小化,且恢復效率高,具體檢測和恢復方式為：通過分析主備數據節點的各分片版本號以及分片內文件組的版本號(version)不一致情況,確定需要同步的索引和數據文件塊并進行數據同步,即對不同版本號文件組直接做替換操作,數據流通過底層TCP 傳輸.

為了不影響整個系統的實時性,主備數據異常恢復時采用在線同步模式,即同步過程中不影響數據正常讀寫,采用如下策略：數據同步過程中主節點產生的修改記錄以Log 方式記錄在主數據節點,并在同步完成后解析Log 和更新數據,解析過程中的數據修改仍然追加到Log 末尾,直到所有Log 解析完畢,管理節點設置該主備數據節點狀態為Normal.

5 應用實例

如下是一個分布式實時數據庫的搭建和設計思路：

(1)建構系統架構：創建管理節點集群,調度節點集群,數據節點集群,數據節點服務器的數量和數據量有關,管理節點因為體量較小,可以和調度節點合并到同一個服務器集群.管理節點存儲節點元信息,包括數據分布規則、各節點狀態等信息,調度節點存儲測點信息表,數據節點存儲包含測點名、數據時間和數據值的數據表,每個數據節點通過主備節點實現冗余備份,管理節點、調度節點和數據節點間分別建立連接,數據和調度節點定時向管理節點匯報當前活動狀態及繁忙程度,調度節點定時從管理節點同步所有節點狀態；

(2)建立分布規則：管理節點依據輸入參數確定系統唯一的分布規則,分布規則的設計見2.1 節；

(3)測點請求：調度節點收到測點寫請求后,檢測測點合法性,檢測通過執行對測點表的操作,并向其余所有調度節點做同步,一致性設計見4.2 節；

(4)數據寫請求：調度節點收到數據寫請求后根據測點名和數據時間,依據分布規則,將數據發送到不同的數據主節點,數據節點的存儲方式見第3 節,另外,如4.3 節所述,數據主節點在存儲過程中將數據轉發給對應的備份節點.數據存儲過程中發生異常會執行恢復流程,見4.4 節；

(5)數據讀請求：調度節點收到讀數據請求后,根據讀請求中測點名和數據時間,通過分布規則篩選數據節點,拆分并重新組織多個讀取子任務分配到多個數據節點并行讀取數據,完成后將結果返回調度節點,調度節點待所有子任務返回后做聚集處理.將結果反饋到請求端.

為了驗證該設計的可行性,使用C++語言開發了分布式實時庫原型系統,使用3 個管理和調度服務器的集群,5 個數據服務器的集群,執行了數據讀寫測試,并和單機實時數據庫做對比.測試數據來源于電力調度系統模擬數據,原始數據量均為10 TB,測點規模為1000 萬級別,分別從測點建立,數據接入效率,數據實際存儲量,數據隨機查詢四個方面進行測試對比.表1是對比結果.

表1 性能測試對比

測試結果顯示,在磁盤壓力較低的情況,單機存儲因為無需做數據分布處理和同步,性能較高；而在需要做復雜運算或者磁盤IO 開銷大的場景下,分布式存儲比單機存儲方式有幾倍的性能提升.

6 結語

由于工業領域對實時數據庫的性能、可靠性、可擴展性等要求越來越高,本文通過將分布式技術和實時數據庫技術相結合,提出一種實時數據系統中的數據分布式存儲的設計,同時給出了數據冗余、數據重分布以及數據一致性的一整套方案.為突破當前實時數據庫技術瓶頸提供技術支撐.