twitter之前的搜索使用的是被它收购的Summize公司的技术，是基于mysql的搜索，具体技术细节不祥。 Finding A Perfect Match有提到，Summize也是个初创公司，做的就是twitter搜索，而twitter看中了Summize的技术和团队，便收编它为正规军。不过，随着twitter数据量的激增及对实时搜索的高要求（每秒1000条推的索引更新和12000次查询，一天下来有10亿次查询），原有的技术架构越来越不能满足需求，所以twitter转向了lucene。这除了lucene拥有诸多的优点，也是因为twitter自家有人是lucene的commiter。

当然，lucene也有缺点，文中有提到twitter对lucene的一些改进点如下，这些点已经或将被提到lucene代码中：
（1）改进GC性能。
（2）无锁的数据结构和算法
（3）逆序遍历posting列表（是指希望默认的查询排序方式是按照添加的索引顺序，而不是需要显示指定排序字段，以提高速度？）
（4）有效的早期query终止（是指对查询做了超时限制，避免查询因为读磁盘等原因被hang住？）

就像之前的linkedin开源过一个基于lucene的实时搜索项目zoie （用Zoie构建实时检索系统 实时检索系统Zoie实现分析），对于social应用，现在越来越追求搜索的实时性。lucene在2.9版本引入了NRT（Near Real-Time search），算是对实时搜索需求的初始回应，但NRT不是RT，根据应用特点不同，一般能做到秒级别到分钟级别的准实时搜索。lucene的RT搜索目前还在branch中缓慢的孕育，twitter为其贡献着代码并充当了很好的实战的先头兵，这个很赞的说。

期待着lucene和solr的RT搜索能早些出来，这样我可能会考虑迁移现在的站内搜索架构。对于查询量不大更新量更不大的站内搜索来说，将建索引和实时查询做到一个server中，而取代master-slave结构，既简化了架构，也提供了更好的查询效果。

实时检索的核心原理

通常的检索系统中，建索引和查询是分开的，即建索引是离线的，新的索引会以一定频率（比如每隔5分钟）供查询端使用。对于一些站内检索来说，这种延迟性使得：不需要建索引的速度足够快（只要能跟的上提交频率就行），查询的效果不必完全精确。而要取得实时检索效果，典型的思路是：建索引和查询是在一个进程内，这样每一次的添加索引都会被下一次的查询用到，但这里面的细节还是需要好好琢磨解决的，下面就给出Zoie的基于Lucene的解决方案：索引分两种，ram index和disk index。建索引的过程是：首先建立ram index，因为是内存操作，这个过程通常较快，建完后会重新打开IndexReader，使查询端能看到最新的索引；当内存中的索引文档数达到阈值（10000）或者间隔时间达到阈值（自定义），一个后台线程就将ram index合并到disk index里去，完成后清空已经无用的ram index，并重新打开disk index的IndexReader供查询使用（这里面有个autowarm IndexReader的过程）。特别指出的是，Zoie的ram index有两个，这使得当一个ram index在和disk index做合并操作时（这个过程可能会很耗时），另一个ram index仍能提供建索引的操作。对于查询，使用的索引就包括两个ram index和一个disk index，所以只要索引在内存里建好，就能查询到最新的数据。

实现概览

下面简要说明Zoie的核心接口和类。

ZoieSystem：这个类是对外的核心类，它提供了诸多方法供外界使用，但它本身就像个Facade，封装了其成员的一系列方法。

DataConsumer：顾名思义，这个接口是用来消费数据也就是建索引的。实时建索引时，ZoieSystem默认使用的DataConsumer是RealtimeIndexDataLoader。在consume数据时，RealtimeIndexDataLoader主要是将数据转换成内部结构后交给另一个DataConsumer即RAMLuceneIndexDataLoader真正在内存里建索引，之后如果当前处理的索引数达到阈值，RealtimeIndexDataLoader会notify LoaderThread，而LoaderThread会调用DiskLuceneIndexDataLoader来合并索引。

DiskSearchIndex和RAMSearchIndex：这两个类是Zoie操作索引结构的，比如获取或打开指定目录的IndexReader、IndexWriter，更新索引写盘等操作。

DataProvider：这个结构表示数据提供者。查看Zoie代码，发现如果在索引的过程中程序挂掉，内存中的索引就有可能丢失，解决这个问题的方法可以是，在DataProvider端做控制，最直接的，当重启程序时，重放之前一段时间的数据即可（因为Zoie能做到定期刷数据，所以可计算出需要回放的时间点）。

建索引的过程

上面已经对建索引过程做了一些说明，下面配上Zoie wiki上的图再形象化些。分析它的实现时，有个RAM需要重点关注，它包含了两个RAMSearchIndex（Ram A和Ram B）和一个DiskSearchIndex对象成员，并且Ram A和Ram B也同时扮演Ram writable和Ram readable，建索引时用的是Ram writable，查询时用的是Ram readable。通过下面的图可以看到，Ram A和Ram B有个交换和清空的过程：1）RAM交换发生在Ram A要合并到Disk Index前，把A的数据挪到Ram B，使新的Ram A开始接收处理客户端建索引请求，而Ram B不再接收数据而专心合并索引。2）在合并索引完成后，Ram B就需要清空了。

