某軟件公司國產分析型數據庫選型方法論
以下文章來源於ITPUB,作者老魚
ITPUB.
ITPUB官方賬戶,分享社區技術乾貨內容,瞭解社區最新動態,參與社區精彩活動。
摘要:本文是國產數據庫選型策略及方法論系列
國產數據庫選型策略及方法論,是我今年的重點選題之一。這個選題的靈感源於我與朋友的一次深入交談。
在現今的國際環境下,技術自主可控的重要性日益突顯。這一趨勢的形成受多重因素推動,包括政治緊張局勢、貿易保護主義以及對數據隱私和安全的加強意識。爲應對這些挑戰,發展和採用國產技術,特別是國產數據庫,已經成爲確保對關鍵技術和數據控制權的有效策略,同時,這也有助於提升國內技術和產業的競爭力。
目前,越來越多的企業正在認識到這一點,並積極考慮並實施國產技術替代和國產數據庫選型。然而,這個過程並不容易,存在許多潛在的問題和挑戰。
因此,如果能系統地總結出各種企業的國產數據庫選型策略和方法論,爲企業提供一個參考框架,幫助他們根據自身需求和條件選擇最適合的國產數據庫,那將是極具價值的。其中,理解和分析真實案例是這個過程中的關鍵步驟。
基於此,老魚常在各種會議上尋找來自用戶企業的相關演講,這樣的機會使老魚能從多角度理解和總結不同企業的數據庫選型策略和方法論。
以下是老魚對某軟件公司憑證引擎國產分析性數據庫選型策略及方法論演講的總結:
憑證引擎是財務覈算系統的核心組成部分,負責憑證處理和財務賬簿管理。在企業中,各種業務系統產生的數據會通過憑證引擎進行保存和記賬,同時落實財務管控規則,並生成各類財務報表。這些報表通過賬戶查詢和接口,可供企業財務的其他外圍系統使用,如稅務、資金預算等。憑證引擎的性能和穩定性對整個財務覈算體系具有重要的影響。
業務需求
某軟件公司在財務系統領域有着二十多年的積累,爲支持大型企業的數字化轉型,以及滿足當前創新趨勢的發展需求,在新創項目中開發了新一代的財務總賬核心系統。在這個過程中,提出了三項具有挑戰性的技術指標:
面臨五大技術挑戰
複雜的憑證數據結構:一個憑證包含至少五張表,每個表字段衆多,總計可能達到一千多個字段。這些字段包含用於集團管控的主數據,科目和輔助覈算的維度,以及用戶和審批人的數據權限控制內容。
嚴格的數據准入校驗:由於憑證是財務核心數據,一旦生成,其財務編號不能更改或刪除。進行嚴格校驗,涉及大約120種主數據,主數據項數達到百萬項,以滿足大型集團細緻靈活的管控需求。此外,需要滿足約300項的校驗規則和數據權限控制需求,可能會面臨10萬量級的用戶組。
憑證編號的連續性需求:憑證編號需要連續遞增且不能斷號,這對於數據庫,特別是分佈式數據庫的自增ID功能,是一個挑戰。需要在應用層面解決這個問題,雖然可以藉助一些數據庫的能力。
高性能需求:系統需要滿足每秒處理2000張憑證的性能要求,這意味着大量的數據入庫壓力和校驗延時。既需要兼容用戶的日常實時提交,也需要兼容大容量的數據提交,同時還需要關注用戶體驗。
適配國產數據庫:國產化數據庫可能會帶來兼容性問題,包括通信協議等。需要在選擇新的開發語言和打通數據庫時考慮這些問題。此外,該軟件公司也希望與國產數據庫廠商有更深入的合作,挖掘數據庫底層的接口,實現更好的實踐。
這些挑戰需要在技術層面進行深入的研究和攻關,以實現新一代財務總賬核心系統的高性能和高效率目標。
工程設計和方案要點
憑證引擎設計:整個設計分爲四個模塊:
數據校驗:校驗包括數據有效性、取值範圍、財務管控、集團管控等多個方面。爲避免在高性能場景下涉及大表的聯表查詢,採用位圖方式,一次CPU位圖處理即可完成校驗。
編號發放:爲保證憑證編號連續不斷,憑證先被寫入Kafka進行串行化,然後批量處理,減小數據庫壓力,提高性能。
事務和狀態管理:主數據和校驗規則存儲在內存中,數據狀態管理模塊類似於數據庫架構。最後,數據寫入憑證記賬數據庫,待記帳數據通過同步機制在兩數據庫間實時同步。
主數據校驗:採用哈希進行查詢,爲避免對數據庫壓力過大,採用百萬位級的大位圖進行數據權限管理。
業務校驗規則:支持300項可配置規則,同時爲了支持實施和第三方廠方實施,提供了腳本規則開發的功能。
整體上,這個工程設計和方案利用了憑證網關、外圍業務、接口適配和憑證校驗等多個模塊來處理和校驗數據,充分考慮了性能和數據準確性,使得數據處理更高效,減小了數據庫壓力。同時,這個設計也很靈活,提供了可配置規則和腳本規則開發的功能,滿足了不同用戶的需求。
工程設計的主要特點和挑戰
編程語言選擇:在初期,產品主要是用Java開發,但由於需要使用更低級的CPU指令以及對內存和計算的控制,Java無法滿足需求。因此,選擇了使用Rust語言,它是一種現代編程語言,提供了零成本抽象,支持併發和原編程,可以提供類似C或C++的系統控制能力。
工程師培養問題:Rust工程師在國內相對較少,因此選擇從Java團隊內部進行轉崗。雖然Rust編譯器的嚴格檢查可能使編碼速度變慢,但它能更早地暴露問題,從而降低整體的開發成本。
編碼格式:在高性能處理環境中,數據冗餘和文本類型會對網絡傳輸、硬盤I/O和解析產生很大壓力。爲了解決這個問題,選擇了使用Flatbuffer編碼,因爲它可以高效地進行單個字段的讀取,而無需完全解碼整個數據。
數據零拷貝和零成本抽象:這是利用Rust對底層系統控制能力的結果,可以更好地利用CPU處理流水線,優化CPU的自身優化。
性能壓力測試:在每秒處理2000張憑證時,硬件資源使用情況良好。一個憑證對應24行數據,每秒可以處理48000行入庫,字段數量超過1000個。雖然Kafka和數據庫佔用的CPU資源相對較多,但是整體性能仍然可以達到需求。
總的來說,這個工程設計利用了Rust的優勢,克服了新語言帶來的挑戰,實現了高性能和低延時的數據處理,同時保證了數據的準確性和安全性。
未來工作計劃
數據庫優化:該軟件公司計劃通過更進一步優化數據庫的處理能力以提高性能。儘管已經可以處理每秒2000張憑證,但他們的目標是進一步提升這個數字。其中一個方法是使用文件方式進行入庫,如CSV文件,這在初步試驗中已經顯示出顯著的性能提升。
代碼優化和數據庫接口優化:進一步優化代碼和數據庫接口能夠進一步提高單線程入庫的性能。他們的目標是在硬件使用低的情況下,使單個線程入庫能達到每秒1450張。
支持快速查詢:爲了能在3秒內查出憑證,他們計劃採用某國產分析型數據庫,利用高性能計算來提升統計分析的能力。此外,他們還希望採用預計算的方式降低一次報表查詢時的IO和CPU計算力消耗。這將使財務報表的查詢更爲高效,滿足3秒內查出財務報表的挑戰。
總的來說,我們在國產數據庫選型策略和方法論方面的工作是綜合性的,需要在理解項目需求、評估現有技術、優化現有流程和規劃未來工作等多個方面進行深入思考和實踐