SophicDB:一個高性能分布式實時數(shù)據(jù)庫系統(tǒng)

崔昌棟　陸　鑫　錢　鋒　王艷蓉

(南京南瑞繼保電氣有限公司　江蘇 南京 211102)

?

SophicDB:一個高性能分布式實時數(shù)據(jù)庫系統(tǒng)

崔昌棟陸鑫錢鋒王艷蓉

(南京南瑞繼保電氣有限公司江蘇 南京 211102)

SophicDB是一個高性能分布式實時數(shù)據(jù)庫系統(tǒng)，它被設計用于處理高速實時數(shù)據(jù)。實時系統(tǒng)中數(shù)據(jù)的時效性對數(shù)據(jù)庫系統(tǒng)的處理速度提出很高的要求，同時為了保證系統(tǒng)的高可用性需求，又對實時數(shù)據(jù)庫提出了分布式主備運行的要求。詳細介紹SophicDB的數(shù)據(jù)組織方式，以及SophicDB系統(tǒng)的設計和實現(xiàn)。通過單機和多機的測試數(shù)據(jù)，以及多個投運系統(tǒng)的實際運行數(shù)據(jù)，表明該數(shù)據(jù)庫系統(tǒng)具備高性能、高擴展性特點，可滿足上百節(jié)點的集群運行要求。

實時數(shù)據(jù)庫分布式高性能高可用性

0　引　言

實時數(shù)據(jù)庫系統(tǒng)是開發(fā)實時控制系統(tǒng)、數(shù)據(jù)采集系統(tǒng)等的重要支撐軟件。在流程行業(yè)中，大量使用實時數(shù)據(jù)庫系統(tǒng)進行控制系統(tǒng)監(jiān)控、系統(tǒng)先進控制和優(yōu)化控制。分布式實時數(shù)據(jù)庫的兩個重要特性是實時性和高可用性，其中實時性包括數(shù)據(jù)實時性和事務實時性。數(shù)據(jù)實時性是存儲數(shù)據(jù)的更新周期，數(shù)據(jù)處理必須在指定時間內完成[1]；事務實時性是指數(shù)據(jù)庫處理事務的速度。高可用性指當系統(tǒng)中某一節(jié)點數(shù)據(jù)庫發(fā)生故障時，其他節(jié)點的數(shù)據(jù)庫仍然可以提供數(shù)據(jù)服務。許多應用場景對系統(tǒng)可用性的指標通常都在99.999%以上，分布式實時數(shù)據(jù)庫系統(tǒng)的可靠性尤其需要特別設計和考慮。

在過去的幾年里，我們設計、實現(xiàn)了一個分布式高性能實時數(shù)據(jù)庫系統(tǒng)SophicDB。SophicDB的設計目的是低延遲、高性能、高吞吐量，并且支持靈活配置的特性，無需像其他分布式數(shù)據(jù)庫系統(tǒng)那樣，對主備數(shù)據(jù)庫的配置需要通過復雜的配置文件進行配置且無法進行靈活切換。SophicDB支持動態(tài)主副本無縫切換，將系統(tǒng)的數(shù)據(jù)劃分到多個實時數(shù)據(jù)庫實例，多個實時數(shù)據(jù)庫實例可以分布在同一節(jié)點或不同的節(jié)點上獨立運行。每個實時數(shù)據(jù)庫實例由獨立的數(shù)據(jù)庫管理程序負責管理數(shù)據(jù)庫中的數(shù)據(jù)。系統(tǒng)同時具有很好的橫向擴展能力和縱向擴展能力。在很多方面，SophicDB和數(shù)據(jù)庫類似：它使用了很多數(shù)據(jù)庫的實現(xiàn)策略，兼顧并行數(shù)據(jù)庫[2]和內存數(shù)據(jù)庫[3]的可擴展性和高性能。同時，SophicDB提供了一個和這些系統(tǒng)不同的數(shù)據(jù)組織方式和存儲方式，以及獨特的離線維護在線裝載等特性，充分考慮到實時系統(tǒng)運行特性而特別設計。

1　數(shù)據(jù)組織與存儲

SophicDB實時數(shù)據(jù)庫通常對應到文件系統(tǒng)中的多個文件，其中一個文件是局部元數(shù)據(jù)文件，其他文件或是數(shù)據(jù)文件，或是索引信息文件。其中數(shù)據(jù)文件中存儲數(shù)據(jù)記錄，如果在對應數(shù)據(jù)庫內表的任意屬性上建有索引則會存在索引文件。索引文件存儲著類似于B樹的數(shù)據(jù)結構[4]，本文主要描述SophicDB中數(shù)據(jù)文件的組織格式等信息。

每個數(shù)據(jù)庫實例是由多張表組成，從訪問優(yōu)化的角度出發(fā)，關系緊密的表的對象通常存儲在同一個數(shù)據(jù)文件里。從物理視圖看數(shù)據(jù)庫是由多個數(shù)據(jù)文件組成。從邏輯視圖看數(shù)據(jù)庫是由多張表組成，每張表由多個屬性項組成。同其他數(shù)據(jù)庫系統(tǒng)類似，通過對象標識來作為通用查詢參數(shù)[5]，在SophicDB內部每個對象都有唯一對象標識ObjectIDentifier(OBJID)來標記，該結構體的定義如下：

