Solr 七宗罪

用空闲时间翻译的一篇solr的文章，不过没有翻译完，sorry！

先贴出来，以后再完善。

原文： http://searchhub.org/2010/01/21/the-seven-deadly-sins-of-solr/

译文：

在 Lucid Imagination 工作给了我分析和评估许多Solr实例的机会，其中Solr不仅运行于最大的财富500强公司，也跑在最小的创业公司上。这些经验使得我能够在建立一个新的Solr应用或保持Solr最新的更改的同时鉴别出许多常见的错误和陷阱。多谢了我的同事Simon Rosenthal提出了文章题目的建议，同时感谢Lance Norskog, Tom Hill给了我有用的建议。言多无益，开始Solr的七宗罪吧。

罪一，懒惰(sloth)

我们定义sloth为懒惰(laziness)或者漠不关心(indifference). 懒惰时时刻刻侵蚀着我们。我们不能抵制避繁从简的冲动，抑或我们仅仅是拒绝承认合理的完成一项任务所必须的工作量。最终我们停止付出，这通常表现为兴趣的枯竭。这儿有一些懒惰或漠不关心如何导致Solr问题的常见例子。

（1）Solr或者搜索应用项目本身缺乏提交。有时候你在一个公司决定从商业搜索应用转换到像Solr和Lucene这样的开源替代品时候可以看到这种现象。涉及该项目的工程师习惯于“古老的方式”而并不感觉要掌握一门新的搜索技术。所以他们甚至不愿付出一点努力就声称Solr不是高效的，Solr很难掌握或者不值得花费这么多努力。如果你很饿的话，那么在很多人的周围一起等待炸鸡飞到你嘴里通常是不切实际的。你的时间也许被用在更主动的获取食物上会更好。开源的软件灵活，自适应强，并且强大，但是那些在开源的解决方案中称为专家的开发者都是那些卷起袖子拼命干并且深入的学习他们所需要了解的知识。参与到邮件列表当中。打开开源代码。阅读文档和wiki。我同那些沉浸于Solr并在短时间内就称为专家的用户甚至刚开始项目几周就贡献过补丁的用户一同工作过。另一方面，我也目睹过由于团队不愿意对Solr的实现付出哪怕一点点努力而导致问题越来越糟糕的情况。无眼不是瞎，有眼不看才是真瞎。

（2）没有审阅、编辑或者改变默认的schema.xml 或/和 solrconfig.xml 文件。

（3）忽略 dismax query parser. 我见过很多这样的案例，人们基于自身系统写了一个自定义的查询解析器，然后他们所需要做的工作可以很简单的被dismax query  parser 完成。有两个极端来解释为什么人们有时会不使用dismax。有一种是觉得dismax是一个被遗弃的解析器，我觉得之所以会有这样的问题部分因为在DismaxRequestHandler 的维基页面的第一行（顺便说一句，我们仍然苦于这个不幸的官方命名--它是一个查询解析器，而不是一个请求句柄）这样说dismax“其被设计用于处理简单的用户输入的词组”。这样的话就会有一种感觉，dismax仅仅是对于那些不愿意做任何工作就来改变他们查询的入门级的工具。正好相反，dismax有巨大的功能和灵活性以致于有“避免dismax”的副作用，也就是说dismax“过于复杂”。实际上，它确实有点复杂。但是，花些时间去了解dismax的回报是巨大的。

罪二，贪婪(greed)

因小失大。这实在有点令人惊讶，它是不少人犯的再寻常不过的错误。很明显并非所有人都有无限的预算，但是有时候为了节约资源而作出糟糕的决定，这些决定都将证明其会更浪费时间，比如：

