科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网服务器频道虚拟化/云计算花15美元租台机器实现百万文档检索

花15美元租台机器实现百万文档检索

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

有了对搜索产品足够深入地了解,再进行一些实验,从廉价的硬件中获得高性能是完全可能的,我们完全可以避免对SaaS的依赖,从而节省大量的费用。了解系统的内部原理也能在你向SaaS平台转移时,帮助你作出正确的决定。

作者:Richard Donovan 来源:CSDN 2014年5月13日

关键字: 云计算 SaaS 搜索引擎 大数据

  • 评论
  • 分享微博
  • 分享邮件

Gwittr以twitter搜索为人所知,同时它还是一个统计信息的网站,除了提供有关推文及链接网页的扩展搜索,也进行数据的统计分析。这篇文章重点介绍如何在廉价(< $15/月)机器上运行一个中型、大型搜索(超过300万份文档)?

面临哪些挑战?

  • 把这个问题丢给云计算既不便宜也不一定能得到解决;
  • 避免为不必要存储空间支付过高的费用;
  • 了解文档字段定义并针对检索需求做优化;
  • 精心设计查询;
  • 研究提交策略;

这些优化对Solr有效,也同样适用于任何基于Lucene的搜索引擎,比如Elastic Search。

把问题扔给云计算怎么样?

在这个云计算和EaaS(Everything as a Service,一切皆服务)时代,对于那些产品需要搜索功能的公司,托管搜索服务很有吸引力。虽然一秒钟只收几美分的云服务听起来很划算,但是到实际应用中,每个月很容易就会产生数百甚至数千美元的费用。

避免这些费用的方法就是在vanilla硬件或者虚拟机上运行自己的Solr,这不仅可以帮助你节省大量的费用,而且还会帮助你获得有关搜索引擎的技能和知识,利用这些技能和知识,可以帮助你进一步节省大量的开支,即使在你要转用其他搜索平台的时候,这些知识和技能也是必不可少的。

在Gwittr中,我们可以在非常便宜的虚拟机中运行Solr实例,而且我们还可以在没有太大延迟的前提下,对数据进行相当高级的统计。于此同时,我们需要遵循以下几个原则。

搜索不等于存储

像Solr这样的搜索引擎不等于数据库存储,索引是很重要的,如果你忘了这一点,只将搜索索引看成内存,那就会产生一些风险:

  • 数据丢失。尽管Solr确实采用了一些保持数据完整性的技术,但保证数据持久性毕竟不是这些系统的长项。
  • 由于Gwittr这样的流媒体数据搜索,搜索专用的存储将得到快速发展。如果你正在使用SaaS,那就意味着将数据存储到Solr中或是内存中是很有必要的。
  • 敏捷性的损失。重建索引以支持新功能是不可避免的,如果不为此做好准备,将失去敏捷性。

优化#1  将搜索索引看作是可任意处理、易于重建的资源,因为当你需要引入新的特性时,应用程序需要经常性、大规模重建索引。

确定架构中的所有字段不通过默认方式存储,这对使用普通的功能已经足够了。一般你不需要在Solr中存储文档字段,除非你要使用突出显示的功能,因为Solr在使用一些突出显示功能时,需要用到文档中的初始文本。你也会想要存储更多的东西,比如文档标识符,因为在应用程序代码中,你可能会用到文档标识符将搜索结果链接回内存。

Solr还提供一套扩展的字段索引选项,帮助你进一步简化索引的过程。

浏览vs.搜索

虽然Solr、Lucene等一系列产品在市场上被称为“搜索引擎”,但实际上,称它们为优越的浏览引擎(具有面片化(faceting)功能的浏览引擎,这也是一个强有力的卖点)更恰当,相比那些开源数据库,它们有极好的文本搜索性能。如果你去了解一下用户体验是如何设计的(包括怎样才能让Web爬虫看到你的网站),除非你是Google,如果不是你很有可能会发现:大多数情况下,你的用户在搜索关键字后还会单击相关导航功能(面片(facet)以及类似文档……),至少像Gwittr那样,让访客可以看到所有的结果,在没有输入任何关键字的情况下对数据进行挖掘。

优化#2  在“浏览”相关查询时,最好使用Solr的过滤器,而不是在“q”参数中堆砌。Solr过滤的文档集被缓存,它们没有进行任何相关性得分的计算,所以,使用它们浏览查询将为你节省宝贵的I/O和CPU周期。

此外,搜索引擎不会在匹配集中显示太多的结果页,显示的结果页越多,需要的临时内存就越多,结果获取的速度也就越慢。就算是Google,搜索的结果最多也不会超出1000页。