structOBJID

{

unsignedlongsub;

unsignedshortcid;

unsignedshortno;

};

其中sub表示對象對應索引段內的下標，cid表示表的ID，no表示索引對象位置被重復使用的次數(shù)，支持對象刪除后的OBJID重復使用。

分區(qū)數(shù)據(jù)由三部分組成：元數(shù)據(jù)區(qū)、OBJID索引區(qū)和數(shù)據(jù)區(qū)。其中元數(shù)據(jù)區(qū)存放每張表的元數(shù)據(jù)信息，包括表中對象數(shù)目、該表對應的OBJID索引區(qū)的首地址和空閑索引項的首尾地址等。OBJID索引區(qū)由若干索引塊組成，每個索引塊存放每張表的索引信息。索引塊內有與表中對象個數(shù)相等的索引項，每個索引項由三段組成，結構如下：

Structi_item

{

Unsignedlongsub;

Unsignedshortid;

Unsignedshortno;

};

一個索引塊的索引項分為兩類：

其一，正被作為某個對象索引使用。通過索引項，可以直接定位對象。如上面OBJID結構定義，OBJID中的sub定位到索引項，根據(jù)索引項就直接定位到對象數(shù)據(jù)。

其二，空閑項。當向表中插入一個對象時，取得一個空閑索引項，基于該空閑索引項生成該對象的唯一標識OBJID。索引塊中的所有空閑項通過一條先進先出隊列組織，首尾指針在元數(shù)據(jù)區(qū)中維護。

數(shù)據(jù)區(qū)由若干數(shù)據(jù)塊組成，每個數(shù)據(jù)塊對應一張表的數(shù)據(jù)。

SophicDB數(shù)據(jù)庫如上所述的數(shù)據(jù)組織方式是基于低延遲、高吞吐的應用場景而特別優(yōu)化設計的：

1) 實際運行系統(tǒng)中對數(shù)據(jù)的訪問90%以上都是基于對象標識方式訪問數(shù)據(jù)，因此可通過在OBJID中存儲索引信息快速定位到數(shù)據(jù)對象。

2) 對象索引區(qū)和數(shù)據(jù)區(qū)緊密存儲，運行過程中數(shù)據(jù)文件通常加載到內存中，優(yōu)化的原則已經(jīng)由傳統(tǒng)數(shù)據(jù)庫的基于磁盤IO訪問優(yōu)化轉化為基于內存訪問的優(yōu)化。從實際運行系統(tǒng)的數(shù)據(jù)更新和訪問的模式分析，絕大多數(shù)數(shù)據(jù)操作都是連續(xù)對象的批量更新和訪問。將索引區(qū)和數(shù)據(jù)區(qū)緊密存儲，連續(xù)對象同時取到高速緩沖存儲器中，極大提升數(shù)據(jù)訪問的效率。

從實際運行系統(tǒng)的測試結果看，單機查詢的吞吐量接近100萬/秒的數(shù)據(jù)訪問，性能指標大大領先于同類產品。

2　數(shù)據(jù)訪問接口

SophicDB數(shù)據(jù)庫同時提供了一整套豐富的數(shù)據(jù)修改和訪問的API函數(shù)。第三方系統(tǒng)需要與已經(jīng)運行的SophicDB系統(tǒng)進行融合，對SophicDB數(shù)據(jù)庫中的數(shù)據(jù)進行訪問，開發(fā)人員可以調用接口實現(xiàn)數(shù)據(jù)訪問。

按照接口的訪問方式分為3種訪問接口，包括本地接口、客戶/服務器訪問接口以及SQL訪問接口。其中SQL方式就是以SQL語句方式進行數(shù)據(jù)查詢；遠程訪問接口則屏蔽實時數(shù)據(jù)庫的實際存儲節(jié)點信息，客戶端無需部署實時數(shù)據(jù)庫，實現(xiàn)對數(shù)據(jù)庫的透明訪問；本地方式則是以本地映射數(shù)據(jù)庫數(shù)據(jù)文件方式對數(shù)據(jù)進行直接操作，在保證數(shù)據(jù)可靠性的同時最大限度優(yōu)化服務的效率。下面分別介紹這3類數(shù)據(jù)訪問接口。

2.1客戶服務器訪問接口

此類接口訪問方式通過數(shù)據(jù)庫建立連接接口實現(xiàn)與系統(tǒng)中某一個實時數(shù)據(jù)庫實例(主本或某一副本)建立連接。具體選擇哪個節(jié)點上的數(shù)據(jù)庫實例進行連接是根據(jù)特定的負載均衡策略選定的，影響因素包括節(jié)點當前系統(tǒng)負載，客戶節(jié)點與數(shù)據(jù)庫服務器節(jié)點的通信延遲，客戶節(jié)點與數(shù)據(jù)庫服務器節(jié)點是同構節(jié)點(比如都是INTELX86/64體系結構)還是異構節(jié)點(客戶節(jié)點和服務節(jié)點分別是INTELX86/64 和IBMPower)。利用事件訂閱/提交機制實現(xiàn)數(shù)據(jù)庫加載后的自動重連以及故障后的重連，絕大多數(shù)應用程序都通過該種方式實現(xiàn)對實時數(shù)據(jù)庫的數(shù)據(jù)訪問。該類接口的調用示例如下所示，實時數(shù)據(jù)庫通常對應到文件系統(tǒng)中的多個文件。

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數(shù)據(jù)庫的連接

