基于TimesTen内存数据库提升股道现车同步应用性能的研究与测试

王凤琳

（北京经纬信息技术有限公司，北京 100081）

铁路运输信息集成平台的目标是实现列车、车辆、货物、机车、机车乘务员等信息的数据集中与共享，并实时掌握与动态追踪其位置和状态、推算与预测其变化趋势，为实现精确调度指挥奠定基础，同时为货运电子商务和货运组织改革提供必要的技术支撑。

运输信息集成平台建设过程中，中国铁路总公司级（简称：总公司级）实时掌握各车站股道现车情况，以便精确组织运输生产，是一项重要且迫切的需求。而铁路运输当前的实际情况是，股道现车数据除本车站外，仅由车站所在铁路局实时掌握，铁路总公司调度部仅能通过各个铁路局的现车系统查询相关信息，无法从全路角度掌控所有在站车辆的位置、数量及空重状态，故如何在总公司级实时掌握并管理全路约60万辆股道现车，是运输信息集成平台建设中亟需解决的问题。

本文旨在分析当前股道现车同步应用存在的主要问题的基础上，针对新的内存数据库技术进行了学习与研究，并将其运用于股道现车同步应用测试，为应用性能的提升提供了科学依据和有力支撑。

1 主要问题及解决思路

1.1 主要问题

中国铁路总公司（简称：总公司）运输信息集成平台股道现车同步应用运行在Unix操作系统，使用Oracle数据库，运用Pro*C编程语言，实现车站股道现车数据同步至总公司。全路股道现车数据庞大且实时变化，基于当前的设备能力和技术水平，很难在总公司级做到真正意义上的同步，即每一辆车的变化状态都实时反映在总公司运输信息集成平台中。目前采用的方式是：利用MQ消息传输机制，各铁路局每30 min按车站为单位以XML文件的形式上报局管内车站股道现车数据至总公司集成平台，总公司接收文件并解析入数据库，以数据共享方式向相关应用提供数据支持。

全路已实施车站系统的车站约6 000多个，均需每30 min上报本站当前股道现车数据，具体包括车号、到达时间、到达股道、空重、始发站、终到站、货物、车辆状态等信息[1]；对于当前时间没有任何车辆的车站，仍需上报股道现车报告，以便在总公司股道现车库中清除上一时间点的车辆信息。频繁的删除和插入操作，使得总公司股道现车库压力较大，执行效率较低。为此，根据各铁路局报告数量，经过估算测试，优化为6个进程并行处理，满足30 min同步的要求，每处理30 min数据需大约12 min左右，即总公司数据与车站实际情况之间存在约40 min的时间差。时间差使得总公司与铁路局数据存在较大的不一致性，而提高两级数据一致性的首要问题是缩短数据同步时间间隔，提升数据处理能力。

1.2 解决思路

内存数据库技术具有更快的数据读取速度，能够大大提升数据处理效率，且该项技术在铁路互联网余票查询[2]、铁路货车追踪[3]等应用中已取得一定成效。经过对目前主流的各类内存数据库产品进行对比和分析，基于与既有应用最大的兼容性，总公司运输信息集成平台股道现车同步应用选取了Oracle TimesTen内存数据库，进行了数据处理性能和高可用性方面的研究与测试。

2 Oracle TimesTen内存数据库简介

Oracle内存数据库TimesTen 是一款针对内存进行了优化的关系型数据库，它为应用程序提供了即时响应性和非常高的吞吐量。Oracle TimesTen作为高速缓存或嵌入式数据库部署在应用程序中，利用标准SQL 接口对完全位于物理内存中的数据存储进行操作，对于大规模的查询应用非常有好处[4]。

目前，Oracle TimesTen在全球的客户包括Dell[5]、美国美林银行[6]、上海海关[7]等，拥有如此众多的客户群并得到业界的广泛认可，主要得益于以下几项优势[8]：

（1）能够和Oracle数据库做无缝集成，数据可以在TimesTen和Oracle直接实现实时双向流动；

（2）TimesTen可以做成多节点并行提供服务的模式，数据在多个TimesTen之间直接实现实时或非实时的传输，进一步提高了系统的扩展性和可靠性；

（3）TimesTen是符合RDBMS标准的独立内存数据库服务，支持SQL92，可运行在Linux、Windows、AIX等操作系统平台上，使用Java、.NET、 C、 C++、 Pro*C 等语言进行应用开发。

基于以上几点，并结合总公司运输信息集成平台股道现车同步应用的特点，运行于Unix平台、使用Oracle数据库、应用Pro*C语言、业务逻辑相对简单但要求快速响应，Oracle TimesTen内存数据库是合适的选择。

3 Oracle TimesTen测试过程

3.1 测试目的

本次测试的主要目的是验证固定场景下内存数据库在数据处理上的效率，为评估内存数据库技术在运输信息集成平台的使用提供依据。