删除数据

Zoie没有提供删除索引的接口，它认为每一次的提交或者是add或者是update。在建索引时，Zoie先将document的uid映射成docid，如果发现docid已存在，就需要标记删除该doc。lucene里表示删除标记的文件是xx.del，Zoie当然会最终将标记更新到这个文件，但因为索引结构有两个Ram index和一个disk index，并且不能每一次标记删除就更新disk index，所以Zoie在两种SearchIndex对象里记录了删除标记。当建索引，Zoie同时更新三个SearchIndex内存索引的删除标记，而在查询时会过滤掉被删除的doc。Zoie还提供了expungeDeletes方法来清除disk index中垃圾索引数据，这个操作因为耗时长而适合在凌晨进行，但查看Zoie的代码，这个操作只提供了通过JMX手动实现而没有自动执行的时机。

ZoieMergePolicy

Zoie的索引合并策略实现可以说是它的很大亮点。lucene中默认使用的MergePolicy是LogByteSizeMergePolicy，这个MergePolicy在选择合并的segment时，是计算segment的总的字节大小。这种方式的一个缺陷是，像用户profile这种如果update操作多的话（每次update会有一次delete操作），会使得一些segment看起来很大，实际上其中有效的索引数据会很少，这些无用索引数据会给查询带来负担。ZoieMergePolicy在计算索引大小时就去除了已删除的doc，使计算更加精确，下图是Zoie给出的两种MergePolicy的性能对比，随着时间的增长，因为被标记delete的doc越来越多，LogByteSizeMergePolicy的查询性能就下降的很厉害了。但是，如果每天低峰期做一次expungeDeletes操作，并且每天提交的delete操作不多的话，LogByteSizeMergePolicy的问题也不是很大。还有一点，Zoie对segment的数量处理上，默认是最多大段10个、小段20个（可通过合并引子控制），通常段数保持在十几个，因为段数比较多，查询时的性能会受些影响，好处是一些旧的大段不会被频繁合并。

总结

上面是对Zoie的实现的简要分析，如有理解不准确的误人之处，敬请指出并谅解。

下面将要介绍的使用Zoie API来编写检索demo，并且为了省事，我的code sample直接来自于Zoie的Wiki（http://snaprojects.jira.com/wiki/display/ZOIE/Code+Samples），但会对其中的使用做些中文版的说明。由于Zoie是个很有针对性的实现，所以相比于Solr这样的通用系统来说，Zoie的代码要“直白”很多，这也促使我拿出精力把它的核心代码研究了一番。总结下来有两点：1）要写一个基于lucene的精致的检索系统需要对lucene有深入的理解，针对实时性检索需求，Zoie本身就对lucene做了很多扩展。2）Zoie的代码结构和代码风格有些糟糕，我看到git里有.project文件，所以可见其作者应该也是基于eclipse开发的，可他的代码就不能好好format下？并且包名和类层次也很诡异。闲言少叙（让我再次想起俞平伯先生），下面罗列下使用Zoie API的code sample。

在检索server端，需要索引的数据总要以一种结构表示，比如一个MAP或POJO之类的。让Zoie来索引数据，就需要Zoie知道你需要索引哪些Field到Document（lucene里的Document）里。说白了，要提供一份要索引的数据及将数据转换成Document结构的接口。这里的数据假定是一个Data：

class Data{
long id;
String content;
}

转换数据的工作由实现ZoieIndexableInterpreter接口的类实现，代码片断如下：

class DataIndexable implements ZoieIndexable {
  private Data _data;
  public DataIndexable(Data data) {
    _data = data;
  }
 
  public long getUID() {
    return _data.id;
  }
 
  public IndexingReq[] buildIndexingReqs() {
    // it is possible we want to map 1 data object to multiple lucene documents
    // but not for this example
    Document doc = new Document();
    doc.add(new Field("content",_data.content,Store.NO,Index.ANALYZED));
 
    // no need to add the id field, Zoie will manage the id for you
    return new IndexingReq[]{new IndexingReq(doc)};
  }
 
  // the following methods in this example are kind of hacky,
  // but it is designed to be used when information needed to determine whether documents
  // are to be deleted and/or skipped are only known at runtime
 
  public boolean isDeleted() {
    return "_MARKED_FOR_DELETE".equals(_data.content);
  }
 
  public boolean isSkip(){
    return "_MARKED_FOR_SKIP".equals(_data.content);
  }
}
 
class DataIndexableInterpreter implements ZoieIndexableInterpreter {
  public ZoieIndexable interpret(Data src){
    return new DataIndexable(src);
  }
}

