-
气象部门内部众多业务系统的各自独立监控模式因监视数据难以共享,导致运维成本高、效率低。集约监控通过收集存储和分析挖掘所有业务环节的监视数据,实现综合业务的集中监控。通过集约监控,有助于综合把控业务运行情况、打通业务流程,结合上下游业务信息快速定位和解决问题,从而提高运维效率。但集约监控带来的是众多业务系统和业务流程环节产生的源源不断的业务运行信息,这些海量监视数据给监控系统的架构设计带来新的挑战,其中一个关键问题就是高效的监视数据存储服务设计,主要需求包括如下几点:
1)在每日监视数据的数据量达到数亿条、瞬时峰值达到数十万条的情况下,完成实时低延迟的数据处理存储,并提供关联性、统计性的秒级频度的高效查询和分析。
2)需要支撑基于复杂规则的监视数据查询,如需要将各个业务信息系统产生的日志信息进行上下游关联串接,这要求对监控信息的访问非常灵活。
3)监视数据的数据类型多样,各自特点和应用场景不同,如日志类数据主要是半结构化和非结构化的处理详细信息,数据之间需要进行比对和关联;性能指标类数据主要是结构化数据,有按时序读取的需要。
4)对业务系统专有监视数据存在独立存储的需求,要对数据实现一定的隔离和权限控制,提供云存储服务,支持监视数据的多租户使用。
传统关系型数据库已无法应对海量数据存储管理和服务的挑战,存储设计逐渐向非关系型数据库(not only structured query language,NoSQL)技术转移。NoSQL技术引入了灵活的无模式数据模型,支持水平扩展,是一种非关系型、分布式、不保证遵循原子性-一致性-隔离性-持久性(atomicity consistency isolation durability,ACID)原则的数据存储系统[1],可分为文档式存储、列式存储、键值式存储、对象式存储、图形式存储和可扩展标记语言存储。典型的NoSQL数据库包括BigTable[2]、Dynamo[3]、Cassandra[4]、MongoDB[5]、HBase[6]、Redis[7]等。根据CAP(consistency,availbility,paatition)原则,很多NoSQL数据库是通过牺牲查询和一致性保证来提供横向可伸缩性和比关系数据库更高的可用性。Abadi指出,在分区的情况下,有一个可用性一致性的权衡,设计要重点关注分片、复制、存储管理和查询处理[8]。
在海量监视数据存储领域,Bai[9]对基于Hbase和Elasticsearch的大日志数据实时搜索可行性进行了分析,实验证明,随着搜索更多的日志事件,搜索响应时间并不会线性增加。庄媛等[10]提出了一种基于WebService的多系统水利日志存储方法,采用HBase存储多系统水利日志。刘小俊等[11]充分考虑了外部需求变换,提出了结合数据安全和服务需求的副本量控制模型,采用双时间粒度预测文件流行度,使得存储数据库应对大规模访问具有优势。在具体NoSQL存储技术应用上,Berglund[12]针对Elasticsearch的分片选择设计开发了插件,对不同算法产生的分片的效果进行了评估。
针对海量业务监视数据存储管理和服务需求,本文对比分析了各种海量数据存储管理技术,设计和实现了一种海量监视数据云存储服务模型,实现对各种类型监视信息的存储管理,同时对数据存储服务的数据流程和服务接口封装进行了设计和说明,并对该模型实现后的应用效果进行了测试分析和评估。评估结果表明,该模型对管理海量监视数据具有预期效果。
-
监视数据来源主要包括:业务数据处理流程各环节产生的业务日志,业务系统应用程序产生的业务运行日志,服务器、存储、网络、安全设备等基础资源的运行性能指标、状态数据、事件数据。除此之外,基于以上原始监视数据,通过处理和分析计算生成的告警信息、统计指标等。以中国气象部门国家数据中心为例,其不同来源的监视数据及数据规模如表 1所示。
表 1 监视数据组成
Table 1. Composition of Monitoring Data
数据分类 说明 数据规模 日志数据 每分钟约500 000条,每条约400 B 增长7亿条/日 增长215GB/日 指标数据 每分钟约1 000 000个,每个指标约20 B 增长14亿条/日 增长30GB/日 状态数据 每分钟约10 000个状态数据,每个约40 B 增长0.28亿条/日 增长0.58 GB /日 告警数据 每日约50 000条,每条约400 B 增长5万条/日 增长20 MB /日 配置数据 共约100 000条,每条约300 B 约30 MB -
目前国内外较为主流的存储模型会用到典型的NoSQL数据库,如BigTable、Dynamo、Cassandra、MongoDB、HBase等。其缺点是:现有的一些模型较难在捕捉到等待时间和一致性之间作平衡。而本文存储架构设计在可用性和一致性之间进行权衡,综合应用了Elasticsearch、Cassandra、MongoDB等数据库集群实现对各类监视数据的存储(见图 1)。重点关注了分片、存储管理、查询处理和告警数据处理。本文云存储服务模型的主要特点有:
1)在存储模型的接入端,通过主备的负载均衡组件来对写入和查询服务请求进行均衡分配,以使各个存储服务节点能分摊高并发时的吞吐量;
2)为消减日志写入高峰的压力,设计了Kafka消息队列,对日志数据进行缓存;
3)配置数据因其动态变化多,需要存储附加文档,因此,采用无模式的文档型数据库技术MongoDB来存储;
4)由于告警数据变化莫测,在进行故障分析时需要与配置数据进行关联,采用MongoDB来存储。
-
索引存储技术用于实现监视数据中日志数据的高效存储和查询。索引存储技术起源于搜索引擎的存储技术。它通过索引来组织数据内容,将数据存储在一个或多个索引中,一个索引就像一个数据库,每个索引通过分片散布到分布式存储的多个节点。
本文存储模型采用的Elasticsearch就是一种基于索引的NoSQL数据库,它具备TB级数据的存储服务能力,通过在集群节点中进行自我分发,实现容错和水平扩展。
1)Elasticsearch存储原理
Elasticsearch中文档是一个基本的数据存储单元,一个文档类似关系数据中一行记录,同一类文档可以有不同的字段组合,可以支持更为灵活的数据存储结构。文档的元数据主要有索引(index)、类型(type)和文档ID,每个文档都属于一个索引,并通过索引来进行索引存储和查询定位。为便于管理和提升性能效率,一个索引内根据文档类型,设置不同的逻辑分区,其中具有一组共同字段的文档可定义同一个类型;同时一个索引会切分成不同分片,分布到不同的集群节点,实现分布式存储,每一个分片是一个实例,每一个分片有主分片和零个或多个副本分片,用于对分片进行冗余存储,以增加高可用性和提高性能。图 2给出了Elasticsearch中索引存储的分片及副本的组织情况。
2)Elasticsearch索引存储流程
当向Elasticsearch集群提交文档,处理节点会根据路由规则确定需要写入的分片,并把文档发给分片所在的节点,由所在节点完成入库后返回。对于分片同步,系统提供了同步和异步两种策略。异步有更好的写入性能,而同步则更注重一致性。Elasticsearch索引一个文档的过程如图 3所示。
3)Elasticsearch查询流程
Elasticsearch集群完成一次查询分成几个步骤,服务节点接受请求,根据请求的索引元数据信息选择可用的数据节点,完成路由选择;数据节点从对应的分片中完成数据,并返回匹配的文档ID和评分;服务节点根据各个数据节点的返回,合并结果并排序,向数据节点提取完整的文档数据,组成完整的结果返回客户端。如图 4所示。
-
Elasticsearch中的大部分操作都是基于索引来完成,索引及相关的分片、副本的设计是关键存储设计,需要根据数据特点和数据量来进行设计[4]。
在日志数据中,业务处理日志类数据与系统日志文件类数据之间相关程度不高,因此将这两类日志数据分开存储;同时日志数据具有较高的时效性,近期的日志是查询和分析的热点数据。因此,在设计索引时,将业务日志和系统日志分成两大类索引,并按日期分开建立索引。由于业务日志有一定的规范性要求和分类,每个业务日志索引内还可以进一步按照业务来分类型。
根据以上的日志数据索引设计,日志数据的索引规划实现如表 2所示,其中索引名由租户、业务分类标识、日期分区共同组成。
表 2 日志数据索引设计
Table 2. Design of Log Data Index
索引 日志类型 分片数量/个 分片大小/GB 副本数量/个 租户 业务分类 日期分区 tenantid application YYYY 业务 10 37 2 MMDD 日志 tenantid system YYYY 系统 6 22 2 MMDD 日志 -
分片路由能限定查询在指定分片上执行,是Elasticsearch应对高吞吐量的措施之一,路由设计能够把广播查询优化为确定的分片查询,能够很好地优化查询效率。
日志数据的分片路由设计可依据数据查询的主要场景。以气象资料处理为例,每种气象资料每个时次都会生成多个环节处理日志,资料类型和时次是其中关键的检索条件,因此分片路由围绕这两个字段设计。
实现上可将访问索引时的routing_key设置为资料类型和资料时次组合,这样相同资料、相同时次的数据保存在一个分片上,对routing_key进行哈希运算,并将哈希值对分片数取模,得到的结果就是制定的分片序号;在查询时也可以进行相同的运算来精确定位分片,提高查询速度。
-
指标类数据存储主要考虑快速读写性能。Cassandra是开源的分布式NoSQL数据库系统,与面向行的传统关系型数据库或键值存储的key-value数据库不同,Cassandra使用的是宽列存储模型,可以有最多20亿个列,每个列由一个column key标识,每个column key下对应若干value,具备100 kB级别的写入性能。本文提出的海量监视数据存储模型采用Cassandra作为监视数据中指标类数据的底层存储技术。
在指标数据存储设计上,一个指标由指标名、标签(一组多维信息)、时间戳、值等组成。随着不同时间点的数据的收集,形成一个时间相关的序列和一个指标的序列。
-
指标存储主要有两个表:指标索引表和指标数据表。充分利用宽列数据库的特点,一个rowkey可以保存21亿列数据,按照监控数据的毫秒精度保存,一个rowkey可以保存3周的指标数据。
1)指标索引表,rowkey为指标名,列名为该指标数据表的rowkey,值字段为空。
2)指标数据表,rowkey为指标名和一个为期3周的起始时间点,列名为指标数据对应的时间戳,值字段为指标值。
在以上模型中,指标表的rowkey是一个关键,一个指标表rowkey由指标名、起始时间片、标签组和指标数据值类型等4部分组成。
-
指标数据存在大量的时间戳,保存一个完整的时间戳需要4个字节,为了节约空间,在时间戳的存储上进行优化,采用了基准时间片加上偏移量的方式优化存储,每一个时间戳从4个字节下降为2个字节。
根据指标时间戳(T)计算时间片(t)和偏移量(d)值的公式如下:
$$ t = T - \left( {T\% 1814\;400\;000} \right) $$ (1) $$ d = T\% 1814\;400\;000 $$ (2) 其中,1 814 400 000为3周的毫秒数。读取时还原指标时间戳,即
$$ T = t + d $$ (3) 指标值压缩:指标值都是数值类型、浮点型和整型,对于浮点数,通过数据类型精度转换成对应的整型存储,整型数据采用分段存储规则,在数值为0×0的时候,无需存储空间,值小于0× 100时,用一个字节,值小于0×10 000时,用2个字节保存。
压缩存储对比:对于0值数据完全不存储,对于整数、大量的小整数,压缩比达到50%以上,节约了一半以上的存储空间。
-
宽列数据写入和查询实现如下:
1)写入。根据指标rowkey设计规则,系统需要根据指标、标签、时间戳计算对应的分区主键rowkey,并且判断该rowkey是否已存在,若不存在,则在指标索引表中新增,若存在,则根据指标偏移时间式(2)计算的时间偏移量,把数据写入rowkey。
2)查询。根据查询条件(指标名、时间段)从指标索引表中查询一组指标数据的rowkey,并根据查询条件中标签组筛选有效rowkey;根据rowkey从指标数据表中连续加载对应的指标数据,并根据汇聚的要求,计算数据返回。
-
存储模型需要提供监视数据访问服务,并进行存储服务接口封装。为了让外部系统比较便捷地提交监视数据,并及时得到数据处理的反馈信息,系统间需要实现松耦合,采用RESTful协议提供数据交互。在安全方面,采用Accesskey机制实现访问控制。
-
1)接口数据格式
数据格式采用JavaScript对象简谱(javascript object notation,JSON)格式,规范采集的业务日志数据格式包括表 3中各项字段内容,指标数据格式包括表 4中各项字段内容。
表 3 日志数据基本格式
Table 3. Basic Format of Log Data
字段 描述 备注 type 日志类型 用来标记是哪种业务的数据 occur_time 发生时间 精确到毫秒的时间戳 fields key-value结构的日志数据 例如“:fields”:{“DATA_TYPE”:”A.0032.P001.R001”“, SYSTEM”:”CTS”} 表 4 指标数据基本格式
Table 4. Basic Format of Index Data
字段 描述 备注 name 指标名称 例如:system.cpu.usage occur_time 发生时间 精确到毫秒的时间戳 tags key-value结构的日志标签 例如:“tags”:{“host”:”10.20.33.19”, “SYSTEM”:”CTS”} value 指标值 47.3 2)监视数据采集接口
业务日志数据和指标数据的采集接口类似,如表 5所示,区别在于两者的表述性状态转移(representational state transfer,Rest)接口路径不同,其中,日志采集接口支持批量数据采集,当提交批量数据时,body参数赋值为多个JSON格式的日志数组即可。
表 5 采集接口说明
Table 5. Description of Acquisition Interface
参数 值 意义 path /logs/push/ Rest接口路径(日志) /metric/push/ (指标) method POST Http的方法,POST/GET/HEAD等 accesskey 访问授权码 系统生成的授权码 body 日志内容 JSON格式数据内容 -
监视数据中蕴含业务运行信息,不仅可以用来展示业务运行状况,有些关键指标还可以驱动业务流程环节,有必要对监视数据和基于数据生成的监视信息提供查询服务。
标准的监视数据查询接口的封装如表 6所示,指标数据查询接口与此类似。
表 6 数据查询接口说明
Table 6. Description of Data Query Interface
参数 值 意义 path /logs/query/ Rest接口路径 method POST Http方法,POST/GET/HEAD等 accesskey 访问授权码 系统生成的接入授权码 body 查询条件 JSON格式的查询条件,例如:{“DATA_TIME”:”A.0032.P001.R001”} 查询DATA_TIME值为A.0032.P001.R001的日志 -
根据气象业务监视数据的数据量统计,目前数据日增量约245 GB,包括215 GB日志数据、30 GB指标数据等。根据业务需求,日志和指标数据在线存储6个月,汇聚后的指标数据在线存储5年,保留2份存储副本。考虑未来业务增长,预留50%的存储容量。存储量计算如下:
膨胀系数设为1.3,原始日志存储量为:
215 GB/日×180日×3×1.3/50%/1 024= 296 TB
压缩比为50%,则原始指标存储量为:
28 GB/日×180日×3×50%/50%/1 024= 14.8 TB
汇聚后指标存储量为:
2 GB/日×365日×5年×3副本/50%/1 024 = 21.4 TB
存储环境采用Elasticsearch和Cassandra集群部署,配置见表 7。在存储环境部署后,重点对海量日志和指标数据存储模型的应用效果、存储服务性能、水平扩展、容错性等多方面进行了测试评估,均达到预期效果,满足监控业务需求。
表 7 存储环境部署信息
Table 7. Information of Storage Environment Deployment
数据库名称 物理机数量/台 配置信息 Elasticsearch集群 12 CPU:16核,内存:128 GB,磁盘:4 TB×6 Cassandra集群 3 CPU:16核,内存:128 GB,磁盘:2 TB×6 -
日志数据存储采用Elasticsearch集群,共12个节点,在不同数据量写入时,数据存储耗时见图 5,同时也测试了相同配置下,Oracle集群的日降低。志数据存储耗时。
从图 5可以看出,Elasticsearch集群即使在实时存储亿级数据量的情况下,都可以达到快速持久的数据存储效率,随着数据量的增加,每秒仍稳定提供约8万条数据的存储能力,远高于关系型数据库的存储性能,Oracle的写入速率为每秒3万条左右。
指标数据存储采用Cassandra集群,共3个节点,在不同数据量写入时,数据存储耗时如图 6所示。可以看出,Cassandra集群对比传统关系型数据库Oracle,具有更快的写入速率,达到每秒约7万条数据的存储能力,Oracle的写入速率为每秒4万条左右。
-
在不同并发访问请求下,Elasticsearch集群的查询时效见图 7。可以看出,Elasticsearch集群在低于50次并发访问时,查询耗时低于1 s,300次并发时,查询耗时为4.2 s,满足日志数据查询业务需求,超过300次并发时,访问性能急剧降低。
在不同并发访问请求下,Cassandra集群的查询时效见图 8。可以看出,Cassandra集群在低于50次并发访问时,查询耗时约2 s,满足指标数据查询业务需求,超过150次并发时,访问性能急剧降低。
针对Elasticsearch集群和Cassandra集群在高并发访问时,数据库访问性能急剧降低的问题,本文通过集群节点的水平扩展,增加存储服务节点数量开展扩展前后的性能分析。测试结果表明,增加节点后,数据库的读写性能都有较大增速。未来可根据业务增长及服务需求,动态在线扩展集群的存储节点。
-
存储架构设计考虑了可扩展性,存储模型采用互联网微服务(MicroService)架构设计,可以提供方便快捷的组件扩展能力。在数据分片基础上,将原有12个节点Elasticsearch集群、3个节点Cassandra集群,各增加2个存储服务节点。水平扩展前后,数据库集群的存储服务性能变化见表 8~11。
表 8 日志数据库水平扩展存储性能对比
Table 8. Comparison of Horizontal Extended StoragePerformance for Log Database
数据量/万条 耗时对比/s 存储速度对比/(条·s-1) 增速/% 12节点 14节点 12节点 14节点 1 000 121 112 82 013 89 524 9 2 000 249 212 80 032 94 521 18 2 500 308 254 81 123 98 425 21 表 9 指标数据库水平扩展存储性能对比
Table 9. Comparison of Horizontal Extended Storage Performance for Indicator Databases
数据量/万条 耗时对比/s 存储速度对比/(条·s-1) 增速/% 3节点 5节点 3节点 5节点 1 000 140 81 71 238 123 456 73 2 000 286 163 69 892 122 699 75 2 500 331 187 75 502 133 689 77 表 10 日志数据库水平扩展服务性能对比
Table 10. Comparison of Horizontal Extended Storage Performance for Log Databases
并发数/次 耗时对比/s 12节点 14节点 增速/% 50 0.34 0.35 -3 150 1.23 1.09 13 300 4.20 3.50 20 表 11 指标数据库水平扩展服务性能对比
Table 11. Comparison of Horizontal Extended Storage Performance for Indicator Database
并发数/次 耗时对比/s 3节点 5节点 增速/% 50 2.14 1.76 22 150 9.31 5.45 71 300 46.75 31.35 49 -
分布式存储系统设计的一个重要指标就是系统的容错性,当数据库集群的某个节点发生故障时,仍然可以提供有效的数据读写服务,不会严重影响整体性能。
在存储模型的设计中,所有数据分片保留2份副本,为测试存储架构的容错性,将原有12个节点Elasticsearch集群、3个节点Cassandra集群,各关闭1个节点,在测试的24 h内数据库操作有效率无明显衰减。
-
为解决对海量监视数据高效管理的问题,本文分析了海量监视数据的组成及不同监视数据的特点,提出了监视数据云存储服务模型。综合应用Elasticsearch、Cassandra、MongoDB等数据库集群实现对监视数据的存储,并通过真实环境测试,说明所提模型比传统关系型数据库具有更好的读写性能,同时也测试了该模型的水平可扩展性和稳定性。目前,监视信息存储服务模型已应用到全国气象综合业务实时监控系统建设中,实现了有效数据支撑。
未来,本文还将对存储服务模型进行完善和优化,实现对海量历史监视数据的在线存储,建立面向不同分析挖掘服务需求的存储服务模型,构建监控运维大数据平台。
-
摘要: 集约化监控有助于全面把控业务信息系统运行情况与提升运维效率,已成为大型企事业部门业务监控的发展方向,但集约化监控带来海量监视数据的存储与服务挑战。以气象部门业务监视数据为例,在分析监视数据的特点及对比海量数据存储服务技术的基础上,设计和实现了海量监视数据云存储服务模型,主要通过时序数据存储技术和索引存储技术分别存储指标类和日志事件类监视数据,并实现存储优化。对该模型的应用效果测试分析表明, 所提海量监视数据云存储服务模型具有高效存储服务性能以及可扩展性稳定的特点。Abstract: Intensive monitoring is helpful to control the operational status of information systems and improv the efficiency of operation and maintenance, which has become the development direction of business monitoring of large-scale enterprises and departments. However, intensive monitoring brings about challenges in processing storage services for massive surveillance data. Taking an application in meteorological department business monitoring as an example, on the basis of analyzing the characteristics of monitoring data and comparing the technologies of massive data storage services, a massive surveillance data cloud storage service model is designed and implemented, it is capable of storing Indicator class and log event class monitoring data mainly through time series data storage and index storage technology, and able to achieve storage optimization. Application test results show that this massive surveillance data cloud storage service model has high efficiency, scalability and stability.
-
表 1 监视数据组成
Table 1. Composition of Monitoring Data
数据分类 说明 数据规模 日志数据 每分钟约500 000条,每条约400 B 增长7亿条/日 增长215GB/日 指标数据 每分钟约1 000 000个,每个指标约20 B 增长14亿条/日 增长30GB/日 状态数据 每分钟约10 000个状态数据,每个约40 B 增长0.28亿条/日 增长0.58 GB /日 告警数据 每日约50 000条,每条约400 B 增长5万条/日 增长20 MB /日 配置数据 共约100 000条,每条约300 B 约30 MB 表 2 日志数据索引设计
Table 2. Design of Log Data Index
索引 日志类型 分片数量/个 分片大小/GB 副本数量/个 租户 业务分类 日期分区 tenantid application YYYY 业务 10 37 2 MMDD 日志 tenantid system YYYY 系统 6 22 2 MMDD 日志 表 3 日志数据基本格式
Table 3. Basic Format of Log Data
字段 描述 备注 type 日志类型 用来标记是哪种业务的数据 occur_time 发生时间 精确到毫秒的时间戳 fields key-value结构的日志数据 例如“:fields”:{“DATA_TYPE”:”A.0032.P001.R001”“, SYSTEM”:”CTS”} 表 4 指标数据基本格式
Table 4. Basic Format of Index Data
字段 描述 备注 name 指标名称 例如:system.cpu.usage occur_time 发生时间 精确到毫秒的时间戳 tags key-value结构的日志标签 例如:“tags”:{“host”:”10.20.33.19”, “SYSTEM”:”CTS”} value 指标值 47.3 表 5 采集接口说明
Table 5. Description of Acquisition Interface
参数 值 意义 path /logs/push/ Rest接口路径(日志) /metric/push/ (指标) method POST Http的方法,POST/GET/HEAD等 accesskey 访问授权码 系统生成的授权码 body 日志内容 JSON格式数据内容 表 6 数据查询接口说明
Table 6. Description of Data Query Interface
参数 值 意义 path /logs/query/ Rest接口路径 method POST Http方法,POST/GET/HEAD等 accesskey 访问授权码 系统生成的接入授权码 body 查询条件 JSON格式的查询条件,例如:{“DATA_TIME”:”A.0032.P001.R001”} 查询DATA_TIME值为A.0032.P001.R001的日志 表 7 存储环境部署信息
Table 7. Information of Storage Environment Deployment
数据库名称 物理机数量/台 配置信息 Elasticsearch集群 12 CPU:16核,内存:128 GB,磁盘:4 TB×6 Cassandra集群 3 CPU:16核,内存:128 GB,磁盘:2 TB×6 表 8 日志数据库水平扩展存储性能对比
Table 8. Comparison of Horizontal Extended StoragePerformance for Log Database
数据量/万条 耗时对比/s 存储速度对比/(条·s-1) 增速/% 12节点 14节点 12节点 14节点 1 000 121 112 82 013 89 524 9 2 000 249 212 80 032 94 521 18 2 500 308 254 81 123 98 425 21 表 9 指标数据库水平扩展存储性能对比
Table 9. Comparison of Horizontal Extended Storage Performance for Indicator Databases
数据量/万条 耗时对比/s 存储速度对比/(条·s-1) 增速/% 3节点 5节点 3节点 5节点 1 000 140 81 71 238 123 456 73 2 000 286 163 69 892 122 699 75 2 500 331 187 75 502 133 689 77 表 10 日志数据库水平扩展服务性能对比
Table 10. Comparison of Horizontal Extended Storage Performance for Log Databases
并发数/次 耗时对比/s 12节点 14节点 增速/% 50 0.34 0.35 -3 150 1.23 1.09 13 300 4.20 3.50 20 表 11 指标数据库水平扩展服务性能对比
Table 11. Comparison of Horizontal Extended Storage Performance for Indicator Database
并发数/次 耗时对比/s 3节点 5节点 增速/% 50 2.14 1.76 22 150 9.31 5.45 71 300 46.75 31.35 49 -
[1] Sadalage P J, Fowler M. NoSQL Distilled:A Brief Guide to the Emerging World of Polyglot Persistence[M]. Massachusetts:Addison-Wesley Professional, 2016 [2] Chang F, Dean J, Ghemawat S, et al. Bigtable:A Distributed Storage System for Structured Data[J]. ACM Transactions on Computer Systems, 2008, 26(2):1-26 http://d.old.wanfangdata.com.cn/Periodical/jsjgcysj201005061 [3] Decandia G, Hastorun D, Jampani M, et al. Dynamo: Amazon's Highly Available Key-value Store [C]. ACM Sigops Symposium on Operating Systems Principles, Washington, USA, 2007 [4] Lakshman A, Malik P. Cassandra:A Decentralized Structured Storage System[J]. ACM Sigops Operating Systems Review, 2009, 44(2):35-40 http://d.old.wanfangdata.com.cn/Periodical/jsjkx201106045 [5] 吕林.基于MongoDB的应用平台的研究与实现[D].北京: 北京邮电大学, 2015 Lü Lin. Research and Implementation of Application Platform Based on MongoDB[D]. Beijing: Beijing University of Posts and Telecommunications, 2015 [6] 杨寒冰, 赵龙, 贾金原. HBase数据库迁移工具的设计与实现[J].计算机科学与探索, 2013, 7(3):236-246 http://d.old.wanfangdata.com.cn/Periodical/jsjkxyts201303007 Yang Hanbing, Zhao Long, Jia Jinyuan. Design and Realization of HBase Migration Tool[J]. Journal of Frontiers of Computer Science & Technology, 2013, 7(3):236-246 http://d.old.wanfangdata.com.cn/Periodical/jsjkxyts201303007 [7] 朱进, 胡斌, 邵华, 等.基于内存数据库Redis的轻量级矢量地理数据组织[J].地球信息科学学报, 2014, 16(2):165-172 http://d.old.wanfangdata.com.cn/Periodical/dqxxkx201402003 Zhu Jin, Hu Bin, Shao Hua, et al. Research of Lightweight Vector Geographic Data Management Based on Main Memory Database Redis[J]. Journal of Geo-information Science, 2014, 16(2):165-172 http://d.old.wanfangdata.com.cn/Periodical/dqxxkx201402003 [8] Abadi D J. Consistency Tradeoffs in Modern Distribu ted Database System Design:CAP is Only Part of the Story[J]. Computer, 2012, 45(2):37-42 doi: 10.1109/MC.2012.33 [9] Bai J. Feasibility Analysis of Big Log Data Real Time Search Based on Hbase and Elasticsearch[C]. Ninth International Conference on Natural Computation, Shenyang, China, 2014 [10] 庄媛, 张鹏程, 李雯睿, 等.一种环境因素敏感的WebService QoS监控方法[J].软件学报, 2016, 27(8):1 978-1 992 http://d.old.wanfangdata.com.cn/Periodical/rjxb201608008 Zhuang Yuan, Zhang Pengcheng, Li Wenrui, et al. Web Service QoS Monitoring Approach Sensing to Environmental Factors[J]. Journal of Software, 2016, 27(8):1 978-1 992 http://d.old.wanfangdata.com.cn/Periodical/rjxb201608008 [11] 刘小俊, 胡志华, 潘少明.智慧城市云存储系统中的副本量控制策略研究[J].武汉大学学报·信息科学版, 2016, 41(9):1 205-1 210 doi: 10.13203/j.whugis20140440 Liu Xiaojun, Hu Zhihua, Pan Shaoming. Control Strategy for the Number of Replica in Smart City Cloud Stroage System[J]. Gematics and Information Science of Wuhan University, 2016, 41(9): 1 205-1 210 doi: 10.13203/j.whugis20140440 [12] Berglund P. Shard Selection in Distributed Collaborative Search Engines a Design, Implementation and Evaluation of Shard Selection in Elasticsearch[J]. Fundamental Informaticae, 2014, 26(1):59-80 http://cn.bing.com/academic/profile?id=217579dd6e0cae43fa5c7a9c477a75c7&encoded=0&v=paper_preview&mkt=zh-cn -