solr索引如何存储

我发现一直理解错了，我一直以为分布式索引和分布式搜索是两个不同的事情，其实是一样的.把索引分布在多台计算机上，不就是正好实现了分布式搜索吗?既然索引已经分布式存储了，,因为搜索就是基于索引的，那搜索就自然是分布式的啦。.前面看网上一些理解，一直以为分布式索 引和分布式搜索是两个独立分开的过程，不知道理解的对不对? 

 

调研了一下，发现索引文件的数据结构相当复杂，这个好像是每提交一次建索引，就会将以前已生成的索引重新组织，而且还会生成新文件，所以如果采用在HDFS中追加写索引文件，那工作量将相当大，必须清楚了解索引文件数据结构及索引文件关联，下面有三篇对lucene索引结构的分析，我是没怎么看懂，有兴趣的可以看一下

1. http://www.cnblogs.com/mikehe1117/archive/2006/08/02/466264.html

2. http://blog.csdn.net/pangliyewanmei/article/details/5721113

3. http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623597.html

同理,用hbase来存放搜索索引文件也是不合理的，因为索引文件是分散管理，这些个小文件是互相关联的，每次都得把这些个小文件全取出来，才能正常查询

我现在知道为什么做分布式索引这么难呢?是因为索引小文件的整体关联性，不能随意拆分，我试了一下，如果将重新生成的段去掉后，那就不能 正常搜索，它会提示报错，少那个删去的文件。那分布式索引存储可行的方案就三种:

1.直接使用solr自带的分布式功能,即布署多台solr,选好master和slaves就可以了
2.使用HDFS分布式存储索引
3.使用Katta来管理索引

1.因为第一种索引文件是存储在多台机器的物理存储空间中的，而不是存在HDFS中，由于后面要用mahout做挖掘需要HDFS，所以第一种方案不适合
2.因为HDFS不适合存储大量小文件，会带来额外的计算开销。Nutch+solr的方案，也是将索引直接存在HDFS上的，没有考虑索引是小文件的问题，所以第二种直接将索引存在HDFS中并在HDFS中进行查询也是不可取的
参考资料：

1. hadoop如何处理小文件

既然索引文件是必须放在HDFS上的，而且还要避免小文件的问题，那么就只有两种方案可取：

1.直接通过java api将solr索引文件目录导到hdfs中，然后用katta来将索引切片
2.用Nutch将索引文件布署到hdfs中，然后用katta来将索引切片

第一种方案的优点是，不需要搭Nutch平台。如果是第二种方案，具说hadoop+lucene=nutch，solr也是基于lucene的，这样是不是有点重复呢？nutch的一个重要组成部分就是网络爬虫，如果只是用来爬本地磁盘文件，,是不是有点大才小用呢?而且nutch更新索引相当麻烦，,需要修改脚本，而目前我们的系统是有 现成数据的，根本用不着nutch。nutch有两种方法实现分布式搜索：一种是将搜索的索引目录，设置在hdfs上；另一种是将索引分散拷到本地，然后用nutch server设置多个机器监听本地索引目录，后一种种需要手动操作，将索引拷到本地，但这一种更高效，因为好多资料都说不建议在 hdfs中直接查询

第一种方案的缺点是每提交一次索引，需要重新导一次索引文件到hdfs中，而且索引文件是调solrj来生成的，这个性能如何是未知的

第二种方案的优缺点自然就和第一种相反喽，第二种方案,还需要解决一个问题，那就是当上传一个新文档到gluster的时候，如何更新索引

 

开源项目 Lily和 Nut中也没提到如何存储及分发搜索索引

由于前面一直是在基于solr的基础上做的，,并且已经实现当新文档传到glusterfs中时，利用solrj来更新索引，所以想采用第一种方案，更新索引后，将索引文件同时提交到hdfs上，然后用katta来切分和管理索引

参考资料:
1. 关于Nutch切分索引  (这篇文章有说各种查询消耗)
2. nutch-1.0 的分布式查询部署   (这篇文章里明确提出用hdfs来做查询不切 实际,用的是将索引从HDFS上拷到本地,多个机器监听本地索引目录)
3. How to Setup Nutch (V1.1) and Hadoop    (这篇文章是搭建nutch的分布式搜索)
4. nutch+solr  

5. nutch分布式配置与安装   

6. Nutch本地索引更新策略