pconn=sophicdb::open(“sysnew”,“scada”,“scadamdl”,CS_OPEN,READ_OPEN,OPEN_ALL_PARTITION);

longclass_id= 30;

longnum=0;

//獲取表ID為30的表中對象數(shù)

num=pconn->get_lv_of_class(class_id);

2.2本地訪問接口

此類訪問接口提供給對數(shù)據(jù)訪問延時有很高要求的場景使用?？蛻舫绦蛑苯訉?shù)據(jù)庫數(shù)據(jù)文件映射到自身進程地址空間，對數(shù)據(jù)的訪問無需與數(shù)據(jù)庫服務程序進行通信，沒有進程間通信和網(wǎng)絡通信的開銷，保證了程序對數(shù)據(jù)訪問的低延時的要求。此類接口只支持數(shù)據(jù)讀操作，寫操作還交由數(shù)據(jù)庫服務程序執(zhí)行。該類接口的調用示例如下：

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數(shù)據(jù)庫的連接

pconn=sophicdb::open(“sysnew”,“scada”,“scadamdl”,CLIENT_OPEN,READ_OPEN,OPEN_ALL_PARTITION);

longclass_id= 30;

OBJIDid;

//獲取表ID為30的首對象的對象ID

ret=pconn->get_oid_by_sub(class_id,0,id);

2.3SQL訪問接口

大多數(shù)系統(tǒng)的后臺存儲是基于商用數(shù)據(jù)庫系統(tǒng)，系統(tǒng)中的很多應用是通過標準SQL接口實現(xiàn)數(shù)據(jù)存儲，SophicDB也提供SQL接口的訪問方式。第三方程序無需了解SophicDB的具體數(shù)據(jù)表示方式，通過SQL接口實現(xiàn)與SophicDB的數(shù)據(jù)交互，簡化了程序的開發(fā)周期。該類接口的調用示例如下：

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數(shù)據(jù)庫的連接

pconn=sophicdb::open(“sysnew”,“scada”,“scadamdl”,CS_OPEN,READ_OPEN,OPEN_ALL_PARTITION);

//查詢Substation表里的滿足條件的name、type字段數(shù)據(jù)集

c_rt_result_set*psets=pconn->exec_select(“selectname,typefromSubstationwherename= ‘testvalue’ ”,ret);

3　實　現(xiàn)

SophicDB實時數(shù)據(jù)庫運行在多節(jié)點分布式系統(tǒng)中。SophicDB同傳統(tǒng)商用數(shù)據(jù)庫的差異是單節(jié)點上可以同時運行多個數(shù)據(jù)庫實例，每個數(shù)據(jù)庫實例管理系統(tǒng)中的一部分數(shù)據(jù)；同時每個數(shù)據(jù)庫可以在多個節(jié)點上部署。其中某一個節(jié)點上的數(shù)據(jù)庫作為主本運行，其他節(jié)點上的同名數(shù)據(jù)庫作為副本運行，通過一致性策略實現(xiàn)主本和多個副本之間的數(shù)據(jù)同步。系統(tǒng)中的節(jié)點信息、每個節(jié)點分別運行哪些數(shù)據(jù)庫、每個數(shù)據(jù)庫在哪些節(jié)點上部署、每個數(shù)據(jù)庫的主本、副本所在節(jié)點和數(shù)據(jù)庫的運行狀況等系統(tǒng)信息存儲在被稱為MasterDB的數(shù)據(jù)庫中。SophicDB實時數(shù)據(jù)庫系統(tǒng)運行的最低要求是每個節(jié)點上至少運行MasterDB，其他數(shù)據(jù)庫可以靈活配置部署到任意節(jié)點上。

3.1數(shù)據(jù)庫服務器

每個數(shù)據(jù)庫實例都由一個獨立的服務程序管理，服務程序采用多線程架構實現(xiàn)對報文分發(fā)、數(shù)據(jù)訪問、連接管理、主副本同步、性能監(jiān)視和死鎖檢測等功能。主本服務程序和副本服務程序的最主要區(qū)別是處理寫操作事務的功能差異，下文以一個典型的主本服務程序為例進行詳細介紹。

數(shù)據(jù)庫服務程序主線程負責接收數(shù)據(jù)庫操作報文，根據(jù)報文類型分發(fā)給不同的線程進行處理，進程內部包括但不限于以下數(shù)據(jù)庫操作報文處理線程：

1) 多個數(shù)據(jù)庫查詢線程：處理客戶端的數(shù)據(jù)庫讀請求。

2) 增刪改線程：處理所有的數(shù)據(jù)庫寫請求。

3) 連接管理線程：客戶端的連接管理。

4) 雜項處理線程：數(shù)據(jù)庫內部的死鎖檢測、主副本數(shù)據(jù)一致性邏輯處理等。

