katta--索引的管理者

介绍
katta 是一个运行在许多商品硬件服务器上的分布式应用，它非常类似于Hadoop MapReduce, Hadoop DFS, HBase, Bigtable 和 Hypertable.

概述
主节点服务器管理从节点服务器和index shards任务。从节点服务器服务index shards。客户端允许从所有连接的节点上查找数据，并把所有的结果合并成一个结果返回给客户端。

数据结构
katta的索引是个文件夹，它里面包含一套所谓的index shards（文件形式）。这些子文件包含了Lucene索引。
index shards能够很简单的用Lucene的index writer创建。创建一个katta的索引只不过是把一群Lucene索引拷贝到一个文件夹下。因此katta索引可以用Hadoop map reduce创建（katta提供了一些工具），一台单独的服务器或者什么都可以满足你的要求。
这样我们就可以使用最适合我们的应用的索引结构方式。比如说：把含有常见相关术语的document放在同一个shard里。

主从节点的通信
主从节点的通信在分布式系统中非常重要。主节点必须尽可能块的知道从节点的是否已经挂没挂掉。通常此类的通信使用了心跳消息（heartbeat messages ）来联系主从节点。但是katta使用了一个不同的方法实现。那就是Zookeeper，一个分布式配置和锁定系统，它是YaHoo的研究项目，用来实现主从节点的通信。Zookeeper允许你读写成一种分布式虚拟文件系统——虽然它不是一个真正的文件系统。从节点在启动过程中把一个临时文件写入一个叫“/nodes”的文件夹。主节点同意任何改变这个文件夹，如果一个从节点失败了，那Zookeeper会移除这个临时文件，并且发送一个通知给主节点。一个类似的程序是用来处理主节点的错误虽然这里只有活跃的主节点写了一个“/master”的文件夹，二级masters订阅通知到这个文件。
在katta中，所有的主从节点的通信都是实施了这种机制。
“/index”---当一个新的索引被部署上时写入这个文件
“/nodes-to-shards”---目录保存每一个从节点的文件夹，在每一个文件夹下是这个从节点被分配的索引文件列表
“/shards-to-nodes”---目录保存每一个从节点的文件夹，在每一个文件夹下是这个从节点已经部署的索引文件列表

客户端节点通信
当得到一个查找请求后客户端和从节点通信。为了客户端和节点的通信，我们决定使用Hadoop的RPC，它是一个非常快速的并且易于使用的同步通信的Java实现（Apache的Mina也很快速但它是异步的通信）。对于每个搜索请求，我们向所有节点发送请求的服分享我们的索引中搜索。
所有的请求都是做成多线程的，Hadoop的RPC保持开放的TC P  IP连接。

载入Shards到节点
因为性能在查找中是至关重要的，所以katta首先把shards拷贝到节点的本地硬盘上。
Hadoop的文件系统可以理解所以的URL并把它们当做一个源。比如，“file：” 从一个本地的shards部署一个索引，所有的节点都能访问它。当然，“hdfs：”也能提供部署从Hadoop的分布式系统的一个索引。亚马逊的S3也支持了这——涉及到Hadoop文件系统文件的更多细节。

分布式评分
katta提供了分布式评分——这是因为我们不希望这个词完全平衡的分配所有shards。
每个搜索查询是在Katta中被两个网络往返：首先，我们从所有节点为查询得到文件的频率，然后根据这个值搜索查询到所有的节点访问。请注意，我们还提供了一个简单的计数方法，仅仅是数查询相匹配的文件，但并不表示，在一个网络往返。

集成
Katta提供的Java API管理系统，你可以集成到你的管理和监控应用程序中（具体见Katta的java api）。
Katta还提供的Java API ，可以搜索索引（Client.java ） -这将是一个结合点来连接你的网站或应用程序的搜索结果。
最后， Katta提供了一个命令行工具来管理系统级功能，如部署和取消部署的shards。