某軟體公司國產分析型資料庫選型方法論

以下是老魚對某軟體公司憑證引擎國產分析性資料庫選型策略及方法論演講的總結：

憑證引擎是財務核算系統的核心組成部分，負責憑證處理和財務賬簿管理。在企業中，各種業務系統產生的資料會透過憑證引擎進行儲存和記賬，同時落實財務管控規則，並生成各類財務報表。這些報表透過賬戶查詢和介面，可供企業財務的其他外圍系統使用，如稅務、資金預算等。憑證引擎的效能和穩定性對整個財務核算體系具有重要的影響。

業務需求

某軟體公司在財務系統領域有著二十多年的積累，為支援大型企業的數字化轉型，以及滿足當前創新趨勢的發展需求，在新創專案中開發了新一代的財務總賬核心系統。在這個過程中，提出了三項具有挑戰性的技術指標：

1、期望新的憑證引擎能夠處理年度憑證數量達到40億，這是當前處理量的4倍。

2、期望總賬查詢報表能在3秒內返回響應。需要注意的是，總賬報表並非簡單的點查詢，它涉及複雜的資料整理過程，包括利潤中心統計、會計期間和科目的複雜計算等。當前，財務報表查詢速度相對較慢，希望能將其最佳化到3秒以內。

3、期望新的憑證引擎能支援每秒處理2000張憑證。這並非指2000行，而是針對不同的客戶和場景。對於實時錄入憑證的客戶，這是一個挑戰性的效能需求;而對於需要批次處理的客戶，這樣的效能可以縮短他們的處理時間視窗。

面臨五大技術挑戰

複雜的憑證資料結構：一個憑證包含至少五張表，每個表欄位眾多，總計可能達到一千多個欄位。這些欄位包含用於集團管控的主資料，科目和輔助核算的維度，以及使用者和審批人的資料許可權控制內容。裸資料本身即達到30KB，對於結構化資料來說，資料量較大。

嚴格的資料准入校驗：由於憑證是財務核心資料，一旦生成，其財務編號不能更改或刪除。進行嚴格校驗，涉及大約120種主資料，主資料項數達到百萬項，以滿足大型集團細緻靈活的管控需求。此外，需要滿足約300項的校驗規則和資料許可權控制需求，可能會面臨10萬量級的使用者組。

憑證編號的連續性需求：憑證編號需要連續遞增且不能斷號，這對於資料庫，特別是分散式資料庫的自增ID功能，是一個挑戰。需要在應用層面解決這個問題，雖然可以藉助一些資料庫的能力。

高效能需求：系統需要滿足每秒處理2000張憑證的效能要求，這意味著大量的資料入庫壓力和校驗延時。

既需要相容使用者的日常實時提交，也需要相容大容量的資料提交，同時還需要關注使用者體驗。

適配國產資料庫：國產化資料庫可能會帶來相容性問題，包括通訊協議等。需要在選擇新的開發語言和打通資料庫時考慮這些問題。此外，該軟體公司也希望與國產資料庫廠商有更深入的合作，挖掘資料庫底層的介面，實現更好的實踐。

這些挑戰需要在技術層面進行深入的研究和攻關，以實現新一代財務總賬核心系統的高效能和高效率目標。

工程設計和方案要點

憑證引擎設計：整個設計分為四個模組：

· 憑證閘道器：處理各種協議介入，將不同格式的憑證轉換成內部標準的憑證格式。

· 外圍業務：處理憑證的沖銷、核銷和關聯交易單據等業務，利用事務機制進行處理。

· 介面適配：處理同步和非同步的介面，完成標準介面轉讓。

· 憑證校驗模組：這是邏輯最複雜且對算力消耗最大的模組。它包含120種主資料，每張憑證需與資料庫進行多次網路通訊。為降低延時，主資料從資料庫拉出，將校驗的複雜度從網路訪問開銷轉移到記憶體。

資料校驗：校驗包括資料有效性、取值範圍、財務管控、集團管控等多個方面。為避免在高效能場景下涉及大表的聯表查詢，採用點陣圖方式，一次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秒內查出財務報表的挑戰。

總的來說，我們在國產資料庫選型策略和方法論方面的工作是綜合性的，需要在理解專案需求、評估現有技術、最佳化現有流程和規劃未來工作等多個方面進行深入思考和實踐。