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