3.2數(shù)據(jù)復制和同步協(xié)議

主備分布式數(shù)據(jù)庫需要考慮數(shù)據(jù)復制的問題，即保證數(shù)據(jù)庫主副本之間的數(shù)據(jù)同步。按照文獻[6]中定義的分布式數(shù)據(jù)庫事務執(zhí)行模型，數(shù)據(jù)庫中的每個數(shù)據(jù)項x在系統(tǒng)中存在一系列的拷貝x1,x2,…,xn。我們稱x為邏輯數(shù)據(jù)項，它的所有拷貝稱為物理數(shù)據(jù)項。系統(tǒng)需要提供主副本之間的數(shù)據(jù)復制協(xié)議，用戶的所有讀寫操作都針對邏輯數(shù)據(jù)項，然后由系統(tǒng)的數(shù)據(jù)復制控制協(xié)議負責將相應的數(shù)據(jù)讀寫操作映射到真實的物理數(shù)據(jù)項x1,x2,…,xn。系統(tǒng)給外部展現(xiàn)的是每個數(shù)據(jù)項只有單份拷貝。

分布式數(shù)據(jù)庫系統(tǒng)中有許多設計和因素決定了數(shù)據(jù)復制協(xié)議的設計，包括：

數(shù)據(jù)庫設計：分布式數(shù)據(jù)庫內的數(shù)據(jù)是全部復制還是部分復制到其他節(jié)點。部分復制模式指每個邏輯數(shù)據(jù)項的物理數(shù)據(jù)項數(shù)目是不固定的；而全部復制模式指所有數(shù)據(jù)庫運行實例包含了數(shù)據(jù)庫中的所有數(shù)據(jù)。SophicDB作為實時數(shù)據(jù)庫系統(tǒng)，在絕大多數(shù)場景下對實時性要求是非常高的，比如某些計算程序要求在幾秒鐘內完成對數(shù)據(jù)庫里所有數(shù)據(jù)的遍歷。如果將數(shù)據(jù)庫中的數(shù)據(jù)部分復制，數(shù)據(jù)分布存儲在不同的節(jié)點上，實時程序訪問數(shù)據(jù)的方式由本地訪問變?yōu)檫h程網(wǎng)絡訪問，可能由于網(wǎng)絡通信造成較大的網(wǎng)絡延遲，實時性的要求無法得到充分滿足。

SophicDB作為單主本多副本分布式數(shù)據(jù)庫，所有的數(shù)據(jù)更新操作首先發(fā)送到主本上執(zhí)行更新，在主本執(zhí)行成功后，通過同步日志的方式發(fā)送到各個副本上執(zhí)行，實現(xiàn)主副本的數(shù)據(jù)一致性。

通過同步日志的方式將數(shù)據(jù)更新傳輸?shù)礁鱾€副本，需要考慮同步日志可能出現(xiàn)丟失的情況。SophicDB通過在數(shù)據(jù)庫內部記錄版本信息來解決該問題，下文詳細描述SophicDB主副本數(shù)據(jù)一致性的算法。

在第二節(jié)中所述，每個SophicDB數(shù)據(jù)庫有1個或多個分區(qū)數(shù)據(jù)文件，每個分區(qū)文件都維護一個版本信息，同時整個數(shù)據(jù)庫維護一個版本信息。

主本數(shù)據(jù)庫處理數(shù)據(jù)更新請求的算法如下：

intsophicdb_master_write(x)

{

//主本數(shù)據(jù)庫服務器處理數(shù)據(jù)更新請求的邏輯

//分析數(shù)據(jù)集中數(shù)據(jù)分別存儲在哪些分區(qū)

vt=analyse_data(x);

//獲取當前數(shù)據(jù)庫版本信息

cur_version=get_cur_version_info();

//在主本數(shù)據(jù)庫中進行數(shù)據(jù)更新

update_data(x)；

//更新主本版本信息

updated_version=update_version(vt);

//組織同步日志，格式如下：

// 更新前的版本信息，更新后的版本信息，

// 數(shù)據(jù)更新內容，其他內容

send_update_log();}

副本數(shù)據(jù)庫負責接收主本數(shù)據(jù)庫發(fā)送過來的同步日志并執(zhí)行，從而完成主副本之間的數(shù)據(jù)同步。副本的數(shù)據(jù)更新算法如下：

intsophicdb_standby_write(log)

{

//副本數(shù)據(jù)庫服務器處理數(shù)據(jù)更新請求的邏輯

//解析同步日志

x=parse_log(log);

//分析數(shù)據(jù)集中數(shù)據(jù)分別存儲在哪些分區(qū)

vt=analyse_data(x);

//獲取本數(shù)據(jù)庫版本信息

cur_version=get_cur_version_info();

//與日志報文中的上次主本版本號比較

Match=check_version_with_master(x)；

if(match==true){//版本號匹配，對副本數(shù)據(jù)庫進行數(shù)據(jù)更新

Update_data(x);

//更新版本號,完成主副本之間的數(shù)據(jù)同步

updated_version=update_version(vt);

}

else

{

//版本不匹配，說明之前有同步日志丟失，需要處理數(shù)據(jù)不一致的情況

process_consistency();

}

}

