SophicDB:一個高性能分布式實時數據庫系統

崔昌棟　陸　鑫　錢　鋒　王艷蓉

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

?

SophicDB:一個高性能分布式實時數據庫系統

崔昌棟陸鑫錢鋒王艷蓉

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

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

實時數據庫分布式高性能高可用性

0　引　言

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

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

1　數據組織與存儲

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

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

structOBJID

{

unsignedlongsub;

unsignedshortcid;

unsignedshortno;

};

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

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

Structi_item

{

Unsignedlongsub;

Unsignedshortid;

Unsignedshortno;

};

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

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

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

數據區由若干數據塊組成，每個數據塊對應一張表的數據。

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

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

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

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

2　數據訪問接口

SophicDB數據庫同時提供了一整套豐富的數據修改和訪問的API函數。第三方系統需要與已經運行的SophicDB系統進行融合，對SophicDB數據庫中的數據進行訪問，開發人員可以調用接口實現數據訪問。

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

2.1客戶服務器訪問接口

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

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數據庫的連接

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

longclass_id= 30;

longnum=0;

//獲取表ID為30的表中對象數

num=pconn->get_lv_of_class(class_id);

2.2本地訪問接口

此類訪問接口提供給對數據訪問延時有很高要求的場景使用。客戶程序直接將數據庫數據文件映射到自身進程地址空間，對數據的訪問無需與數據庫服務程序進行通信，沒有進程間通信和網絡通信的開銷，保證了程序對數據訪問的低延時的要求。此類接口只支持數據讀操作，寫操作還交由數據庫服務程序執行。該類接口的調用示例如下：

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數據庫的連接

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訪問接口

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

sophic_db_connection*pconn=NULL;

longret=0;

//建立與scada/scadamdl數據庫的連接

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

//查詢Substation表里的滿足條件的name、type字段數據集

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

3　實　現

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

3.1數據庫服務器

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

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

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

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

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

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

3.2數據復制和同步協議

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

分布式數據庫系統中有許多設計和因素決定了數據復制協議的設計，包括：

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

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

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

在第二節中所述，每個SophicDB數據庫有1個或多個分區數據文件，每個分區文件都維護一個版本信息，同時整個數據庫維護一個版本信息。

主本數據庫處理數據更新請求的算法如下：

intsophicdb_master_write(x)

{

//主本數據庫服務器處理數據更新請求的邏輯

//分析數據集中數據分別存儲在哪些分區

vt=analyse_data(x);

//獲取當前數據庫版本信息

cur_version=get_cur_version_info();

//在主本數據庫中進行數據更新

update_data(x)；

//更新主本版本信息

updated_version=update_version(vt);

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

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

// 數據更新內容，其他內容

send_update_log();}

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

intsophicdb_standby_write(log)

{

//副本數據庫服務器處理數據更新請求的邏輯

//解析同步日志

x=parse_log(log);

//分析數據集中數據分別存儲在哪些分區

vt=analyse_data(x);

//獲取本數據庫版本信息

cur_version=get_cur_version_info();

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

Match=check_version_with_master(x)；

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

Update_data(x);

//更新版本號,完成主副本之間的數據同步

updated_version=update_version(vt);

}

else

{

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

process_consistency();

}

}

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

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

4　優　化

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

4.1離線維護在線加載技術

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

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

傳統的數據庫使用如下兩種方式：

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

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

SophicDB提出特有的離線維護在線加載的數據維護流程，數據區分靜態數據和動態數據：

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

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

第三步系統平臺通過事件機制給客戶端發送數據裝載事件，通知客戶端重新建立與數據庫的連接。

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

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

4.2數據一致性策略優化

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

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

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

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

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

5　性能評估

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

5.1性能評測模型

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

5.2讀寫性能測試

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

圖1　數據查詢性能

圖2 數據更新性能

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

5.3擴展性測試

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

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

圖3　縱向擴展測試

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

圖4　橫向擴展測試

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

6　結　語

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

[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。崔昌棟，高工，主研領域：分布式系統。陸鑫，高工。錢鋒，高工。王艷蓉，高工。

TP

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