（1）拒绝给服务器加适当的内存。曾有这样的场合，当我在我的Mac笔记本上的内存多于我曾见过的一些Solr安装所耗的内存。有时候即便Solr在大公司的工程都是内存不足的。Solr会有对内存要求极高的业务需求(对大量的string字段的排序，基于多个字段大量distince terms 的面过滤)，但是其表现出来的是在不足的内存和某种魔法下，solr也能工作起来。我有个朋友曾这样说过，你不能把15磅的大米放到只有10英镑的袋子里(you can't fit 15 pounds of rice into a 10 pound bag) . 无论如何请投入至少能到达最小充足的资源。

（2）在同一台服务器上建立索引和搜索。我们在Lucid Imagination 最经常给客户的第一个建议就是把索引和搜索程序放在(至少)两个不同的节点上。通过这样做我们能有不少益处。首先，索引和搜索过程不再会对资源产生竞争(cpu, 内存等)。其次，master和slave(s)可以配置的些许不同以达到最优的性能。确定给你的文档数量、索引大小和期望的查询容量配置足够的硬盘空间。

罪三，高傲(pride)

高傲(我们的理解)：没有承认别人的优异工作。过分的偏爱靠自己来编码。有时候甚至到了明知可能在某个地方已经有解决方案了但还是想要自己来创建工作，这是因为：a)他们认为自己能做的更好;b)他们认为经历这些过程能够学到东西;c)这样会“很有意思”.这并不是不鼓励新的工作到开源的项目中去贡献bug修复，提升现有的功能。但是要谨慎不要匆忙，在你了解什么选项已经存在之前再开始编码。多思量，再行动。

(1) 不要再造车轮。我曾见过开发者差点寻找借口来写他们自己的查询解析器或者其他的自定义组件。有时候这样的工作是必要的，幸运的是，开源软件已经使之可行，而这在商业搜索软件中是不可行的。但是在动手写自定义代码前确定你有实际的需要，至少公司有需要。由于维护自定义的代码并和Solr同步会付出额外的努力，所以确保那确实是解决用例的唯一方法。

(2)利用邮件列表和目录存档。这应该是显而易见的，但是还是有许多人认为这会在某种方式上贬低他们，就好像向别人寻求帮助是自己的一个瑕疵一样。相反的，发文在邮件列表上，充分的利用每个人的时间。在发文之前确保遍历搜索过整个列表。(LucidFind 会提前搜索相关的邮件列表，维基，博客，文档和当地的源数据). 当提交一个问题的时候，保证对问题描述的简洁，让别人明白你所需要的。保持话题贯穿全文。Lucene和Solr的提交者还有Lucid Imagination的员工是邮件列表的常客，所以当你有实际的需求的时候好好利用好这一资源。

罪四，欲望(lust)

对此你们必须授予我艺术许可证，否则我们不能保证这篇博客为G级。我们定义lust为“对某事的不自然的渴求以致于放纵或失常”。

(1) 把JVM的堆栈容量设置的太高，没有给OS留足够的内存。我们终于得到我们一直渴求的(参见: “贪婪”)内存分配，现在我们该做什么呢？现在我们在机器上有16G的内存，所以我们分配15G的内存给Solr运行所在的堆空间中。哇哦！洗冷水澡的时间到了。Solr也许是你唯一关心的，但是不要忽略了操作系统啊。耐心和留心在此就发挥作用了。观测加载的JVM并判断Solr实际所需的内存。你得让操作系统能够缓存得了文件系统的数据(特别是lucene的索引)，因此确定给操作系统预留了足够的内存空间。

(2) 对JVM核垃圾回收过多关注。另外一方面(与我们第一次在“贪”婪的重点完全相反)，不要再JVM上作的太过分。似乎对JVM所做的调整是无止境的。不要陷入尝试每一个晦涩的JVM或垃圾回收的设置的陷阱中，除非你是个JVM的专家。一旦你掌握了JVM的基础，并掌握了不同类型的垃圾回收之间的不同，大多数情况下你不需要再做其他的创新举动了。不要出于好奇心混淆"-XX:CMSIncrementalDutyCycleMin=10"。

(3) Trying to "push the envelope" on auto-warm counts

罪五，嫉妒

(1)想要其他站点拥有的而你自己并不需要的特性。专注于你自己的业务需求。确保你清楚从搜索应用中你真正需要什么。一个在邮件列表的常见的场景就是Lucene/Solr 的提交者Chris Hostetter称之的“XY”问题。从Solr的用户邮件列表中:"你在处理问题‘X’，你设定‘Y’可以起到帮助，你询问有关‘Y’的问题而未提及‘X’，以至于我们认为‘Y’就是全部的问题所在。也许最好的解决方案根本就不需要‘Y’ "。明确你所需要的，并专注于其要求。

(2)想要比其他人有更大的索引。这