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

从前 发布于 2013/07/04 17:31
阅读 14K+
收藏 6

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

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

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

各位谁有经验,指点指点?

加载中
0
烟花人
烟花人
两种折中考虑,根据你实际业务
无夏之年
无夏之年
两者根本就是两回事,要么用这个,要么用那个,还怎么折中呀
0
曾杰
曾杰
solrcloud 你值得拥有
0
leon_rock
leon_rock

刚入手solr 飘过 

0
jiacai2050
jiacai2050

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

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

从前
从前
嗯,谢了。这个之前看到过的。暂时放弃 lucene + hadoop,暂时用不上 lucene索引的mapreduce,现在solr 4.4已经支持 hadoop了,不过不太成熟
0
l
liuhongtao
solrcloud 这个咋样。   katta 呢?
0
momoHuang
momoHuang

但有人提到 solr的分布式有一些缺点没有全局的Lucene评分机制中的idf、lengthNorm因子

------------------

这个应该是有的啊

0
x
xto

 

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索引目录,整个过程在于加快全量索引生成效率。

x
xto
回复 @从前 : 纯粹研究的话,用这个方案都没问题,甚至能够支撑小规模级别的应用。但这个似乎没太大意义。
comeonniu
comeonniu
回复 @从前 : 能否高速一下链接?
comeonniu
comeonniu
如果是纯粹做研究的话,是否可采用HBase+Lucene?
从前
从前
嗯,对的,淘宝有个系统的方案和你最后讲的思路是一样的。但具体实现起来很复杂。 我最后放弃lucene+hadoop的方案了,采用的solrcloud,目前来说能够解决大部分问题
0
hya1985
hya1985

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

0
w
wangshaohua10
elasticsearch 是基于lucene的分布式搜索,你可以选择
返回顶部
顶部