论文部分内容阅读
摘 要 ApacheSolr是一个基于ApacheLucene的开源企业搜索服务器。Apache SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作为集群的配置信息中心。文章在海量日志索引信息存储和查询方面进行了探索，证明了在相关优化策略下Solr Cloud具备了优秀的查询性能。
关键词 Solr；SolrCloud；日志信息查询；大数据；性能优化；集群；分片
中图分类号：TP393 文献标识码：A 文章编号：1671-7597（2014）03-0037-03
随着传统互联网和移动互联网的持续发展，网络带给我们的是不断增长的各种不同价值信息，然而如何在信息海洋中快速检索到有价值信息，对于我们来讲至关重要。目前一些搜索公司在公共互联网领域提供了很好的解决方案，但是企业或者政府机关内部相关信息往往需要应用独立的搜索系统，Solr Cloud则是很好的一个平台选择。
1 概述
随着企业和政府信息化建设的持续推进，相关系统平台会产生海量的日志数据，而这些日志数据的整合分析对于企业和政府相关单位具有非常重要的价值，既有关系型数据库能够存储如此海量的大数据，然而对于分析如此海量的大数据进而提供准确的信息查询服务则显得力不从心。
1.1 问题描述
笔者所在从事项目环境对于海量的日志分析具有以下要求。
1）日志信息数据增量庞大。每天会有500万条记录的日志增量，总量有15亿条记录，索引物理存储总量1.5T的存储。
2）数据索引需要保留4年并且会动态添加新表的配置，并且维护索引和搜索会同步进行。
3）需要根据关键字搜索，将相关表的搜索结果总数返回，并且返回其中一个表的前10条数据，要求召回率为100%，可以时间排序。
4）源日志数据表众多且结构不统一。
5）维护索引结构时同时会产生实时日志数据（约平均每小时20万条记录），需保证新日志数据索引同步延迟不得超过1小时。
6）80%请求2 s内响应。物理服务器资源有限，控制在3台左右。
基于以上特定需求，我们提出基于SolrCloud的日志信息查询性能优化方案。
1.2 相关技术
SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作为集群的配置信息中心。它有如下几个特色功能。
1）集中式的配置信息。
2）自动容错。
3）近实时搜索。
4）查询时自动负载均衡.
下面将详细描述应用SolrCloud来管理维护海量日志数据查询的方案，并给出相关优化策略来满足section 1.1所描述特定需求问题。
2 方案设计
从总体框架（图1）我们可以看出，具体优化策略包括：索引优化、检索应用缓存优化、存储优化、分布式优化等方面。方案中我们依据Solr实际测试结果将Solr单机节点数控制在3-5个，每节点索引量控制在3亿条左右。
2.1 索引优化
Solr自带的全切词只能讲中文全切，英文和数字不能切，我们改造了分词算法。全切分可以很好解决拉链问题，也满足全召回，但如果字段长度过大可能会导致性能下降，我们将部分只做精确查询的字段，制定为string类型（不切词），在索引和查询时提高效率。
尽量减少配置的数据库字段，仅索引必要的数据库字段，减少索引量，同时很多字段是需要检索，但不需要显示，将这些设置为不存储。
2.2 检索应用缓存优化
为了更好的提供检索性能，我们将继承分布式缓存。借助Solr的SolrCacheBase集成了BerkeleyDB。由于BerkeleyDB具有以下特性：高速K-V系统，具备持久化功能，拥有一层可配置的内存cache顺序读写。我们极大的缩短了查询的响应时间。
2.3 减少磁盘扫描
Solr是通过唯一主键的，每次检索都要读取正排索引，可以在每个段前添加BloomFilter。Solr要求读取ID，有些记录不分词，倒排索引和目标正文是一样的，只读取倒排索引，减少磁盘扫描，这样通过优化存储来提高查询效率。
2.4 分布式建立索引
Solr Cloud支持直接指定shard（分片），跳过node和collection的分流过程，提高索引入库速度。我们根据日志时间来做shard指定。
2.5 优化分页过程
图4 分页过程
SolrCloud的分页查询是主节点将关键字传给各个shard，各个shard将id和分数传给主节点，主节点再排序后，再通过id到各个shard中取数据。这个过程我们可以通过在图4中1.1.2的步骤中直接返回数据，避免进行后续步骤，提高分页查询效率。
2.6 根据业务分片
图5 分片策略
我们前面通过时间做shard分片，查询过程中可以通过时间范围来确定哪些shard分片，通过指定shard分片，来缩小查询数据范围，提高查询效率。
3 写入、读取性能效果分析
SolrCloud的数据写入性能测试主要包含以下几个场景模式，包含单机3节点虚拟集群与单机5节点虚拟集群的性能比较。理论上节点越多，性能会越高，我们做3节点和5节点的测试。
3.1 实验环境
实测环境的数据库版本为：Solr：4.5，Oracle：10g。
表1 测试环境
服务器 操作系统 硬件环境 数量 Oracle RedHat Linux
5.4 64Bit CPU：32C
MEM：32G 2台
Solr服务器 RedHat Linux
5.4 64Bit CPU：32C
MEM：32G 1台
3.2 索引写入性能
表2 索引写入性能
虚拟节点数 数据量 索引
大小 时间
（小时） 每秒
条数 Cpu/内存
3分片集群 1亿 58G 9h 3471 12%/9.6G
5分片集群 1亿 40G 10h 2300 38%/11G
3分片集群 2亿 120G 17h 3508 18%/15G
5分片集群 2亿 83G 22h 1167 35%/12.5G
3分片集群 3亿 171G 24h 3525 13%/15G
5分片集群 3亿 135G 44h 1800 48%/18G
3.3 数据查询性能
表3 数据查询性能
虚拟节点数 关键字 数据量 时间（毫秒）
3分片集群 *：* 3亿 1400
3分片集群 all_fields：*1986* 3亿 230082
3分片集群 all_fields：1987* 3亿 9870
3分片集群 all_fields：19880101 3亿 4522
3分片集群 all_fields："19890101" 3亿 153845
3分片集群 all_fields：（"1990" AND "1991"） 3亿 250349
5分片集群 *：* 3亿 1344
5分片集群 all_fields：*1986* 3亿 190875
5分片集群 all_fields：1987* 3亿 7703
5分片集群 all_fields：19880101 3亿 3734
5分片集群 all_fields："19890101" 3亿 118437
5分片集群 all_fields：（"1990" AND "1991"） 3亿 218172
3.4 效果分析
由于做了5节点部署之后，对schema做了优化（将不需要显示的字段设置为不存储索引），所以通过上述两种写入模式分析我们可以看出，索引量降低很多，但是5节点索引速度慢了很多，而且随着索引量的增加，索引随之降低。
查询效率方面，在3亿级数据全量搜索情况下，节点数3或者5差别不是很大，但是查询语法的不同效率明显不同。通过不同的关键字语法进行查询，全模糊的效率最低。
考虑到日志系统对索引实时性要求不高，查询性能比索引性能要求更高，该硬件配置情况下，选择5节点模式。
4 总结
本文针对海量日志系统的数据索引和查询性能优化进行了探索，证明在海量日志数据环境下，应用以SolrCloud分布式搜索引擎为基础的查询系统，在经过特定优化策略下，具有很好的查询性能和有良好的扩展性。该方案不仅适用于大数据场景下的日志数据分析，同时也适用于其他海量文本数据查询检索应用，为我们在大数据时代的信息查询搜索业务奠定了技术基础。
参考文献
[1]solr wiki. http：//wiki.apache.org/solr/FrontPage.
[2]solr中国微博. www.solr.cc.
[3]Otis Gospodnetic， Erik Hatcher.Lucene in Action中文版[M].北京：电子工业出版社，2007.
关键词 Solr；SolrCloud；日志信息查询；大数据；性能优化；集群；分片
中图分类号：TP393 文献标识码：A 文章编号：1671-7597（2014）03-0037-03
随着传统互联网和移动互联网的持续发展，网络带给我们的是不断增长的各种不同价值信息，然而如何在信息海洋中快速检索到有价值信息，对于我们来讲至关重要。目前一些搜索公司在公共互联网领域提供了很好的解决方案，但是企业或者政府机关内部相关信息往往需要应用独立的搜索系统，Solr Cloud则是很好的一个平台选择。
1 概述
随着企业和政府信息化建设的持续推进，相关系统平台会产生海量的日志数据，而这些日志数据的整合分析对于企业和政府相关单位具有非常重要的价值，既有关系型数据库能够存储如此海量的大数据，然而对于分析如此海量的大数据进而提供准确的信息查询服务则显得力不从心。
1.1 问题描述
笔者所在从事项目环境对于海量的日志分析具有以下要求。
1）日志信息数据增量庞大。每天会有500万条记录的日志增量，总量有15亿条记录，索引物理存储总量1.5T的存储。
2）数据索引需要保留4年并且会动态添加新表的配置，并且维护索引和搜索会同步进行。
3）需要根据关键字搜索，将相关表的搜索结果总数返回，并且返回其中一个表的前10条数据，要求召回率为100%，可以时间排序。
4）源日志数据表众多且结构不统一。
5）维护索引结构时同时会产生实时日志数据（约平均每小时20万条记录），需保证新日志数据索引同步延迟不得超过1小时。
6）80%请求2 s内响应。物理服务器资源有限，控制在3台左右。
基于以上特定需求，我们提出基于SolrCloud的日志信息查询性能优化方案。
1.2 相关技术
SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作为集群的配置信息中心。它有如下几个特色功能。
1）集中式的配置信息。
2）自动容错。
3）近实时搜索。
4）查询时自动负载均衡.
下面将详细描述应用SolrCloud来管理维护海量日志数据查询的方案，并给出相关优化策略来满足section 1.1所描述特定需求问题。
2 方案设计
从总体框架（图1）我们可以看出，具体优化策略包括：索引优化、检索应用缓存优化、存储优化、分布式优化等方面。方案中我们依据Solr实际测试结果将Solr单机节点数控制在3-5个，每节点索引量控制在3亿条左右。
2.1 索引优化
Solr自带的全切词只能讲中文全切，英文和数字不能切，我们改造了分词算法。全切分可以很好解决拉链问题，也满足全召回，但如果字段长度过大可能会导致性能下降，我们将部分只做精确查询的字段，制定为string类型（不切词），在索引和查询时提高效率。
尽量减少配置的数据库字段，仅索引必要的数据库字段，减少索引量，同时很多字段是需要检索，但不需要显示，将这些设置为不存储。
2.2 检索应用缓存优化
为了更好的提供检索性能，我们将继承分布式缓存。借助Solr的SolrCacheBase集成了BerkeleyDB。由于BerkeleyDB具有以下特性：高速K-V系统，具备持久化功能，拥有一层可配置的内存cache顺序读写。我们极大的缩短了查询的响应时间。
2.3 减少磁盘扫描
Solr是通过唯一主键的，每次检索都要读取正排索引，可以在每个段前添加BloomFilter。Solr要求读取ID，有些记录不分词，倒排索引和目标正文是一样的，只读取倒排索引，减少磁盘扫描，这样通过优化存储来提高查询效率。
2.4 分布式建立索引
Solr Cloud支持直接指定shard（分片），跳过node和collection的分流过程，提高索引入库速度。我们根据日志时间来做shard指定。
2.5 优化分页过程
图4 分页过程
SolrCloud的分页查询是主节点将关键字传给各个shard，各个shard将id和分数传给主节点，主节点再排序后，再通过id到各个shard中取数据。这个过程我们可以通过在图4中1.1.2的步骤中直接返回数据，避免进行后续步骤，提高分页查询效率。
2.6 根据业务分片
图5 分片策略
我们前面通过时间做shard分片，查询过程中可以通过时间范围来确定哪些shard分片，通过指定shard分片，来缩小查询数据范围，提高查询效率。
3 写入、读取性能效果分析
SolrCloud的数据写入性能测试主要包含以下几个场景模式，包含单机3节点虚拟集群与单机5节点虚拟集群的性能比较。理论上节点越多，性能会越高，我们做3节点和5节点的测试。
3.1 实验环境
实测环境的数据库版本为：Solr：4.5，Oracle：10g。
表1 测试环境
服务器 操作系统 硬件环境 数量 Oracle RedHat Linux
5.4 64Bit CPU：32C
MEM：32G 2台
Solr服务器 RedHat Linux
5.4 64Bit CPU：32C
MEM：32G 1台
3.2 索引写入性能
表2 索引写入性能
虚拟节点数 数据量 索引
大小 时间
（小时） 每秒
条数 Cpu/内存
3分片集群 1亿 58G 9h 3471 12%/9.6G
5分片集群 1亿 40G 10h 2300 38%/11G
3分片集群 2亿 120G 17h 3508 18%/15G
5分片集群 2亿 83G 22h 1167 35%/12.5G
3分片集群 3亿 171G 24h 3525 13%/15G
5分片集群 3亿 135G 44h 1800 48%/18G
3.3 数据查询性能
表3 数据查询性能
虚拟节点数 关键字 数据量 时间（毫秒）
3分片集群 *：* 3亿 1400
3分片集群 all_fields：*1986* 3亿 230082
3分片集群 all_fields：1987* 3亿 9870
3分片集群 all_fields：19880101 3亿 4522
3分片集群 all_fields："19890101" 3亿 153845
3分片集群 all_fields：（"1990" AND "1991"） 3亿 250349
5分片集群 *：* 3亿 1344
5分片集群 all_fields：*1986* 3亿 190875
5分片集群 all_fields：1987* 3亿 7703
5分片集群 all_fields：19880101 3亿 3734
5分片集群 all_fields："19890101" 3亿 118437
5分片集群 all_fields：（"1990" AND "1991"） 3亿 218172
3.4 效果分析
由于做了5节点部署之后，对schema做了优化（将不需要显示的字段设置为不存储索引），所以通过上述两种写入模式分析我们可以看出，索引量降低很多，但是5节点索引速度慢了很多，而且随着索引量的增加，索引随之降低。
查询效率方面，在3亿级数据全量搜索情况下，节点数3或者5差别不是很大，但是查询语法的不同效率明显不同。通过不同的关键字语法进行查询，全模糊的效率最低。
考虑到日志系统对索引实时性要求不高，查询性能比索引性能要求更高，该硬件配置情况下，选择5节点模式。
4 总结
本文针对海量日志系统的数据索引和查询性能优化进行了探索，证明在海量日志数据环境下，应用以SolrCloud分布式搜索引擎为基础的查询系统，在经过特定优化策略下，具有很好的查询性能和有良好的扩展性。该方案不仅适用于大数据场景下的日志数据分析，同时也适用于其他海量文本数据查询检索应用，为我们在大数据时代的信息查询搜索业务奠定了技术基础。
参考文献
[1]solr wiki. http：//wiki.apache.org/solr/FrontPage.
[2]solr中国微博. www.solr.cc.
[3]Otis Gospodnetic， Erik Hatcher.Lucene in Action中文版[M].北京：电子工业出版社，2007.