lucene事务（译与解）
本文分两部份，第一部份为译：是对是对于lucene事务的一篇佳作《Transactional Lucene》的翻译。第二部份为解：是本人对一文中提到一些概念在源码层次的一些理解分析，参考lucene源码版本为4.10.4。《Transactional Lucene》中还提到了多commit在实际生产中的一些妙用，值得参考。
标签 搜索引擎 下的文章
关于solr build search分离的讨论以及re-indexing的实现
场景需求与分析
我们的做法，一般将索引构建大致分为两类操作，一为全量索引构建，二为增量索引构建。使用solr建索引，一般会在初始状态的时候，进行一次全量构建，根据当前数据源的整体数据生成一套完整索引，可提供服务，但为了保证索引数据的完整且最新，还需要增量索引，使得数据源的改变（包括记录的增加，修改，与删除）体现在这套索引之上。
Solr源码掘金之 SolrCloud中的zookeeper使用分析
上一周，对公司搜索引擎工作流程的做改造工作。涉及到不同角色服务器之间的沟通工作。我们试图应用zookeeper到我们的场景，实现应用模块之间的解耦。本文深入到solr源码，从中掘金，看看solr是如何使用zookeeper的。
在做本次改造的时候，公司同事对于zookeeper的使用，提供了很好的建议，其中一个重要原则就是“谁创建，谁修改”，也就是各个服务应用自己创造自己的结点，自己去修改配置自己的最新状态。一般情况下，对结点的修改是结点的创建者，而不应该是其它对些结点数据的关注者，不然会增加操作复杂度与不确定性。
IK分词器原理与源码分析
引言
做搜索技术的不可能不接触分词器。个人认为为什么搜索引擎无法被数据库所替代的原因主要有两点，一个是在数据量比较大的时候，搜索引擎的查询速度快，第二点在于，搜索引擎能做到比数据库更理解用户。第一点好理解，每当数据库的单个表大了，就是一件头疼的事，还有在较大数据量级的情况下，你让数据库去做模糊查询，那也是一件比较吃力的事（当然前缀匹配会好得多），设计上就应当避免。关于第二点，搜索引擎如何理解用户，肯定不是简单的靠匹配，这里面可以加入很多的处理，甚至加入各种自然语言处理的高级技术，而比较通用且基本的方法就是靠分词器来完成，而且这是一种比较简单而且高效的处理方法。