1海量数据管理系统的总体设计
1．1中央数据库
中央数据库部署在北京数据中心，采用Ora-cle/SqlServer群集，具体随方案选择而定。入库方式:通过人工或网络传输的方式获取数据库备份，经过导入程序入库;中央数据库存储项目的历史数据，其存储数据量比现场数据库要高出1～2个数量级。中央数据库要支持快速的数据查询、文件导入导出和Web访问，主要功能如下:将经过处理的实时数据写入现场数据库;支持数据的历史回放和离线分析;支持历史海量数据库的实时备份、清除和异地恢复;提供与评估软件平台的文件导出和数据接口;支持数据的后期操作和查询、编辑、更改［3］。各模块功能见表1，整体结构设计见图2。
1．2现场数据库
现场数据库针对具体项目，部署在现场监控中心，存储的是处理后的实时数据，要求定期备份、删除、异地恢复、更新。实时数据的特点是数据量大，数据入库较快。在设计现场数据库的时候，主要考虑如下:各个监测类型原始数据互不干扰;数据写入要求实时，考虑拥堵策略和故障恢复策略;灵活配置监测项、监测点的数据存储库表结构［4］;一定时期的历史数据在线回放和分析;单一监测类型数据存储(由于处理系统需要在较长时间内持续对采集数据进行处理，即使一种设备，持续累计多天的时候，数据量也会非常大，需要考虑以何种方式对多天数据进行组织)。现场数据库配置版本为SQLServer数据库。
1．3结构特征值数据库
本数据库主要存储桥梁结构采集数据的特征值，包括结构应变、加速度、索力等原始数据的最大值、最小值、平均值及方差等，特点是数据量相对较小，但数据计算频繁，使用频率较高。此数据库数据量小但关系较复杂，由于其入库频率相对于原始数据来说比较低，故采用较为简单的单库表结构。特征数据库配置版本为SQLServer数据库。
2海量数据库详细设计优化方案
2．1高速大容量数据存储与管理
通过对系统的总体评估，拟采用以下措施解决系统中大数据量的存储与管理问题。通过使用OracleＲAC(集群)模式加强底层数据库的处理性能;使用存储过程的方式来进一步加强数据库的交互性能;定期进行数据备份与清理，避免存储过多的低使用率数据(比如，数据库一般可以保持6个月到1年的数据，其它数据通过磁带库等存储介质将数据备份转移，减轻数据库的处理压力);对海量数据进行分区操作(例如针对按年份存取的数据，我们按年进行分区，不同的数据库有不同的分区方式，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志、索引存放于不同的分区下);建立广泛的索引［5］。对大表建立索引，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引。当插入表时，首先删除索引，插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引。要注意索引使用的时机，索引的填充因子和聚集、非聚集索引都要考虑。在对海量数据进行查询处理过程中，查询的SQL语句的性能对查询效率的影响是非常大的［6］。在对SQL语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表结构等都十分必要。
2．2数据库优化设计
桥梁结构桥梁索力数据量较大，由于实时数据处理系统平时的主要操作是桥梁索力的插入及数据查询，对数据的实时性及可恢复性要求不高，并不要求绝对的精度，允许一定的数据损失，对数据库的一致性、并发性及事物的隔离性要求不高，但对于大数据的吞吐量要求较高，故可将其定位为针对插入操作的OLTP系统及部分的OLAP系统［7］。所以考虑降低数据库的隔离级别和并发一致性控制以提高数据库性能，优先满足海量数据插入的吞吐量要求。Oracle版本的数据库优化设计如表2所示。
3系统应用项目及领域
本系统已经软件实现并应用到南京第4长江大桥的结构监测后期运营管理中，不但能较好的弥补新系统的数据处理与存储管理短板，还能完美融合到已经投入使用的大型结构监测系统中。同时，本系统力争建立一个基于结构监测的北京大型数据中心，中心数据库主要服务于建立全寿命期的数字化、信息化桥梁数据中心，用于桥梁结构海量历史数据的存储管理和挖掘分析，为日后的离线数据分析和历史状态追溯提供支持。同时，以中央数据库为基础和平台，根据结构的分析和报告编制需求，可以单项和并行的完成数据应用和管理。
作者：周兵 周锋 单位：中交公路规划设计院 桥梁结构安全监测事业部 河南中原水利水电工程集团有限公司
