Gwittr以twitter搜索为人所知，同时它还是一个统计信息的网站，除了提供有关推文及链接网页的扩展搜索，也进行数据的统计分析。这篇文章重点介绍如何在廉价（< /月）机器上运行一个中型、大型搜索（超过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是个避免扩展和备份等头痛事情的好办法，但不要忽略了这些服务的背后的技术，不然即使你支付很高的费用，也不一定能得到高性能。