3.2 测试环境及步骤

3.2.1 软硬件环境配置

测试环境的软硬件配置情况如表1所示，两台主机分别安装TimesTen11，建立Active Standby Pair主从复制关系，使用Oracle Cluster Ware作为集群管理软件，监控TimesTen及错误切换、监控应用和文件系统及应用和文件系统切换。系统逻辑架构如图1所示。测试文件位于/u01/testdata目录，TimesTen软件安装于/home/oracle/TimesTen/tt1122目录，测试程序和脚本位于/home/oracle/poc目录。

3.2.2 测试数据说明

表1 软硬件环境配置

图1 系统逻辑架构

测试所用数据是实际业务数据文件的备份，为XML格式文件，描述各铁路局上报的车站股道现车情况，一个车站对应一个或多个文件，没有现车的车站上报一个只有文件头没有文件内容的空文件。为便于测试，将备份文件整理为数据集合A和数据集合B：数据集A是从随机备份的实际业务数据的全集中经过筛选后，模拟全路各站每30 min上报的一轮数据的集合，并比照目前股道现车同步应用的实际情况，按铁路局分6个目录保存，分别为gdcl_1、gdcl_2、……、gdcl_6；数据集B是在A的基础上，按铁路局将文件分为12个目录保存，分别为gdcl_1、gdcl_2、……、gdcl_12。同时，为了保证测试的准确性，以股道现车实际生产数据表BGDCARA中的数据作为测试基础数据。

表2 测试数据集基本情况描述

测试数据集A和B中文件数量和占用空间大小描述如表2所示。铁路局上报的股道车辆文件格式和股道车辆数据表结构，如图2和图3所示。

图2 股道现车文件格式

图3 股道现车数据表结构

3.2.3 测试步骤

（1）将Oracle数据库中基础数据表的数据导入到内存数据库表BGDCARA中。

（2）应用按时序分别读取各文件夹中的报文，进行XML报文解析，并更新内存数据库表BGDCARA。处理过程需保留日志备查。

（3）处理某一车站报告时，需删除数据库表中该车站对应的所有车辆，解析文件中每一辆车的详细信息，插入到内存数据库表BGDCARA中。

（4）正确处理完毕的文件直接删除；如果文件校验有错，将该文件保存到错误文件目录。

（5）测试完毕，将内存数据库数据表BGDCARA的数据导出到Oracle数据库中的数据表。

3.3 测试场景及结果

3.3.1 性能测试

性能测试是为了验证系统是否能够达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的[9]。本测试仅涉及dp29-08一台主机，基于数据集A和B，以OCI和Java两种方式分别进行性能测试，以验证Oracle TimesTen数据处理能力。

（1）测试准备

a.连接TimesTen数据库gdcl1，比照集成平台生产环境中股道车辆Oracle数据表结构和索引在TimesTen数据库中新建数据表BGDCARA。

b.将Oracle数据库中的数据导入TimesTen，记录表行数。数据成功通过TimesTen缓存特性从Oracle数据库导入，记录数为626 610。

c.在/u01/testdata目录下新建子目录A和B，解压测试数据集A到/u01/testdata/A目录下，解压测试数据集B到/u01/testdata/B目录下。

（2）OCI测试

a. A数据集测试。比照既有生产环境下的模式，启动6个Pro*C进程分别同时处理数据集6个文件夹中的数据，以最后完成的进程运行时间作为总执行时间。为了保证测试的准确性，共进行10轮测试，记录每次运行时间，并计算一轮平均运行时间为16 s。登录TimesTen gdcl1数据库，查看数据表BGDCARA中的数据及记录数。数据表总记录数为620 356，各字段显示正确。/u01/testdata/A目录下正确处理完毕的XML文件成功删除，解析校验不正确的文件共4个，被挪至/u01/testdata/errdata目录下。

b. B数据集测试。与既有生产环境下的模式不同，测试启动12个Pro*C进程分别同时处理数据集12个文件夹中的数据，以最后完成的进程运行时间作为总执行时间。为了保证测试的准确性，共进行10轮测试，记录每次运行时间，并计算一轮平均运行时间为18 s。登录TimesTen gdcl1数据库，查看数据表BGDCARA中的数据及记录数。数据表总记录数为620 356，各字段显示正确。/u01/testdata/B目录下正确处理完毕的XML文件成功删除，解析校验不正确的文件共4个，被挪至/u01/testdata/errdata目录下。

（3）Java测试

a. A数据集测试。比照既有生产环境下的模式，启动6个Java进程分别同时处理数据集6个文件夹中的数据，以最后完成的进程运行时间作为总执行时间。为了保证测试的准确性，共进行10轮测试，记录每次运行时间，并计算一轮平均运行时间为22 s。登录TimesTen gdcl1数据库，查看数据表BGDCARA中的数据及记录数。数据表总记录数为620 356，各字段显示正确。/u01/testdata/A目录下正确处理完毕的XML文件成功删除，解析校验不正确的文件共4个，被挪至/u01/testdata/errdata目录下。