副本收到同步日志并執(zhí)行上述的邏輯，完成數(shù)據(jù)同步。主副本之間通過比較版本號判斷是否有同步日志丟失的情況，如果發(fā)現(xiàn)有同步日志丟失情況，此時數(shù)據(jù)庫主副本之間處于不一致狀態(tài)，函數(shù)process_consistency負責處理主副本之間的數(shù)據(jù)不一致的恢復。該函數(shù)通過向主本請求重新發(fā)送丟失的同步日志集合，收到后重做并更新版本從而完成數(shù)據(jù)的一致性恢復。實時數(shù)據(jù)庫系統(tǒng)的運行特點：數(shù)據(jù)更新頻率高，對同一個對象可能重復更新。SophicDB也針對該特點重新設計了不同步情況下的同步日志集合的組織形式，通過合并同一個對象的多個更新操作，減少同步日志集合的數(shù)量以及傳輸?shù)礁北旧蠄?zhí)行的時間。

如上所述，數(shù)據(jù)更新首先在主本上執(zhí)行，然后通過同步日志的方式異步發(fā)送到各個副本上執(zhí)行。主本和副本之間理論上存在短時間間隔內的數(shù)據(jù)不一致情況，在實際千兆網(wǎng)運行系統(tǒng)中雖然只有毫秒級的時間間隔，在這段時間間隔內客戶程序如果從副本上讀取數(shù)據(jù)的值，有可能讀到舊的數(shù)據(jù)值。為了保證系統(tǒng)的串行執(zhí)行的語義[7]，SophicDB提供了專門的嚴格讀事務操作接口。對數(shù)據(jù)值的實時性要求很高的場景，客戶程序可以調用該接口，從而保證了串行化的要求。

4　優(yōu)　化

上一節(jié)描述了SophicDB的實現(xiàn)，我們還需要很多優(yōu)化工作才能使SophicDB達到用戶要求的高性能、高可用性和高可靠性。本節(jié)描述了SophicDB實現(xiàn)的其他部分，為了更好地強調這些優(yōu)化工作，我們將較深入描述細節(jié)。

4.1離線維護在線加載技術

SophicDB實時數(shù)據(jù)庫通常被用于實時監(jiān)控系統(tǒng)中，系統(tǒng)對實時性和持續(xù)運行能力要求很高，任何對數(shù)據(jù)庫的錯誤插入和刪除都可能對系統(tǒng)有致命的影響。這類系統(tǒng)中的某些關鍵數(shù)據(jù)庫，不允許進行在線插入和刪除操作。SophicDB具備獨特的離線維護在線加載的技術，即在離線庫中進行數(shù)據(jù)模型的維護，維護結束后驗證正確，通過在線加載技術加載到運行數(shù)據(jù)庫中，不影響運行庫的正常運行。

以一個典型的數(shù)據(jù)庫維護過程為例，一個監(jiān)控系統(tǒng)中通常包含多個監(jiān)控對象，且對象間可能存在層次包含關系，需要幾天時間進行數(shù)據(jù)庫建模。在此過程中由于數(shù)據(jù)不完整或者參數(shù)錯誤，只有所有參數(shù)輸入完畢并驗證正確后，整個監(jiān)控模型數(shù)據(jù)庫才能作為一個整體參與數(shù)據(jù)采集和分析。

傳統(tǒng)的數(shù)據(jù)庫使用如下兩種方式：

1) 應用程序重啟的離線裝載方式：數(shù)據(jù)維護是在一份獨立于運行庫的數(shù)據(jù)庫上進行維護，維護完成后需要停止運行庫，用維護好的庫覆蓋運行庫的數(shù)據(jù)文件后再重啟運行庫。該方式要求數(shù)據(jù)庫離線，時間持續(xù)數(shù)十秒，對系統(tǒng)持續(xù)運行造成了影響。

2) 在線直接修改：對修改的數(shù)據(jù)加入特殊標記，應用程序暫時不處理數(shù)據(jù)，最后所有維護完成時，將該標記統(tǒng)一去除。該方式的缺點是需要應用程序做特殊處理，處理復雜且不能優(yōu)化數(shù)據(jù)在內存中排列，性能會受很大影響。

SophicDB提出特有的離線維護在線加載的數(shù)據(jù)維護流程，數(shù)據(jù)區(qū)分靜態(tài)數(shù)據(jù)和動態(tài)數(shù)據(jù)：

第一步初始階段，數(shù)據(jù)在獨立于運行庫的維護庫上修改。此時，運行庫的數(shù)據(jù)模型是舊的，維護庫中的數(shù)據(jù)模型是新的。根據(jù)維護時的數(shù)據(jù)增刪情況，記錄數(shù)據(jù)庫的“增刪日志”。

第二步數(shù)據(jù)加載開始時，將維護庫的靜態(tài)數(shù)據(jù)載入內存，根據(jù)第一步記錄的“增刪日志”在運行庫中執(zhí)行日志，完成運行庫的數(shù)據(jù)模型的更新。