优化#3  在应用程序中加入分页限制。

优化#4  只请求那些你需要用来显示结果的字段,从而尽量减少I/O和带宽。

Solr提交不等于RDBMS提交

在数据库中,我们无时不刻不在使用事务和并发机制,在更新操作涉及到许多行或者许多表时,这是确保数据完整性的一个正确方法,在Solr中,“提交”有着迥然不同的语义。

你很有可能已经知道,在Solr中没有所谓的“更新”、“数据完整性外键”或者“多表”,实质上,Solr/Lucene只是通过索引形式管理日益增长的文档集合。每次添加、更新或删除一个文档集合,Solr就会向其数据目录中添加一个新“段”(一堆文件),最后段的数量会越来越大。有一种机制可以应对这种情况,这里就不再赘述。

在Solr中,通过一个Searcher对象可以处理所有的搜索查询。Searcher建立在索引组成的段的集合上。提交在这里的作用很简单:“让Solr生成新的Searcher,包括新段,并以原子方式用它替换当前Searcher。”

不要过分追求速度

优化#5  避免不惜代价的并发提交,因为你不停地构建新的Searcher,之后又把它扔了。事实上,同时构建Searcher会导致在Solr的配置中产生一个显式设置对数目施加严格上限,默认值是2。所以如果你同时提交的话,很有可能会获得异常堆栈,抱怨打开的Searcher太多。

优化#6  监视建立新Searcher的时间。优化在Solr中新建/更新文档的响应时间(流行的说法是“实时”),总的来说就是尽量减少Solr生成一个新Searcher对象的时间。监视Solr日志,查找“事件=newSearcher”,然后查找那些行QTime(查询时间),为的是使时间尽可能合理的短(我们稍后将看到为什么“合理”在这里很重要),因为构建新Seacher的速度越快,你可以构建的Seacher就越多,插入、更新和删除的响应就越快。

在Solr中有两个主要的提交策略。第一个策略就是让Solr在固定的时间间隔完成提交,该方法被称为自动提交,应作为首选策略考虑,它可以帮助你摆脱对应用程序的手工管理。事实上,如果你使用了自动提交,那让应用自己提交就成为一个非常糟糕的办法,记住重叠Searcher的上限也适用于自动提交的Searcher,所以要让自动提交比构建Searcher的时间更长。自动按固定时间间隔提交存在问题——在索引没有更新时,定期构建新的Searcher只是在浪费CPU,这也为我们指出提交的第二个策略:

优化#7  让应用程序根据需要执行提交。并发是一个糟糕的办法,应该实施全局的锁机制。

给Searcher热身

你可能会想“构建只增加了一个段的新Searcher能有多慢?Solr很好地支持这一点而且肯定会非常快”。你说对了,它的速度确实非常快。

唯一的问题是新Searcher最初的几个查询将会非常慢,这并不好。在高容量搜索环境中,几个缓慢的查询可能成为产品的短板,最终影响到应用程序层。这些最初查询缓慢背后的原因是新Searcher缓存中填充的东西是无用的。在Solr术语中,这被称为“Cold Searcher”。Solr允许使用“Cold Searcher”,但幸运的是这仅存在于其他Searcher也没有被注册的情况下。也就是说,它只发生Solr的实例刚开始时。在所有其他情况下,Solr会提供了一些给“Searcher”热身的机制,确保在它们被用到服务请求时,查询的速度不会太慢。

优化#8  有两组设置影响到新Searcher的热身,应该将两者结合起来使用。

  • 一组是设置Solr对热身中的Searcher进行查询。针对这些查询,可以建立几个实时应用程序的典型查询样本,使其在移除过滤器后能更通用一些,关键是要尽量包括将在应用程序中使用的各个方面,还可以发出几个关键字查询,因为如果有足够的空间,这种方法会在内存中加载全文索引。
  • 另一种给新Searcher热身的方法是在缓存中建立autowarming。高速缓存autowarming是将旧缓存中的值预先填充到热身中的Searcher缓存中。

对于热身中的Searcher关键是要找到建立新Searcher与注册Searcher在时间上的平衡(建立新Search可以很快——但很危险),找到这个平衡点需要进行实验,而这一切都取决于应用程序层的需要。

结论

有了对搜索产品足够深入地了解,再进行一些实验,从廉价的硬件中获得高性能是完全可能的,我们完全可以避免对SaaS的依赖,从而节省大量的费用。了解系统的内部原理也能在你向SaaS平台转移时,帮助你作出正确的决定。SaaS是个避免扩展和备份等头痛事情的好办法,但不要忽略了这些服务的背后的技术,不然即使你支付很高的费用,也不一定能得到高性能。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章