基于Lucene的分布式搜索方案，solr 还是 lucene+hadoop好点

Question

最近要实现一个分布式搜索框架，但不知道那种方案较好，经验较少。下面是一点初步了解，

第一种：采用 solr 的分布式功能。 由于最初设计的是index 的build 和search 是分离的，solr在这块就鸡肋了，所以这里主要采用solr的分布式功能，但有人提到 solr的分布式有一些缺点：没有全局的Lucene评分机制中的idf、lengthNorm因子，没有节点失效处理机制，而且性能上在亿级别？

第二种：采用 hadoop 和 Lucene。 主要考虑是 数据存储目前考虑用hbase ， 本身 Lucene的 index build和search过程是分离的，hadoop 处理分布式方面的，但是就是提高了项目的复杂度。

各位谁有经验，指点指点？

Answer 1

elasticsearch  天然分布式，简单易用，同时支持节点失效，集群自动回复等等！elasticsearch.org

Answer 2

elasticsearch 是基于lucene的分布式搜索，你可以选择

Answer 3

嗯，对的，淘宝有个系统的方案和你最后讲的思路是一样的。但具体实现起来很复杂。 我最后放弃lucene+hadoop的方案了，采用的solrcloud，目前来说能够解决大部分问题

Answer 4

如果是纯粹做研究的话，是否可采用HBase+Lucene？

Answer 5

回复
能否高速一下链接？

Answer 6

回复
纯粹研究的话，用这个方案都没问题，甚至能够支撑小规模级别的应用。但这个似乎没太大意义。

Answer 7

lucene索引数据放在哪里？

放在hbase，hbase是典型的key-value存储，不适合跨行事务。虽然在随机读取方面借助缓存有优势，但如果一次事务读取key太多，延迟也挺低的。我在hbase上面存储lucene index以及借助hbase机制重新设计lucene index，性能始终不是特别好。

如果lucene+hadoop，索引数据存储在hdfs，而hdfs目前并不适合大量小文件存储。lucene索引过程涉及大量索引小文件合并，而且hdfs设计目标也并不是一个实时流读写系统，因此对于lucene核心的near time index也是个挑战。

生搬硬凑在一起玩玩可以，产线恐怕还真要慎重。　　

目前最成熟的都是通过hadoop mapreduce生成索引先存储在hdfs,然后从hdfs将索引下载到本地的solr索引目录，整个过程在于加快全量索引生成效率。

Answer 8

solrcloud 这个咋样。   katta 呢？

Answer 9

嗯，谢了。这个之前看到过的。暂时放弃 lucene + hadoop，暂时用不上 lucene索引的mapreduce，现在solr 4.4已经支持 hadoop了，不过不太成熟

Answer 10

http://www.zhihu.com/question/19793393

LZ这个问题曾经也尝试过，上面的讨论帖子对你应该有帮助，希望回答不是太晚

Answer 11

刚入手solr 飘过 

Answer 12

solrcloud 你值得拥有

Answer 13

两者根本就是两回事，要么用这个，要么用那个，还怎么折中呀

Answer 14

两种折中考虑，根据你实际业务