第三步系統(tǒng)平臺通過事件機制給客戶端發(fā)送數(shù)據(jù)裝載事件，通知客戶端重新建立與數(shù)據(jù)庫的連接。

第四步所有應用程序切換到新庫的連接。此時對舊的運行庫進行卸載，新庫成為運行庫。

該技術的優(yōu)點是：數(shù)據(jù)模型維護過程不影響在線運行，可以進行驗證和優(yōu)化；數(shù)據(jù)加載無需應用程序切為離線或重啟，數(shù)據(jù)庫可持續(xù)穩(wěn)定運行，數(shù)據(jù)加載對應用程序透明，不增加應用程序的復雜性。

4.2數(shù)據(jù)一致性策略優(yōu)化

如3.2節(jié)描述的，SophicDB通過多種版本號機制維護主副本數(shù)據(jù)庫中的數(shù)據(jù)一致性。如出現(xiàn)副本數(shù)據(jù)與主本數(shù)據(jù)不一致的情況或者在系統(tǒng)中增加部署數(shù)據(jù)庫的副本，此時都需要啟動數(shù)據(jù)一致性處理。

傳統(tǒng)的分布式數(shù)據(jù)庫的處理策略是主本記錄日志，副本通過請求主本傳輸同步日志并重做記錄日志來實現(xiàn)主副本之間的數(shù)據(jù)同步[8]。在實時數(shù)據(jù)庫運行系統(tǒng)中由于數(shù)據(jù)更新非常頻繁，每個數(shù)據(jù)庫實體通常每秒中有上千次的數(shù)據(jù)更新操作，系統(tǒng)長時間運行對同步日志的容量提出了很高的要求。SophicDB針對該問題有如下的優(yōu)化處理策略：

1) 系統(tǒng)將數(shù)據(jù)庫的內存鏡像回寫到后端磁盤存儲中，實現(xiàn)check-point功能，同時清空同步日志。觸發(fā)該動作的條件是由時間間隔和同步日志的最大容量等多個因素決定的。

2) 系統(tǒng)中某一副本發(fā)現(xiàn)數(shù)據(jù)跟主本數(shù)據(jù)庫中的數(shù)據(jù)不一致時，會主動發(fā)起數(shù)據(jù)一致性處理策略，發(fā)送本節(jié)點的數(shù)據(jù)庫版本信息給主本數(shù)據(jù)庫服務器。主本數(shù)據(jù)庫服務器收到副本的版本信息后同自身的數(shù)據(jù)庫版本信息比較，判斷哪些數(shù)據(jù)分區(qū)不一致，通過直接傳輸數(shù)據(jù)分區(qū)文件和一部分同步日志的方式實現(xiàn)主副本的數(shù)據(jù)一致性。通過合理劃分數(shù)據(jù)庫中的數(shù)據(jù)分區(qū)數(shù)目和分區(qū)大小，該種方式比直接傳輸大量的同步日志效率更高。

3) 考慮系統(tǒng)運行過程中存在網(wǎng)絡抖動的情況，導致副本與主本數(shù)據(jù)庫的數(shù)據(jù)不一致，即使啟動數(shù)據(jù)一致性策略處理仍然無法完成同步，短時間內可能啟動多次數(shù)據(jù)一致策略處理。如果不加以控制，在極端情況下可能進一步惡化網(wǎng)絡環(huán)境。SophicDB針對短時間內處理多次數(shù)據(jù)一致性策略失敗的情況引入了計數(shù)和保護措施：如果發(fā)現(xiàn)在固定時間周期內(比如10分鐘)連續(xù)進行幾次數(shù)據(jù)一致性策略都無法完成主副本數(shù)據(jù)一致性，會啟動數(shù)據(jù)庫自恢復功能，在本周期剩余時間內置本節(jié)點的數(shù)據(jù)庫為暫停狀態(tài)，等待進入下一周期再嘗試啟動數(shù)據(jù)一致性處理。通過實驗和實際運行系統(tǒng)的實踐證明該措施能夠大大縮短網(wǎng)絡擁塞的恢復時間。

5　性能評估

本節(jié)介紹SophicDB的性能評測模型以及性能測試結果。從測試結果可以看出，無論是單機數(shù)據(jù)訪問性能或多機數(shù)據(jù)訪問性能都很高。同時擴展性測試結果也表明，SophicDB具備很強的橫向擴展和縱向擴展能力。

5.1性能評測模型

性能模型覆蓋兩種場景：單機讀寫性能和多機讀寫性能。SophicDB實現(xiàn)了完備的服務程序和的數(shù)據(jù)接口。測試環(huán)境中節(jié)點的硬件配置是每個節(jié)點包含2顆IntelXeonX5650CPU，每顆CPU包含6核，12線程，內存大小為16GB；節(jié)點之間通過1GB網(wǎng)絡交換機連接，操作系統(tǒng)為RedHatLinux(內核2.6),每個數(shù)據(jù)庫容量為最大支持120萬個實時數(shù)據(jù)對象的數(shù)據(jù)更新。性能測試采用通用的客戶服務器訪問接口方式測試數(shù)據(jù)庫的性能和擴展性，同時測試通過采用批量提交方式來提高包含大量小數(shù)據(jù)量更新操作的應用程序的吞吐量。