针对上面的代码，我还需要做一些解释。可以看出的是，Zoie在建索引时，需要使用public IndexingReq[] buildIndexingReqs()方法来取出数据，在这个方法里，需要自己build document结构。而方法public long getUID()表明，Zoie需要索引的数据包含uid（可以认为是唯一性主键的概念，而不必须是实际意义的uid），并且这个uid不要在buildIndexingReqs()方法里做成Field，Zoie自己会处理uid，实际上它内部是将uid和lucene的doc id对应上了。这有什么用处呢？对于像用户profile情景，是假设没有删除profile而只有add或update的情况，这使得Zoie在内存里记录了uid和doc id的对应关系，当检查发现是update时，就标记该doc需要在search时过滤掉。对于需要删除数据的场景，一个折中的方法是仅保留uid而将其他Field都去掉。还有那个isDeleted()方法，不要以为它是提供要删除的doc的判断的，它的作用和isSkip差不多，是在Zoie建索引时临时的将当前的Data去掉而不建它的索引（这需要外部修改Data的内容才行），就好像你发现建的数据有问题想中止操作一样，但可想见的是，你根本不知道Zoie建索引到什么阶段了，这个接口的用处就值得怀疑了。

下面再来构建IndexDecorator。Zoie提供的这个接口是允许客户端（相对于Zoie来说是客户端）对给定的ZoieIndexReader装饰成自定义的IndexReader。就像demo给的那样，除非有必要，否则默认实现就可以了。

class MyDoNothingFilterIndexReader extends FilterIndexReader {
public MyDoNothingFilterIndexReader(IndexReader reader) {
super(reader);
}
 
public void updateInnerReader(IndexReader inner) {
in = inner;
}
}
 
class MyDoNothingIndexReaderDecorator implements IndexReaderDecorator {
 
  public MyDoNothingIndexReaderDecorator decorate(ZoieIndexReader indexReader) throws IOException {
    return new MyDoNothingFilterIndexReader(indexReader);
  }
 
  public MyDoNothingIndexReaderDecorator redecorate(MyDoNothingIndexReaderDecorator decorated,
                                                    ZoieIndexReader copy) throws IOException {
    // underlying segment has not changed, just change the inner reader
 
    decorated.updateInnerReader(copy);
    return decorated;
  }
}

下面是build Zoie的核心：ZoieSystem。indexingSystem的start()方法将启动新的线程准备接收数据来建索引。

// index directory
File idxDir = new File("myIdxDir");
 
// create an analyzer
Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_CURRENT);
 
// create similarity
Similarity similarity = new DefaultSimilarity();
 
ZoieIndexableInterpreter myInterpreter = new DataIndexableInterpreter();
 
IndexReaderDecorator decorator = new MyDoNothingIndexReaderDecorator();
 
ZoieSystem indexingSystem = new ZoieSystem(idxDir,         // index direcotry
                                           myInterpreter,  // my interpreter
                                           decorator,      // index decorator
                                           analyzer,       // my analyzer
                                           similarity,     // my similarity
                                           1000,           // # events to hold in mem before flushing to disk
                                           300000,         // time(ms) to wait before flushing to disk
                                           true);          // true for realtime
 
indexingSystem.start();  // ready to accept indexing even

下面给出建索引和查询的使用片断，两者可分别在不同线程执行。
索引线程的代码片断：

long batchVersion = 0;
while(true){
  Data[] data = buildDataEvents(...); // build a batch of data object to index
 
  // construct a collection of indexing events
  ArrayList eventList = new ArrayList(data.length);
  for (Data datum : data){
    eventList.add(new DataEvent(batchVersion,datum));
  }
 
  // do indexing
  indexingSystem.consume(events);
 
 // increment my version
  batchVersion++;
}

上面的buildDataEvents方法是产生数据的方法，比如接收客户端请求的数据（也许它还会阻塞在那？），或者是查询数据库的数据之类的。ZoieSystem的consume方法就是用来消费数据建索引，并且是可以批量处理的。

再看看查询线程的代码片断：

	// get the IndexReaders
List> readerList = indexingSystem.getIndexReaders();
 
// MyDoNothingFilterIndexReader instances can be obtained by calling
// ZoieIndexReader.getDecoratedReaders()
 
// combine the readers
MultiReader reader = new MultiReader(readerList.toArray(new IndexReader[readerList.size()]),false);
// do search
IndexSearcher searcher = new IndexSearcher(reader);
Query q = buildQuery("myquery",indexingSystem.getAnalyzer());
 
TopDocs docs = searcher.search(q,10);
 
// return readers
indexingSystem.returnIndexReaders(readerList);

懒得解释了，跟使用lucene的查询接口差不多。

上面的代码稍加完善就可以真正跑起来了。Zoie也提供了独立的Server功能，但它的那个Server很有可能是你不想要的，而使用上述的嵌入式接口来实现一个Server显然已经极大简化工作了。Zoie还提供了DataProvider机制及实用的实现，对于像通过数据库数据来新建或重建索引，实现自定义的DataProvider就ok了。

总结来说，Zoie是个不错的开源项目，会适合一些站内检索需求。至于它的发展如何就很难说了，LinkedIn开源的几个项目都没什么发展，和Facebook形成了较为鲜明的对比，所以Zoie是否会持续发展下去也很难说，需要看社区及其作者是否能推动这个项目。不过，鉴于这个系统并不复杂，应用及扩展成本是可以控制的。