基于Solr的海量日志信息查询性能优化的研究.docxVIP

基于Solr的海量日志信息查询性能优化的研究.docx

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

?

?

基于Solr的海量日志信息查询性能优化的研究

?

?

冯祥+邱志超

摘要ApacheSolr是一个基于ApacheLucene的开源企业搜索服务器。ApacheSolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要思想是使用Zookeeper作为集群的配置信息中心。文章在海量日志索引信息存储和查询方面进行了探索,证明了在相关优化策略下SolrCloud具备了优秀的查询性能。

关键词Solr;SolrCloud;日志信息查询;大数据;性能优化;集群;分片

:TP393:A:1671-7597(2014)03-0037-03

随着传统互联网和移动互联网的持续发展,网络带给我们的是不断增长的各种不同价值信息,然而如何在信息海洋中快速检索到有价值信息,对于我们来讲至关重要。目前一些搜索公司在公共互联网领域提供了很好的解决方案,但是企业或者政府机关内部相关信息往往需要应用独立的搜索系统,SolrCloud则是很好的一个平台选择。

1概述

随着企业和政府信息化建设的持续推进,相关系统平台会产生海量的日志数据,而这些日志数据的整合分析对于企业和政府相关单位具有非常重要的价值,既有关系型数据库能够存储如此海量的大数据,然而对于分析如此海量的大数据进而提供准确的信息查询服务则显得力不从心。

1.1问题描述

笔者所在从事项目环境对于海量的日志分析具有以下要求。

1)日志信息数据增量庞大。每天会有500万条记录的日志增量,总量有15亿条记录,索引物理存储总量1.5T的存储。

2)数据索引需要保留4年并且会动态添加新表的配置,并且维护索引和搜索会同步进行。

3)需要根据关键字搜索,将相关表的搜索结果总数返回,并且返回其中一个表的前10条数据,要求召回率为100%,可以时间排序。

4)源日志数据表众多且结构不统一。

5)维护索引结构时同时会产生实时日志数据(约平均每小时20万条记录),需保证新日志数据索引同步延迟不得超过1小时。

6)80%请求2s内响应。物理服务器资源有限,控制在3台左右。

基于以上特定需求,我们提出基于SolrCloud的日志信息查询性能优化方案。

1.2相关技术

SolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要思想是使用Zookeeper作为集群的配置信息中心。它有如下几个特色功能。

1)集中式的配置信息。

2)自动容错。

3)近实时搜索。

4)查询时自动负载均衡.

下面将详细描述应用SolrCloud来管理维护海量日志数据查询的方案,并给出相关优化策略来满足section1.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分布式建立索引

SolrCloud支持直接指定shard(分片),跳过node和collection的分流过程,提高索引入库速度。我们根据日志时间来做shard指定。

2.5优化分页过程

图4分页过程

SolrCloud的分页查询是主节点将关键字传给各个shard,各个shard将id和分数传给主节点,主节点再排序后,再通过id到各个shard中取数据。这个过程我们可以通过在图4中1.1.2的步骤中直接返回数据,避免进行后续步骤,提高分页查询效率。

2.6根据业务分片

图5分片策略

我们前面通过时间做shard分片,查询过程中可以通过时间范围来确定哪些shard分片,通过指定shard分片,来缩小查询数据范围

文档评论(0)

183****9213 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档