前言
隨著5G、物聯(lián)網(wǎng)和AI技術的全面布局，世界萬物互聯(lián)、智能感知，緊密相關的數(shù)據(jù)高速產(chǎn)生，快數(shù)據(jù)繼大數(shù)據(jù)之后成為未來十年顯著的時代特征，數(shù)據(jù)分析正在發(fā)生質(zhì)變。當前，以ChatGPT為代表大語言模型LLM的盛行，更是加速了這種變革。面對更多更快更復雜的實時數(shù)據(jù)決策分析，傳統(tǒng)數(shù)據(jù)庫系統(tǒng)面臨著算力不足、多場景融合、多源異構、彈性擴展、高性能、高可靠、高可用、高吞吐量、云原生服務等諸多挑戰(zhàn)?？鞌?shù)據(jù)密集的數(shù)據(jù)智能時代，融合人工智能技術的高性能分布式數(shù)據(jù)庫系統(tǒng)將是時代所需。
傳統(tǒng)的單機數(shù)據(jù)庫在面對大規(guī)模數(shù)據(jù)量和高并發(fā)訪問時，往往會面臨性能瓶頸和可靠性問題。分布式數(shù)據(jù)庫可以有效地處理大規(guī)模復雜的數(shù)據(jù)，將數(shù)據(jù)分布存儲在多臺機器上，實現(xiàn)數(shù)據(jù)的水平擴展，從而提高了系統(tǒng)的整體性能和容量。同時，分布式數(shù)據(jù)庫可以通過數(shù)據(jù)復制和容錯機制來提高系統(tǒng)的可靠性，即使少量機器發(fā)生故障，整個系統(tǒng)仍然可以繼續(xù)運行，從而避免了單點故障帶來的風險。另外，分布式數(shù)據(jù)庫還可以支持跨地域、跨數(shù)據(jù)中心的部署，提高了系統(tǒng)的可用性和災備能力。因此，分布式數(shù)據(jù)庫可以有效解決單點故障和性能瓶頸的問題，提高系統(tǒng)的可靠性、可用性和擴展性。
BigInsights是貝格邁思面向快數(shù)據(jù)實時分析所需研發(fā)的新一代高性能分布式數(shù)據(jù)庫，滿足從強一致核心交易到復雜計算及分析的企業(yè)級實時業(yè)務需求，針對高速高并發(fā)的實時處理及分析應用場景具有其高效適用性。相較于傳統(tǒng)分布數(shù)據(jù)庫，BigInsights踐行了一條不同的技術路線：
1）BigInsights融合新型硬件技術革新，打造自適應處理器的異構智能計算平臺，通過軟硬一體化創(chuàng)新設計的分布式架構實現(xiàn)高性能和高可用；
2）BigInsights分布式內(nèi)存驅動架構，通過高速網(wǎng)絡和端到端的總線協(xié)議，在分布式內(nèi)存中實現(xiàn)HTAP和NewSQL統(tǒng)一融合的完全分布式事務處理機制，真正做到數(shù)據(jù)強一致性和系統(tǒng)擴展性的統(tǒng)一；
3）BigInsights行列混合存儲和可查詢壓縮技術，實現(xiàn)高效數(shù)據(jù)查詢和海量數(shù)據(jù)存儲能力；
4）BigInsights云原生NewSQL分布式架構，使數(shù)據(jù)庫更具彈性擴展和多模態(tài)數(shù)據(jù)適用性；
5）BigInsights實現(xiàn)以DRAM和存儲級內(nèi)存SCM為中心，兼容NVMe-oF SSD的軟件定義多級數(shù)據(jù)存儲架構，實現(xiàn)冷熱分離的多級數(shù)據(jù)存儲系統(tǒng)，充分發(fā)揮DRAM、SCM和NVMe-oF SSD的不同特性，實現(xiàn)高效數(shù)據(jù)存儲。
6）通過向量引擎及SIMD向量并行能力為大規(guī)模數(shù)據(jù)計算提供底層并行和并發(fā)計算的基礎。
BigInsights作為一個分布式數(shù)據(jù)庫系統(tǒng),具有很強的容量和性能。它可以很好地支持海量數(shù)據(jù)的高并發(fā)處理與訪問，滿足了企業(yè)對于可靠和高效的數(shù)據(jù)存儲與處理能力的需求。同時，BigInsights將多模態(tài)計算統(tǒng)融于統(tǒng)一的計算框架，以應對數(shù)十億級以及關系、圖、文檔等多模態(tài)的分析查詢需求，基于自適應的異步并行框架和事務調(diào)度機制大大提高任務調(diào)度效率。
本文將從幾個重要方面來介紹BigInsights是如何同時實現(xiàn)高性能和高可用的。包括分布式架構設計、動態(tài)擴縮容機制、負載均衡策略、存儲引擎優(yōu)化、緩存設計、支持新的硬件等技術,以及其內(nèi)部采用的高性能事務處理方法等。
NewSQL分布式架構
BigInsights將企業(yè)級關系數(shù)據(jù)庫功能與NewSQL云原生架構的水平可擴展性和彈性伸縮相結合，系統(tǒng)采用Share-Nothing架構以節(jié)點為單元進行彈性伸縮，基于MPP+SMP并發(fā)模式充分地利用NODE的集成資源，融合了NoSQL和SQL的優(yōu)點，具有高性能、高可用性和高擴展性，滿足用戶的按需使用和簡單易用需求，利用“極致彈性”滿足數(shù)據(jù)智能時代下企業(yè)業(yè)務的快速發(fā)展需求。BigInsights高效分布式事務基于Google Spanner架構設計，主副本之間寫入操作的強一致性通過Raft協(xié)議實現(xiàn)，集群級的分布式ACID事務使用混合邏輯時鐘（hybrid logical clocks）實現(xiàn)，支持SSI（Snapshot serializable isolation）隔離級別。讀操作默認保證強一致性，但可以動態(tài)選擇從Follower讀和副本讀。
圖一 BigInsights系統(tǒng)架構
BigInsights云原生分布式系統(tǒng)架構（參照圖一）以Node節(jié)點為基本擴展單元，每個節(jié)點主要有兩個組件MServer和DBServer。其中，MServer負責系統(tǒng)元數(shù)據(jù)管理，包括基本存儲單元Tile的位置信息、表結構、安全信息、配置管理等信息，MServer本身依靠Raft實現(xiàn)高可用，并可單獨擴展。DBServer是BigInsights的數(shù)據(jù)庫核心組件，負責數(shù)據(jù)庫相關的分布式事務和數(shù)據(jù)處理，從邏輯上主要分為四層：查詢引擎Query Engine、事務引擎Transaction Engine、執(zhí)行引擎Execute Engine和存儲引擎Storage Engine，這些引擎從邏輯上都位于DBServer進程中，共享DBServer的進程空間。
查詢引擎Query Engine主要支持SQL和CQL兩種API。其中SQL API完全兼容PostgreSQL語法；CQL API兼容Cassandra的NoSQL語法，對應于文檔數(shù)據(jù)庫的存儲模型。
事務引擎Transaction Engine主要負責分布式事務處理。BigInsights通過MVCC結合快照隔離的事務實現(xiàn)，與基于鎖定和兩階段提交的方法相比，它在避免沖突方面具有優(yōu)勢，支持任意規(guī)模的跨多行、多分片和多個節(jié)點完全分布式ACID事務，實現(xiàn)了透明且可擴展的事務處理，遵守嚴格的響應時間要求：
●將更新的可見性與原子提交分離，實現(xiàn)事務橫向擴展。避免了組件之間任何形式的復雜且耗時的協(xié)調(diào)，例如兩階段提交協(xié)議。相反，事務可以快速并行提交，而不會影響一致性。
●分解和分配各種相對獨立的事務任務分配到事務管理器的不同獨立組件，并單獨擴展它們，例如本地事務管理器（mvcc）、沖突管理器（conflict）、記錄器、快照服務器和提交定序器等。
●盡可能引入異步和消息批處理。異步使得大部分混亂處理都在事務范圍之外，批處理可以減少消息總數(shù)。
執(zhí)行引擎Execute Engine是完全并行分布式的，實現(xiàn)了查詢間并行性和查詢內(nèi)并行性，特別是支持運算符內(nèi)并行性，并且可以具有任意數(shù)量的實例。為了橫向擴展OLTP工作負載，本地執(zhí)行引擎實例負責處理本地數(shù)據(jù)副本查詢的子集。
存儲引擎Storage Engine主要基于LSM-Tree實現(xiàn)實現(xiàn)以tile分片方式數(shù)據(jù)高效存儲管理。BigInsights的最小數(shù)據(jù)分片單位為tile，是一種將table進行垂直和水平切分實現(xiàn)行列混合存儲的數(shù)據(jù)切分單元。每個tile數(shù)據(jù)分片對應一個Raft Group，可配置分布在多個節(jié)點上，以此保證高可用性，相應的元數(shù)據(jù)由MServer管理。Tile式數(shù)據(jù)分片可以有效支持OLTP和OLAP混合事務能力，并且很好的發(fā)掘數(shù)據(jù)關聯(lián)聚合能力，提升數(shù)據(jù)本地聯(lián)合操作性能。
基于Tile的行列混合分布式存儲
圖二 Person表數(shù)據(jù)Tile分片
BigInsights基于Tile實現(xiàn)行列混合存儲，表Table被按行或列進行聚簇式分片，類似于BigTable的列族column family進行相關列聚合存儲。參照圖二，Person表包含PersonID、Name、Address、BirthDate、Gender等一系例相關person信息的列，其中Name和Address是強相關列，因此聚合為personal_data列族；BirthDate和Gender屬于IO相似列，因此BirthDate和Gender聚合為demographic列族。從而，person表可以按照列族和行進行劃分成不同tile單元。Tile單元內(nèi)數(shù)據(jù)組織基于行列混合存儲模式，按PAX格式進行持久化數(shù)據(jù)存儲。Tile數(shù)據(jù)存儲可以有效的融合行存儲和列存儲的各自優(yōu)勢，有效支持OLTP和OLAP混合的HTAP事務處理能力。很顯然，針對OLTP任務可以選擇面向行存儲的Tile，例如圖二中的TileX；相應地OLAP任務，會選擇傾向于列存的Tile，如圖二中的Tile1、Tile2以及TileN。結合AiSQL的自調(diào)優(yōu)機制，這種Tile可以挖掘或學習行列數(shù)據(jù)間的關聯(lián)性，自動實現(xiàn)數(shù)據(jù)表中基于相關行列數(shù)據(jù)的調(diào)整和切分，實現(xiàn)更具用戶應用場景的最優(yōu)數(shù)據(jù)分片方法。
PAX提供了一種基于page的行列混合存儲機制。在page里面使用了一種mini page的方式，將record切到到不同的mini page里面。假設有n個attributes，PAX就會將page分成n個mini pages，然后將第一個attribute的放在第一個mini page上面，第二個放在第二個mini page，以此類推。PAX的格式其實是行存儲和列存儲的一種折中，當要依據(jù)某一列進行scan的時候，我們可以方便的在mini page里面順序掃描，充分利用cache。而對于需要訪問多attributes得到最終tuple的時候，我們也僅僅是需要在同一個page里面的mini page之間讀取相關的數(shù)據(jù)。
可見，基于PAX的混合存儲可以在一個數(shù)據(jù)庫中既有行存儲結構，又有列存儲結構，兩種存儲結構結合使用以提升系統(tǒng)的整體性能，重要的是，它是一個Cache友好高效的行列混存模式。Google Spanner首次采用PAX行列混合數(shù)據(jù)結構Ressi，用來支持OLTP和OLAP。
BigInsights有效的基于Tile模式進行數(shù)據(jù)分片機制，每張表被分成很多個tiles，tile是數(shù)據(jù)分布的最小單元，通過在節(jié)點間搬運tile以及tile的分裂與合并，就可以實現(xiàn)幾乎無上限的scale out。每個tile有多個副本，形成一個Raft Group，通過Raft協(xié)議保證數(shù)據(jù)的高可用和持久性，Group Leader負責處理所有的寫入負載，其他Follower作為備份,數(shù)據(jù)分布模式參照圖三。MServer節(jié)點會負責協(xié)調(diào)tile的搬運、分裂等操作，保證集群的負載均衡，這些操作是直接基于Raft Group實現(xiàn)。
圖三 BigInsights基于Tile數(shù)據(jù)分片的分布模式
分布式數(shù)據(jù)庫的關鍵要素之一是數(shù)據(jù)如何在不同的數(shù)據(jù)存儲節(jié)點之間分布。BigInsights基于Tile的數(shù)據(jù)分片模式很好的解決了有效支持HTAP的數(shù)據(jù)組織模式。但是，如何均勻的分布Tile的數(shù)據(jù)劃分方式至關重要。BigInsights提供基于范圍分區(qū)的主索引哈希（Partition Hashing Primary Index(PHPI）)（參考圖四）方式進行數(shù)據(jù)劃分：
●鍵值范圍分區(qū)：基于分區(qū)列進行范圍劃分，均勻的把數(shù)據(jù)分配到各個主機。
●哈希映射分區(qū)：哈希是一種非常簡單的分區(qū)方案，并且具有非常擅長跨數(shù)據(jù)存儲平衡數(shù)據(jù)的優(yōu)點。系統(tǒng)將從密鑰計算哈希值，并根據(jù)哈希值的模數(shù)分配數(shù)據(jù)。有效的一致性哈希算法可以有效的將數(shù)據(jù)分配到相應的節(jié)點。哈希的缺點是對于掃描系統(tǒng)必須在所有數(shù)據(jù)存儲中進行掃描，因為數(shù)據(jù)可以存儲在任何數(shù)據(jù)存儲中，與鍵范圍分區(qū)相比，掃描需要更多的資源。
●二維分區(qū)：二維分區(qū)是一種自動分區(qū)模式，通常是結合在前述分區(qū)模式一起使用。首先，需要定義一個隨時間變化的參數(shù)和一個標準，使系統(tǒng)自動對數(shù)據(jù)進行分區(qū)以獲得最佳資源。特別是如何有效的隨著時間變化，系統(tǒng)運行自動發(fā)現(xiàn)不同列數(shù)據(jù)間的關聯(lián)性，從而進行列族聚簇，實現(xiàn)不同tile的數(shù)據(jù)劃分模式。BigInsights不僅允許二維分區(qū)，還允許多維分區(qū)。
圖四 基于范圍分區(qū)的主索引哈希數(shù)據(jù)分片（Partition Hashing Primary Index）
BigInsights基于范圍分區(qū)的主索引哈希數(shù)據(jù)分片方法可以很好的為系統(tǒng)擴縮和自動數(shù)據(jù)平衡提供了算法保證。特別是，基于主索引范圍劃分索引為負載范圍查詢提供了高效的數(shù)據(jù)訪問保證；基于一致性哈希散列和虛擬節(jié)點聚合算法，可以有效的實現(xiàn)數(shù)據(jù)的均勻散列到所有數(shù)據(jù)節(jié)點。該方法的另一大優(yōu)點在于系統(tǒng)擴所容導致的數(shù)據(jù)遷移影響的節(jié)點較少，主要針對相鄰范圍內(nèi)的節(jié)點，結合raft機制，基本可以實現(xiàn)自動化高效系統(tǒng)擴所容和負載均衡能力。這一點在NewSQL分布式數(shù)據(jù)庫（如CockroachDB、ScyllaDB、Cansandra等）和P2P分布式哈希表DHT得到了很好的驗證，對分布式系統(tǒng)自動數(shù)據(jù)均衡有很大作用。
高效橫向擴縮容和自動負載均衡
Raft協(xié)議能夠輕松實現(xiàn)動態(tài)成員資格更改。當節(jié)點被刪除時，只需要重新運行受影響分片的Raft領導者選舉，并由MServer主導重新創(chuàng)建復制副本以實現(xiàn)完全復制。當節(jié)點被添加到集群后，MServer會根據(jù)每個DBServer上持有的分片數(shù)和分片領導數(shù)自動進行負載平衡，將分片移動到新加入的節(jié)點上。這種方式實現(xiàn)了快速的橫向擴展和縮減，提升了讀寫負載的性能。
如圖五所示，我們將新節(jié)點4添加到具有三個節(jié)點和四個分片的群集時究竟會發(fā)生什么。節(jié)點1有兩個領導者，Tile1-Leader和Tile4-Leader。
圖五 系統(tǒng)水平擴容與自動負載均衡
●將向集群添加新節(jié)點Node 4。
●MServerLeader察覺到集群的變化并啟動負載均衡操作。這涉及到領導者（例如Tile4-Leader）離開節(jié)點1。
●為了實現(xiàn)完全的負載平衡，?些追隨者也會從節(jié)點2和節(jié)點3移動到節(jié)點4。需要注意的是，所有的移動都是以公平的方式進行的，沒有?個現(xiàn)有節(jié)點承擔填充新節(jié)點的負擔，集群中的所有節(jié)點都按照公平的份額計算，因此集群永遠不會受到壓?。
●圖六展示了最終的完全負載平衡的集群，每個節(jié)點都有?個領導者和三個追隨者。
圖六 自動負載均衡
BigInsights的架構設計實現(xiàn)了快速的橫向擴容和縮容，確保了集群的高可用性，并提升了讀寫性能。它通過將讀寫負載均衡到其他節(jié)點上，充分利?整個集群的硬件資源。這種設計使得BigInsights能夠靈活地適應不同的?作負載，并實現(xiàn)?效的數(shù)據(jù)處理能力。
高性能讀取
圖七 多副本讀取
鑒于在寫?時已經(jīng)完成了確保一致性的重要任務，BigInsights的Raft實現(xiàn)確保讀取請求可以以極低的延遲提供服務，?無需使用任何仲裁。此外，它允許應?程序客戶端選擇從Leader讀?。ㄓ糜趶?致性讀?。┗驈腇ollower讀?。?于時間線?致性讀?。igInsights甚?允許從異步更新的集群中取讀副本，這些副本不參與寫?路徑。從Follower中讀取副本可以顯著提高系統(tǒng)的吞吐量，因為Follower?Leader多，?且如果Leader恰好位于不同地區(qū)，甚?可以減少延遲。
高效的緩存設計
我們知道，Cache是實現(xiàn)有限內(nèi)存對磁盤熱數(shù)據(jù)的高效緩存，是提高讀性能的最重要數(shù)據(jù)庫組件。LRU（Least Recently Used，最近最少使用）是一種常見的緩存淘汰算法。LRU算法的基本思想是根據(jù)數(shù)據(jù)的訪問歷史記錄來淘汰最近最少使用的數(shù)據(jù)，以便為新的數(shù)據(jù)騰出空間。
LRU算法適用于需要根據(jù)訪問模式來淘汰數(shù)據(jù)的場景，例如緩存系統(tǒng)和頁面置換算法。但數(shù)據(jù)庫的Scan操作是不利于這個LRU算法。當DBScan時，一時間會產(chǎn)生大量的數(shù)據(jù)并進入到鏈表的熱頭，雖然這些Scan數(shù)據(jù)如果只被用到一次，最終會通過鏈表冷尾驅逐出去，但是，它因為消耗內(nèi)存特別大，導致一些熱數(shù)據(jù)被不當?shù)尿屩鸪鲦湵?，從而降低了讀性能。
大家都知道RocksDB API接口既支持點查找Lookup，也支持范圍查找Scan。早期的RocksDB的緩存只支持block形式緩存，即緩存的單位是block（block大小可設，最小是4KB，但一般是幾十KB）。這就存在一個浪費，比如：我們需要的是點查Lookup，訪問一個4KB的某個key/value，其key/value大小之和假設只要100字節(jié)，那么為了這么一個100字節(jié)的kv，我們卻至少需要緩存4KB大小的一個block，即浪費率是(1-100/4000)*100%=98%。RocksDB在后續(xù)版本加入了row cache，針對key/value的更細粒度的緩存。因為存在范圍查詢，所以，block cache和row cache都提供，讓程序員根據(jù)應用類型work load來選用，或者組合使用。
這就帶來了新的問題,內(nèi)存大小是一定的，block cache和row cache應該設置比例是多少。假如當前初始設置在比例是1:1已經(jīng)是最優(yōu)選擇。但是隨著時間推移，用戶在work load發(fā)生了變化，點查和scan查詢的比例發(fā)生了變化，這樣就不能最有效利用緩存。
還有另一個問題，一個數(shù)據(jù)分片持有一個RocksDB實例。一個節(jié)點持有多個分片，假如每個分片都獨自管理自己的cache。那么就會因為有的分片數(shù)據(jù)冷，有的分片數(shù)據(jù)熱。這樣冷的分片的cache就沒有得到有效利用。
BigInsights采用智能統(tǒng)一cache管理，根據(jù)當前work load負載情況，動態(tài)調(diào)整row cache和block cache大小比例。同時統(tǒng)一管理調(diào)度cache，防止出現(xiàn)cache孤島出現(xiàn)。根據(jù)訪問情況把cache分為多個等級，防止scan引起不應該的hot key被淘汰。
圖八是BigInsights優(yōu)后的緩存算法和RocksDB傳統(tǒng)LRU算法效果對比：
圖八 BigInsights緩存機制Benchmark結果
另外，緩存管理機制和B+Tree在內(nèi)存的負載上有很多性能瓶頸，比如將Page ID轉換成內(nèi)存指針的Hash Table和它對應的全局Latch，訪問B+Tree的每個內(nèi)存節(jié)點時需要獲取Latch等。為了達到更好的性能，像H-Store、Hekaton、HANA、HyPer、或Silo這樣的內(nèi)存數(shù)據(jù)庫都摒棄了Buffer Manager的設計，把數(shù)據(jù)和索引直接存儲在內(nèi)存中，通過內(nèi)存指針而不是Page ID來高效的訪問這些數(shù)據(jù)。
BigInsights通過去中心化的Pointer Swizzling和頁替換機制實現(xiàn)了工作在SSD上的緩存管理，通過這個緩存管理和樂觀鎖等關鍵技術實現(xiàn)了高性能B+Tree，讓BigInsights既能支持大容量的工作負載，又能提供和內(nèi)存數(shù)據(jù)庫一樣的性能表現(xiàn)。
新硬件架構設計
BigInsights實現(xiàn)以DRAM和SCM內(nèi)存為中心，兼容NVMe-oF SSD的軟件定義多級數(shù)據(jù)存儲架構，可以實現(xiàn)數(shù)據(jù)的冷熱分離的多級數(shù)據(jù)存儲系統(tǒng)，充分發(fā)揮DRAM、SCM和NVMe-oF SSD的不同特性。例如將熱數(shù)據(jù)和索引存于DRAM、溫數(shù)據(jù)和OLAP模式數(shù)據(jù)列式結構持久化于SCM以及冷數(shù)據(jù)和LOG日志數(shù)據(jù)持久化于SSD。
此外，BigInsights存儲引擎是基于LSM-tree的低成本、高性能存儲引擎，其組成部分包括熱數(shù)據(jù)層和冷數(shù)據(jù)層。熱數(shù)據(jù)層存儲在內(nèi)存中，包括活躍內(nèi)存表、固化內(nèi)存表和緩存，而冷數(shù)據(jù)層則存儲在持久化磁盤上，采用多層次結構。活躍內(nèi)存表具有高插入性能，而固化內(nèi)存表則會逐漸轉儲至持久化存儲介質(zhì)。
從內(nèi)存中轉存而來的Immemtable中的記錄會按照數(shù)據(jù)塊的格式被插入L0中。當L0被填滿后，其中的部分數(shù)據(jù)塊會被選中，通過異步的合并操作（Compaction）和L1中的數(shù)據(jù)塊合并，并從L0中移出。同理，L1中的數(shù)據(jù)塊最終會被合并到L2中。BigInsights存儲引擎采用將L0層的數(shù)據(jù)保存在NVMe設備上，L1層及以下的數(shù)據(jù)保存在傳統(tǒng)存儲介質(zhì)上SSD/HHD。
圖九 數(shù)據(jù)冷熱分離
對于OLTP型業(yè)務，由于對訪問延遲非常敏感，云廠商通常采用本地SSD或ESSD云盤作為存儲介質(zhì)。然而，對于流水型業(yè)務（如交易物流、即時通信等），大部分數(shù)據(jù)在生成后訪問頻次逐漸降低，甚至不再被訪問。將這些冷數(shù)據(jù)與熱數(shù)據(jù)一樣存儲在NVMe、SSD等高速存儲介質(zhì)上，會顯著降低整體性價比。BigInsights存儲引擎通過分析負載的訪問特征，實現(xiàn)精準的冷熱數(shù)據(jù)分離，并結合混合存儲架構自動歸檔冷數(shù)據(jù)，為用戶提供極致的性價比。
另外，BigInsights設計了一種基于NVMe-oF SSD快存儲融合B-Tree和LSM-Tree混合架構的鍵值存儲引擎，采用快慢存儲混合的存儲數(shù)據(jù)存儲架構，全面加速數(shù)據(jù)讀寫性能。一方面，在NVMe-oF SSD快存儲上采用SPDK技術構建了一個用戶態(tài)文件系統(tǒng)BMFS，BMFS中的文件是無序的SLAB文件。在NVMe-oF SSD快存儲上使用無序的SLAB文件存儲鍵值對象，在內(nèi)存中構建B-Tree索引來快速查找鍵值對象，在NVMe-oF SSD快存儲上不考慮壓縮操作，而在慢存儲（例如Disk）上采用LSM樹，并使用SST文件存儲鍵值數(shù)據(jù)。另一方面，引入一種基于讀感知的冷熱分層壓縮算法（即上述冷熱存儲分層存儲策略）。該算法將數(shù)據(jù)在快慢存儲之間進行壓縮，通過讀感知追蹤數(shù)據(jù)的冷熱程度，冷數(shù)據(jù)從快存儲降級壓縮到慢存儲，熱數(shù)據(jù)從慢存儲升級壓縮到快存儲，最終實現(xiàn)熱數(shù)據(jù)被固定在快存儲上。這種基于NVMe-oF SSD快存儲融合B-Tree和LSM-Tree混合架構的鍵值存儲引擎設計，顯著提升系統(tǒng)讀寫能力（實驗顯示至少5倍左右的性能提升），降低慢存儲上的寫放大問題，延長慢存儲（如Flash）的使用壽命。
BigInsights通過軟硬一體化創(chuàng)新設計，針對現(xiàn)代CPU、GPU和FPGA的不同并行數(shù)據(jù)分析能力，構建統(tǒng)一的異構自適應計算框架，從底層硬件充分激發(fā)異構處理器協(xié)同并行計算能力，全面突破馮.諾依曼體系架構固有的內(nèi)存墻性能瓶頸，全面提升數(shù)據(jù)庫系統(tǒng)性能。
高性能的事務處理
BigInsights的事務處理機制可以在滿足ACID特性要求的情況下，結合多核處理器與內(nèi)存的硬件特性，實現(xiàn)極高的事務處理性能。增、刪、改、查數(shù)據(jù)庫中的記錄是事務處理所需要的基礎能力，我們可以將這一系列操作視為寫路徑和讀路徑。
1.寫路徑
如圖九所示，為了在DRAM內(nèi)存掉電易失的情況下保證數(shù)據(jù)庫中存儲數(shù)據(jù)的持久化，對數(shù)據(jù)庫記錄的所有修改操作都要先記錄在WAL預寫日志中并存儲在NVMe快速存儲介質(zhì)上。然后再存入內(nèi)存的活躍內(nèi)存表中。然后再通過兩段式Read/Write Phase和Commit Phase的銜接配合來保障一個事務對記錄所做的修改符合ACID特性，并在完成提交后對其他事務和查詢可見?；钴S內(nèi)存表存滿后被轉為固化內(nèi)存表，稍后再被Flush落盤完成持久化。
2.讀路徑
讀路徑。如圖十所示，BigInsights執(zhí)行引擎中的查詢操作按照活躍和固化內(nèi)存表（Memtables/Immutable）、行級緩存（Row Cache）、塊級緩存（Block Cache）和磁盤的順序依次查詢數(shù)據(jù)。內(nèi)存表采用的多版本跳躍鏈表結構可以降低熱點記錄查詢的開銷。行級緩存和塊級緩存可以分別緩存磁盤中的熱數(shù)據(jù)記錄或記錄塊，可以減少磁盤訪問的布隆過濾器（Bloom Filters）和相應索引塊（Index Block）。
圖十 查詢路徑
3.高效能的事務處理
如圖十一BigInsights執(zhí)行引擎為處理每一條分布式事務設計了兩階段的并行事務處理流水線，具體分為準備階段和提交階段。準備階段完成所有所需的查詢和計算操作，然后將所需要進行的修改暫存入事務緩沖區(qū)中。
在提交階段，多個準備線程負責將事務中要寫的內(nèi)容寫入無鎖的任務隊列（Task Queues）中。隨后，多階段流水作業(yè)消費線程會處理相應的任務，包括寫WAL日志、日志落盤、寫入RocksDB內(nèi)存表，最終完成事務提交。不同階段的任務通過事務緩沖區(qū)交接數(shù)據(jù)，實現(xiàn)了并行執(zhí)行，同時處理不同數(shù)據(jù)。這種交疊執(zhí)行時間的方式提高了每個線程的指令緩存命中率，最終提高了系統(tǒng)的吞吐率。在提交階段中，每個任務隊列由一個后臺線程負責管理，而任務隊列的數(shù)量受系統(tǒng)中可用I/O帶寬等硬件條件的限制。
圖十一 事務處理流程
在圖十二所示的分階段事務流水線中，針對每個階段的特性，我們分別優(yōu)化了其并行粒度。具體而言，第一階段的寫日志緩存（收集一個任務隊列中所有寫入內(nèi)容的相關日志）和第二階段的日志落盤由于存在數(shù)據(jù)依賴，因此由單一線程串行完成；第三級的寫內(nèi)存表則由多個線程并發(fā)完成對內(nèi)存表的寫入；第四級的提交負責釋放相應的資源（如所持有的鎖和內(nèi)存空間等），使所有修改可見，由多個線程并行完成。所有的寫入線程采取主動拉取工作的方式，從任意級別中獲取所需執(zhí)行的任務。這種設計允許我們分配更多的線程來處理帶寬高、延遲低的訪問內(nèi)存的工作，同時適用較少的線程完成帶寬相對較低、延遲相對較高的寫入磁盤工作，從而提高了硬件資源的利用率。同時，各個階段內(nèi)的任務相同，可以批量處理任務，大大提高了任務的處理能力。
圖十二 分階段流水作業(yè)
綜上所述，BigInsights高性能分布式數(shù)據(jù)庫，通過合理的架構設計和技術選型，可以實現(xiàn)高性能、高可靠性和高擴展性的分布式數(shù)據(jù)庫系統(tǒng)，為企業(yè)提供可靠、高效的數(shù)據(jù)存儲和處理能力，助力企業(yè)實現(xiàn)數(shù)據(jù)驅動的業(yè)務創(chuàng)新和發(fā)展。
性能基準Benchmark
BigInsights通過先進的架構提供高性能、高可用性、可擴展性和容錯能力，同時通過BSQL和BCQL API提供簡單的接口易于開發(fā)和使用。為了評估BigInsights真實能力并展示其處理實際工作負載的潛力，Benchmark基準測試是有效的途徑。基準測試是評估系統(tǒng)在特定工作負載下的性能和功能的過程，以深入了解其可擴展性、彈性和整體效率。此過程涉及使用標準化工作負載模擬現(xiàn)實世界的使用場景，以了解系統(tǒng)的執(zhí)行、擴展和從故障中恢復的情況。評估數(shù)據(jù)庫處理各種工作負載的能力主要有TPC-C、TPC-H和TPC-DS基準測試，它們代表了分布式數(shù)據(jù)庫不同方面的性能，本文展示了BigInsights TPC-C的測試情況，其他測試結果可以參考貝格邁思官網(wǎng)文檔。
TPC是一系列事務處理和數(shù)據(jù)庫基準測試的規(guī)范。其中TPC-C（Transaction Processing Performance Council）是針對OLTP的基準測試模型。TPC-C測試模型給基準測試提供了一種統(tǒng)一的測試標準，可以大體觀察出數(shù)據(jù)庫服務穩(wěn)定性、性能以及系統(tǒng)性能等一系列問題。對數(shù)據(jù)庫展開TPC-C基準性能測試，一方面可以衡量數(shù)據(jù)庫的性能，另一方面可以衡量采用不同硬件軟件系統(tǒng)的性價比，也是被業(yè)內(nèi)廣泛應用并關注的一種測試模型。
測試結果
數(shù)據(jù)庫服務器節(jié)點類型：8vCPU RAM64GB
通過這個實驗，我們證實了BigInsights具有線性橫向擴展的特性，證明了9個數(shù)據(jù)節(jié)點的性能比3數(shù)據(jù)節(jié)點的性能提高了3倍，這使得BigInsights能夠通過確定系統(tǒng)規(guī)模來處理任何事務工作負載。另外，系統(tǒng)的事務數(shù)量與TPC-C基準以及響應時間相關。使用BigInsights，平均響應時間（12分鐘內(nèi)）與部署中的倉庫和數(shù)據(jù)節(jié)點的數(shù)量無關。基于TPC-C基準測試12分鐘的平均響應時間，BigInsights的響應時間保持在11ms左右。相較于其他創(chuàng)新型分布式數(shù)據(jù)庫系統(tǒng)（如CockroachDB、YugabyteDB等），BigInsights在相應時間方面具有數(shù)量級（即至少10倍）性能提升的明顯優(yōu)勢。