5.2讀寫性能測試

圖1和圖2分別是單機環(huán)境下的數(shù)據(jù)查詢和更新的性能測試結果，區(qū)分兩種測試場景：本節(jié)點部署數(shù)據(jù)庫和本節(jié)點未部署數(shù)據(jù)庫需要遠程訪問。從測試結果看，本地部署數(shù)據(jù)庫，單機訪問的極限吞吐量可達百萬級別以上；異機訪問由于有網(wǎng)絡通信的延時，極限吞吐量可到30萬/秒。本機訪問一般是異機訪問的2～3倍。且從實驗結果看，由于達到網(wǎng)絡帶寬的上限，即使增加每次接口調用獲取對象的個數(shù)，總的吞吐量并沒有增加。

圖1　數(shù)據(jù)查詢性能

圖2 數(shù)據(jù)更新性能

數(shù)據(jù)更新測試，主本數(shù)據(jù)庫與應用程序位于同一個節(jié)點，無需通過網(wǎng)絡傳輸，更新操作通過進程間通信方式發(fā)送給數(shù)據(jù)庫服務器執(zhí)行，極限吞吐量可達60萬/秒以上。主本數(shù)據(jù)庫與應用程序不在同一個節(jié)點，更新操作首先需要通過網(wǎng)絡傳輸?shù)狡渌?jié)點，其他節(jié)點的數(shù)據(jù)庫服務器接收操作報文，執(zhí)行相應操作并返回操作結果給應用程序，極限吞吐量大致在20萬/秒左右。

5.3擴展性測試

上一節(jié)討論了單機單數(shù)據(jù)庫的數(shù)據(jù)查詢和更新性能。實際運行系統(tǒng)由于業(yè)務量、計算規(guī)模的增長要求對系統(tǒng)的處理能力進行擴展，通常情況下衡量系統(tǒng)可擴展性能力的好壞主要通過兩個方面：縱向和橫向。

縱向是指提高單節(jié)點的處理能力。SophicDB單節(jié)點縱向擴展實驗通過增加單節(jié)點上同時運行的實時數(shù)據(jù)庫實例數(shù)目，其中每個實時數(shù)據(jù)庫實例獨立運行，分別負責不同實時數(shù)據(jù)的采集和訪問。測試隨著數(shù)據(jù)庫實例數(shù)目的增加，整個節(jié)點的吞吐量的變化趨勢。如圖3所示，在單節(jié)點上分別同時運行1、2、3、4個數(shù)據(jù)庫實例，每個數(shù)據(jù)庫實例可以管理120萬點實時數(shù)據(jù)的數(shù)據(jù)采集。從實驗結果看，隨著數(shù)據(jù)庫實例數(shù)目的增加，整個單節(jié)點的數(shù)據(jù)更新吞吐量也隨之增加。在4個數(shù)據(jù)庫實例同時運行、每次更新512個對象的測試場景下，單節(jié)點的數(shù)據(jù)吞吐量達到近250萬/秒。實際測試結果表明，隨著數(shù)據(jù)庫實例數(shù)目的進一步增加，單機的吞吐量此時已經(jīng)沒有顯著的變化。原因是SophicDB內部客戶端與數(shù)據(jù)庫服務器之間是通過操作系統(tǒng)提供的進程間通信方式實現(xiàn)數(shù)據(jù)交互，系統(tǒng)的吞吐量受限于操作系統(tǒng)的進程間通信的效率。

圖3　縱向擴展測試

橫向指通過增加節(jié)點規(guī)模來提高系統(tǒng)的整體處理能力。SophicDB支持單節(jié)點運行多個數(shù)據(jù)庫實例，每個數(shù)據(jù)庫實例管理不同的數(shù)據(jù)對象。通過將不同的數(shù)據(jù)庫部署到不同節(jié)點上分別運行，理論上SophicDB支持任意節(jié)點數(shù)的擴展，且整體的系統(tǒng)數(shù)據(jù)更新吞吐量與整個系統(tǒng)中部署的數(shù)據(jù)庫數(shù)目成線性關系。但是考慮到MasterDB處理能力的極限以及由于系統(tǒng)中節(jié)點數(shù)目的增加可能導致網(wǎng)絡分區(qū)等影響系統(tǒng)正常運行的因素。如圖4所示，測試單節(jié)點、2節(jié)點、4節(jié)點、8節(jié)點的系統(tǒng)的數(shù)據(jù)更新吞吐量，每個節(jié)點上只運行一個數(shù)據(jù)庫主本，同時在另外一個節(jié)點上部署1個副本(副本冗余度為1)，每個節(jié)點上有2個數(shù)據(jù)庫實例同時運行(一個作為主本，一個作為副本)。從實驗結果看，系統(tǒng)吞吐量具備很好的線性加速比。

圖4　橫向擴展測試

