崔昌棟　陸　鑫　錢(qián)　鋒　王艷蓉

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

?

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

崔昌棟陸鑫錢(qián)鋒王艷蓉

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

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

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

0　引　言

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

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

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

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

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

structOBJID

{

unsignedlongsub;

unsignedshortcid;

unsignedshortno;

};

其中sub表示對(duì)象對(duì)應(yīng)索引段內(nèi)的下標(biāo)，cid表示表的ID，no表示索引對(duì)象位置被重復(fù)使用的次數(shù)，支持對(duì)象刪除后的OBJID重復(fù)使用。

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

Structi_item

{

Unsignedlongsub;

Unsignedshortid;

Unsignedshortno;

};

一個(gè)索引塊的索引項(xiàng)分為兩類(lèi)：

其一，正被作為某個(gè)對(duì)象索引使用。通過(guò)索引項(xiàng)，可以直接定位對(duì)象。如上面OBJID結(jié)構(gòu)定義，OBJID中的sub定位到索引項(xiàng)，根據(jù)索引項(xiàng)就直接定位到對(duì)象數(shù)據(jù)。

其二，空閑項(xiàng)。當(dāng)向表中插入一個(gè)對(duì)象時(shí)，取得一個(gè)空閑索引項(xiàng)，基于該空閑索引項(xiàng)生成該對(duì)象的唯一標(biāo)識(shí)OBJID。索引塊中的所有空閑項(xiàng)通過(guò)一條先進(jìn)先出隊(duì)列組織，首尾指針在元數(shù)據(jù)區(qū)中維護(hù)。

數(shù)據(jù)區(qū)由若干數(shù)據(jù)塊組成，每個(gè)數(shù)據(jù)塊對(duì)應(yīng)一張表的數(shù)據(jù)。

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

1) 實(shí)際運(yùn)行系統(tǒng)中對(duì)數(shù)據(jù)的訪問(wèn)90%以上都是基于對(duì)象標(biāo)識(shí)方式訪問(wèn)數(shù)據(jù)，因此可通過(guò)在OBJID中存儲(chǔ)索引信息快速定位到數(shù)據(jù)對(duì)象。

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

從實(shí)際運(yùn)行系統(tǒng)的測(cè)試結(jié)果看，單機(jī)查詢的吞吐量接近100萬(wàn)/秒的數(shù)據(jù)訪問(wèn)，性能指標(biāo)大大領(lǐng)先于同類(lèi)產(chǎn)品。

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

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

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

2.1客戶服務(wù)器訪問(wèn)接口

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

sophic_db_connection*pconn=NULL;

longret=0;

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

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

longclass_id= 30;

longnum=0;

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

num=pconn->get_lv_of_class(class_id);

2.2本地訪問(wèn)接口

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

sophic_db_connection*pconn=NULL;

longret=0;

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

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

longclass_id= 30;

OBJIDid;

//獲取表ID為30的首對(duì)象的對(duì)象ID

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

2.3SQL訪問(wèn)接口

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

sophic_db_connection*pconn=NULL;

longret=0;

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

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　實(shí)　現(xiàn)

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

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

每個(gè)數(shù)據(jù)庫(kù)實(shí)例都由一個(gè)獨(dú)立的服務(wù)程序管理，服務(wù)程序采用多線程架構(gòu)實(shí)現(xiàn)對(duì)報(bào)文分發(fā)、數(shù)據(jù)訪問(wèn)、連接管理、主副本同步、性能監(jiān)視和死鎖檢測(cè)等功能。主本服務(wù)程序和副本服務(wù)程序的最主要區(qū)別是處理寫(xiě)操作事務(wù)的功能差異，下文以一個(gè)典型的主本服務(wù)程序?yàn)槔M(jìn)行詳細(xì)介紹。

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

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

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

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

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

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

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

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

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

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

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

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

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

intsophicdb_master_write(x)

{

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

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

vt=analyse_data(x);

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

cur_version=get_cur_version_info();

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

update_data(x)；

//更新主本版本信息

updated_version=update_version(vt);

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

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

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

send_update_log();}

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

intsophicdb_standby_write(log)

{

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

//解析同步日志

x=parse_log(log);

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

vt=analyse_data(x);

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

cur_version=get_cur_version_info();

//與日志報(bào)文中的上次主本版本號(hào)比較

Match=check_version_with_master(x)；

if(match==true){//版本號(hào)匹配，對(duì)副本數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)更新

Update_data(x);

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

updated_version=update_version(vt);

}

else

{

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

process_consistency();

}

}

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

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

4　優(yōu)　化

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

4.1離線維護(hù)在線加載技術(shù)

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

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

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

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

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

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

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

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

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

第四步所有應(yīng)用程序切換到新庫(kù)的連接。此時(shí)對(duì)舊的運(yùn)行庫(kù)進(jìn)行卸載，新庫(kù)成為運(yùn)行庫(kù)。

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

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

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

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

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

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

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

5　性能評(píng)估

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

5.1性能評(píng)測(cè)模型

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

5.2讀寫(xiě)性能測(cè)試

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

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

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

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

5.3擴(kuò)展性測(cè)試

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

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

圖3　縱向擴(kuò)展測(cè)試

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

圖4　橫向擴(kuò)展測(cè)試

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

6　結(jié)　語(yǔ)

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

[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。崔昌棟，高工，主研領(lǐng)域：分布式系統(tǒng)。陸鑫，高工。錢(qián)鋒，高工。王艷蓉，高工。

TP

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