katta文档

katta文档

http://katta.sourceforge.net/documentation/how-katta-works

 

 

Lucene另一种分布式搜索是使用Solr（本人 不太熟悉Solr）。所有的更新是在Solr的主服务器，通过cron自动分发到搜索服务器。搜索通过只定shards的 host:port/base_url分发到各个搜索服务器。url例子：http://localhost:8983/solr /select?shards=192.168.1.27:8983/solr,192.168.1.28:8983&q=solr。缺点是没有 全局的Lucene评分机制中的idf、lengthNorm因子，没有节点失效处理机制。由于分发document到shards使用 uniqueId.hashCode() % numServers机制，可扩展性大打折扣。最近Rackspace结合Sorl，Hadoop和Tomcat来搜索邮件日志数据，文档中看不出使用何种机制失效处理机制等。

 

在Hadoop的wiki中提到由HP Lab实现的Distributed Lucene，但是自从08年5月18日提交了一次source后就没了下文。

 

Katta分布式搜索是101tec.com贡献的一个开源项目。主要目的提供高有效性的搜索服务，并提供负载平衡。Katta使用zookeeper保 证主节点和搜索节点的有效性，指派索引文件给搜索节点，察觉搜索节点的失效。每一个搜索节点在启动时往zookeeper的“/nodes”节点写一个短 暂的znode。主节点设定watch事件察觉这个znode的变化。即当节点和zookeeper server连接断开时，zookeeper自动把这个znode删除，并通知主节点。同样，相同的程序处理主节点失效。当前只有一个活动的主节点往 zookeeper中写“/master” 这个znode。备用的主节点设定watch事件察觉这个znode的变化，并把自己变成活动的主节点。当有新的索引被部署时在zookeeper中 “/index” znode下添加一个znode，主节点把这个索引分配给搜索节点。“/nodes-to-shards”目录保存每一个搜索节点的znode，在每一个 znode下是这个搜索节点被分配的索引文件列表。“/shards-to-nodes”目录保存每一个搜索节点的znode，在每一个znode下是这 个搜索节点已经部署的索引文件列表。

 

Katta现阶段没有实时更新。（正在计划，可能类似于Dynamo， 更新的一致性，采用类似于 Quorum 系统的一致性协议实现），没有LRU或LFU缓存策略。其分布式TF-IDF的解决方案：分为两次发送请求。首先向每个搜索节点发送获取document frequency（只读取tis文件）的请求，然后再向每个搜索节点发送搜索请求，把document frequency和query一起发送。

 

在Hadoop的contrib中的index是使用MapReduce建立Lucene索引的，不是用来搜索用的。

 

通过上面的软件，我们可以建立一个自动化的搜索服务。建立一个web控制服务器来监控整个过程。先使用hadoop的MapReduce来建立索 引，在提交job是设定job.end.notification.url到我们的控制服务器，控制服务器接受到建立索引的任务已经完成，就可把索引分配 给Katta提供搜索服务。