b. B数据集测试。与既有生产环境下的模式不同，测试启动12个Java进程分别同时处理数据集12个文件夹中的数据，以最后完成的进程的运行时间作为总执行时间。为了保证测试的准确性，共进行10轮测试，记录每次运行时间，并计算一轮平均运行时间为24 s。登录TimesTen gdcl1数据库，查看数据表BGDCARA中的数据及记录数。数据表总记录数为620 356，各字段显示正确。/u01/testdata/B目录下正确处理完毕的XML文件成功删除，解析校验不正确的文件共4个，被挪至/u01/testdata/errdata目录下。

（4）测试结果

性能测试结果如表3和表4所示。表3是测试过程中执行DELETE和INSERT操作的次数，表4汇总了各类测试方式的处理效率。从两个表中可以看出，OCI方式数据处理效率明显高于Java方式；频繁的DELETE与INSERT操作并未对数据处理效率有明显影响；当并行进程数由6调整到12时，OCI与Java 方式的处理时间均有所增加，这说明并行度也有一个平衡点，并非并发度越高越好。

3.3.2 高可用性测试

本文高可用性测试采用主从方式，即主机工作，备机处于监控准备状况，当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决[10]。

表3 数据表操作统计表

表4 处理效率汇总表

本测试涉及dp29-08和dp29-07两台主机，数据库为gdcl1（dp29-08）和gdcl2（dp29-07），目的是为验证TimesTen对业务连续性的支持。

（1）测试准备

a.清空dp29-08主机gdcl1数据库BGDCARA数据表中的测试数据；在主机dp29-07 gdcl2数据库中新建数据表BGDCARA。

b.从Oracle数据库导入数据到gdcl1，记录数为626 610，登录gdcl2可以看到相同记录数，确认两个数据库之间数据复制正常。

c.为便于测试，将6个文件夹中的数据汇总到一个文件夹中，以OIC方式启动一个应用进程处理数据。

（2）高可用性测试之模拟内存数据库故障

a.启动应用，默认连接位于主机dp29-08的数据库gdcl1，进程运行正常，实时往数据表中写入记录。模拟内存数据库故障，手动Kill数据库守护进程，应用立即检测到数据库错误，并成功切换至gdcl2数据库继续处理文件、插入数据。

b.文件全部处理完成后，检查两数据库表中记录数。gdcl2数据库表中记录数为620 356，gdcl1数据库表中记录数为379 703，为数据库gdcl1故障之前应用写入数据表的记录数。

c.重新启动数据库gdcl1，复制关系自动建立，最终gdcl1中的数据由379 703变为620 356，两数据库表数据完全一致。

（3）高可用性测试之模拟主机故障

a.启动应用，默认连接位于主机dp29-08的数据库gdcl1，进程运行正常，实时往数据表中写入记录。模拟主机dp29-08故障，reboot重启主机，应用停顿约几十秒后检测到错误，并成功切换到gdcl2数据库继续处理文件、插入数据。

b.文件全部处理完成后，检查两数据库表中记录数。gdcl2数据库表中记录数为620 356，gdcl1数据库表中记录数为268 915，为主机dp29-08重启之前应用写入数据表的记录数。

c.主机dp29-08重启后，启动数据库gdcl1，复制关系自动建立，最终gdcl1中的数据由268 915变为620 356，两数据库表数据完全一致。

（4）测试结果

从表5汇总情况可知，无论数据库故障还是主机故障，应用均无中断，都可无缝切换到备机数据库，继续处理数据，并在故障恢复后，主备机数据库可自动恢复复制关系，保证主备机数据库表数据的完整性和一致性。该测试证明了Oracle TimesTen具有很好的高可用性，为业务处理的连续性提供了有力的保证。

表5 高可用性测试结果汇总表

4 结束语

通过本次测试，可以看到使用Oracle TimesTen内存数据库进行铁路局股道现车数据同步的处理效率比Oracle数据库本身有了质的飞跃，处理一轮数据所需时间从12 min缩短到16 s，提升了约45倍，完全能够实现在总公司实时掌握车站车辆的现场情况。TimesTen的高可用性，更有力保证了业务处理的连续性和数据的完整性。同时，由于TimesTen支持SQL92并支持 Pro*C语言进行应用开发，使得本次OCI测试应用程序修改量不大，仅做了部分适应性修改，程序主体基本沿用目前生产环境中的既有应用，便于开发运维人员学习使用。

因此，使用Oracle TimesTen内存数据库提升股道现车同步应用的性能是可行的解决方案。