前面的橫向測試中，每個節(jié)點部署不同的數(shù)據(jù)庫運行實例，還需要考慮多個節(jié)點上部署相同數(shù)據(jù)庫的測試場景。SophicDB數(shù)據(jù)庫作為一種分布式數(shù)據(jù)庫，同許多分布式存儲系統(tǒng)和分布式數(shù)據(jù)庫類似，采用一主本多副本的方式來提高系統(tǒng)的可用性和可靠性[9]。副本的管理機制需要解決2個關鍵問題：副本冗余度和副本一致性。副本冗余度的增加提高了數(shù)據(jù)的可用性和總的理論數(shù)據(jù)服務容量，也增加了整個系統(tǒng)的錯誤容忍能力，但也帶來了副本一致性。副本冗余度增加到一定程度后，由于數(shù)據(jù)庫之間同步報文量的增加，系統(tǒng)性能非但沒有增加，反而有所衰減且系統(tǒng)不穩(wěn)定性大大增加。該類測試需要考慮系統(tǒng)的讀寫負載的比例，以及系統(tǒng)的節(jié)點規(guī)模。在已經(jīng)運行的多個大型系統(tǒng)(節(jié)點數(shù)近百臺)中得出的結論是：針對數(shù)據(jù)更新比較頻繁的數(shù)據(jù)庫(每秒上千次更新)，副本冗余度為3～5之間，系統(tǒng)的穩(wěn)定性較好且能提供很好的數(shù)據(jù)服務。

6　結　語

本文介紹了一種高性能分布式實時數(shù)據(jù)庫系統(tǒng)SophicDB的設計和實現(xiàn)。和以往的分布式數(shù)據(jù)庫系統(tǒng)不同，它具有靈活配置的特點，它的設計特點決定了它具備很強的橫向擴展和縱向擴展能力，能滿足系統(tǒng)擴展的需求。從實驗結果看，系統(tǒng)的單機讀寫和多機讀寫效率是非常高的。目前該產品已在多個行業(yè)(能源、電力、鋼鐵、化工、軌道交通等)的多個大型實時數(shù)據(jù)管理系統(tǒng)中得到使用，包括網(wǎng)級電力調度管理系統(tǒng)、能源管理控制系統(tǒng)等，系統(tǒng)規(guī)模達到上百節(jié)點的數(shù)量級。未來的工作主要關注SophicDB性能的進一步擴展以及支持在跨越廣域網(wǎng)通信情況下的數(shù)據(jù)采集和存儲的研究。

[1]CaiS,GallinaB,Nystr?mD,etal.Trading-offdataconsistencyfortimelinessinreal-timedatabasesystems[C] //The27thEuromicroConferenceonReal-timeSystems.IEEE,2015:18-25.

[2]DewittJ,GrayJ.ParallelDatabaseSystems:Thefutureofhighperformancedatabasesystems[J].CommunicationsofTheACM,1992,35(6):85-98.

[3]DewittD,KatzRH,OlkenF,etal.Implementationtechniquesformainmemorydatabasesystems[C] //Proceedingsofthe1984ACMSIGMODinternationalconferenceonManagementofdata.ACM,1984:1-8.

[5]AbiteboulS,KanellakisPC.Objectidentityasaquerylanguageprimitive[J].JournaloftheACM,1998,45(5):798-842.

[6] ?zsuMT,ValduriezP.PrinciplesofdistributeddatabaseSystems[M].NewYork:Springer,2011:459-480.

[7]MansooriB,RosipkoB,ErhardKK,etal.DesignandimplementationofdisasterrecoveryandbusinesscontinuitysolutionforradiologyPACS[J].JournalofDigitalImaging,2014,27(1):19-25.

[8]CellaryW,GelenbeE,MorzyT.Concurrencycontrolindistributeddatabasesystems[M].Amsterdam:ElsevierScience,1988:221-226.

[9]KemmeB,SchiperA,RamalingamG,etal.Dagstuhlseminarreview:Consistencyindistributedsystems[J].ACMSIGACTNews,2014,45(1):67-89.

SOPHICDB:AHIGHPERFORMANCEDISTRIBUTEDREAL-TIMEDATABASE

CuiChangdongLuXinQianFengWangYanrong

(NanjingNARI-RELAYSElectricCo.,Ltd,Nanjing211102,Jiangsu,China)

SophicDBisahigh-performancedistributedreal-timedatabase,itisdesignedtoprocesshigh-speedreal-timedata.Thetimelinessofdatainreal-timesystemraisesveryhighrequirementsontheprocessingspeedofdatabasesystem,meanwhile,inordertoensurethedemandofhighavailability,itputsforwardtherequirementonreal-timedatabasetorunindistributedduty-standbymodeaswell.ThispaperexpatiatesondataorganisationmodeofSophicDBaswellasthedesignandimplementationofSophicDBsystem.Itisdemonstratedthroughtestdatagatheredfromsingleandmultiplecomputersaswellasactualoperationdatainacoupleofrunningsystemsthatthedatabasesystemhasthefeaturesofhighperformanceandhighscalability,itcanmeettherequirementofclusteringoperationwithhundrednodes.

Real-timedatabaseDistributedHighperformanceHighavailability

2015-08-12。崔昌棟，高工，主研領域：分布式系統(tǒng)。陸鑫，高工。錢鋒，高工。王艷蓉，高工。

TP

ADOI:10.3969/j.issn.1000-386x.2016.10.011