solr是如何存储索引的
调研了一下，发现索引文件的数据结构相当复杂，这个好像是每提交一次建索引，就会将以前已生成的索引重新组织，而且还会生成新文件，所以如果采用在HDFS中追加写索引文件，那工作量将相当大，必须清楚了解索引文件数据结构及索引文件关联，下面有三篇对lucene索引结构的分析，我是没怎么看懂，有兴趣的可以看一下
同理,用hbase来存放搜索索引文件也是不合理的，因为索引文件是分散管理，这些个小文件是互相关联的，每次都得把这些个小文件全取出来，才能正常查询
我现在知道为什么做分布式索引这么难呢?是因为索引小文件的整体关联性，不能随意拆分，我试了一下，如果将重新生成的段去掉后，那就不能正常搜索，它会提示报错，少那个删去的文件。那分布式索引存储可行的方案就三种:
1.直接使用solr自带的分布式功能,即布署多台solr,选好master和slaves就可以了
2.使用HDFS分布式存储索引
3.使用Katta来管理索引
1.因为第一种索引文件是存储在多台机器的物理存储空间中的，而不是存在HDFS中，由于后面要用mahout做挖掘需要HDFS，所以第一种方案不适合
2.因为HDFS不适合存储大量小文件，会带来额外的计算开销。Nutch+solr的方案，也是将索引直接存在HDFS上的，没有考虑索引是小文件的问题，所以第二种直接将索引存在HDFS中并在HDFS中进行查询也是不可取的
参考资料：既然索引文件是必须放在HDFS上的，而且还要避免小文件的问题，那么就只有两种方案可取：
1.直接通过javaapi将solr索引文件目录导到hdfs中，然后用katta来将索引切片
2.用Nutch将索引文件布署到hdfs中，然后用katta来将索引切片
第一种方案的优点是，不需要搭Nutch平台。如果是第二种方案，具说hadoop+lucene=nutch，这样是不是有点重复呢？nutch的一个重要组成部分就是网络爬虫，如果只是用来爬本地磁盘文件，,是不是有点大才小用呢?而且nutch更新索引相当麻烦，,需要修改脚本，而目前我们的系统是有现成数据的，根本用不着nutch。nutch有两种方法实现分布式搜索：一种是将搜索的索引目录，设置在hdfs上；另一种是将索引分散拷到本地，然后用nutchserver设置多个机器监听本地索引目录，后一种种需要手动操作，将索引拷到本地，但这一种更高效，因为好多资料都说不建议在hdfs中直接查询
第一种方案的缺点是每提交一次索引，需要重新导一次索引文件到hdfs中，而且索引文件是调solrj来生成的，这个性能如何是未知的
第二种方案的优缺点自然就和第一种相反喽，第二种方案,还需要解决一个问题，那就是当上传一个新文档到gluster的时候，如何更新索引由于前面一直是在基于solr的基础上做的，,并且已经实现当新文档传到glusterfs中时，利用solrj来更新索引，所以想采用第一种方案，更新索引后，将索引文件同时提交到hdfs上，然后用katta来切分和管理索引