Page 82 - 《软件学报》2021年第5期

1306 Journal of Software 软件学报 Vol.32, No.5, May 2021

浪费;另外,MySQL 为了支持这些能力,对整体性能做了很大折衷,所以使用 MySQL 存储从成本和技术运维角度
并不适合.
此外,MySQL 基于 B+树建立索引,该方式由于需要建立索引树,对写入性能有一定影响.但是 B+树却提供
了很高的查询性能,在第 1.3 节中提到了,LogView 是一种写多读少的场景,因此需要一种支持写入性能很高的
存储技术.但是查询效率的要求并不高,从查询的角度而言,MySQL 应对的场景同样不适合 LogView.
2.1.2 MongoDB
MongoDB [12] 是一个面向文档存储的数据库,可以将每条 LogView 日志数据以文档的形式存储在数据库中.
而实际每日上百 TB 的 LogView 日志数据量并不合适存放在单个 MongoDB,需要采取 MongoDB 集群存放海量
的数据.集群引入分片机制并存储数据的多份副本以保证数据的一致性 [13] ,而海量日志数据的多副本存储对存
储资源而言是一种浪费,所以该方式同样不适 LogView 的存储.
2.1.3 Key-Value
Key-Value 数据库是一种典型的 NoSQL 数据库,相关的数据库有 Memcached [14] 、Redis [15] 、TiKV [16] .此类
型数据库通过在内存中维护海量的键值对数据,在查询时直接使用 key 值即可,此类型的数据库将键值数据维
护在内存中,从而使得系统整体的读写性能非常高 [17] .以 Redis 为例,它具有非常高的读写速度,此外,它还支持数
据持久化到硬盘中、支持多种类型的数据、支持主从部署.如果选取 Redis 存储 LogView 日志数据,要求将日
志数据都维护在内存中,但是每条日志数据字节量是相对较大的,所以能够在维护内存中的 LogView 的数量必
然不会很大,从而无法将庞大数量的日志维护在内存中,所以同样也不适合于日志的存储.此外,分布式事务
Key-Value 数据库 TiKV 不仅能够支持分布式的数据存储,同样充分利用内存提供了很高的查询性能.但是 TiKV
是基于事务的数据库,强调数据的强一致性、数据的完整性等,在数据的写入时存在较多约束,写入性能受到影
响.TiKV 的设计中,会对数据会创建多份副本存放在集群的不同节点中,对于 LogView 的海量数据而言,集群中
存放多份数据副本会造成极大的存储开销.
综上,Key-Value 类型的存储方案同样不适合用于 LogView 日志的存储与查询.
2.1.4 ELK
ELK 是目前热门的日志 管理与分析 系统,ELK 是 Elasticsearch [18] 、Logstash [19] 、Kibana [20] 的简称,
Elasticsearch 是搜索与分析引擎,Logstash 负责日志数据的采集,Kibana 是基于 web 的图形界面.存储与查询主
要与 es(elasticsearch)有关,它可以快速地储存、搜索和分析海量数据.原则上,es 可以用来存储日志数据,但是
ELK 这种高度集成化的日志管理框架在后期的定制化需求中存在局限性,其中,仅有 es 能够用于 LogView 日志
的数据存储.但是由于 LogView 的数据特征,es 也仅能用于存储 LogView 的 id 与对应存储位置的索引信息.虽
然 es 集群能够提供非常高的查询性能,支持高效丰富的查询筛选功能,而前面提到 LogView 搜索条件比较简单
(根据 id 检索到具体的日志即可),并且日志数据量十分庞大,每天上百 TB 的存储量,es 不能十分高效存储这种
海量数据.通常,es 单个索引存储上限仅几 TB,每日需要创建上百个索引去存储这些日志,极大地增加了运维成
本,并且需要存储 2 周的 LogView 数据,则需要维持 10 余个 es 集群、上千个索引,运维开发难度极大.所以,单独
设计完整的存储与查询方案会有更好的可用性.
2.2 索引结构
在实现 LogView 日志的存储时,同时也需要考虑合适的索引结构用以提高查询的效率.在日志数据写入磁
盘后,需要充分利用日志的 id 标识、磁盘中的地址信息这两项数据来建立索引结构,这样在查询时即可直接根
据 id 值获取到该条日志在磁盘中的位置信息.
下面分析两种在数据库广泛应用的索引结构,并指出它们的优缺点.
2.2.1 Hash 索引结构
Hash 索引 [21] 是基于哈希表建立的,哈希表是由数组与链表两部分组成,如图 2 所示.