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提供搜索服務。
