- 浏览: 78991 次
- 性别:
- 来自: 广州
最新评论
-
zaytay:
赞,正好解决遇到的问题
使用IndexMergeTool后,导致solrcloud的主从同步失败的解决方案 -
solrer:
rows=100+10
Solr性能优化之merger的合并方式优化 -
nouuid:
思路有点问题,不能保证【最新1W】
Solr性能优化之merger的合并方式优化 -
kernaling.wong:
whz137458 写道我觉得你思路有问题!(A&&a ...
我在工作中的Lucene中关于 MUST , SHOULD的一个想法 -
whz137458:
我觉得你思路有问题!(A&&(B||C))|| ...
我在工作中的Lucene中关于 MUST , SHOULD的一个想法
文章列表
早几天写的文章那里,对域名的搜索那里 http://kernaling-wong.iteye.com/blog/2212191 ,这几天经过实践,有了新的认识所以想补充一下.
简单说说上个文章表达的,其实就是对域名进行搜索,比如输入it.com ,则不希望出现类似 ...
solr 对网站域名的搜索技巧应用
- 博客分类:
- java
菜鸟级文章,高手请绕道.
基本事情背景是这样, 在公司的抓取回来的数据中,都有大量的来源不同网站的域名.这时用户可能只对某几个来源网站感兴趣,或者对某几个来源网站不感兴趣之类,以前的版本中,只对网站域名做了非常简单的分词,基本上可以认为是对 www.it.com.cn 之类的网站,通过 "." 把域名拆开,然后索引.这样用户在搜索某几个域名的网站,直接就可以匹配到了.
但这样形式在最近用户提出的问题中需要处理了. 原来当时我们理解用户的要求有点偏差,其中主要是集中两个问题
1. 比如用户搜索来源于 www.it.com ...
开端与场景
接着上一篇文章的地区分词匹配,最近发现有一些内容中全部为英文或者直接就是一些连接URL,理论上根本不可能产生地区特征的关键字,之前的做法却把这些也进行了分词和匹配了。所以一个比较高效的方式就是把文章内容中非中文的字符过滤掉。
集群的数据存储了约8亿的文章,现在进行一次索引的 rebuild .
这涉及了一个对中文字符的判断及过滤了,想必大家对此也很多想法。网上也介绍了几种方式。这里不讨论是否能实现的问题,是讨论实现速度最快的的问题。
方法一:
也是网上最多人使用的方式通过正则表达式,方便又快捷
...
在使用 solrcloud 的时候,很多人都会使用主从同步实现负载均衡与索引的容错性,当索引经过修改,删除或者新增了数据后,索引的段数会不断增多,累积得越多,索引的搜索速度越慢.这时很多人都会提出使用 optimize 优化索引.没错,这一个的确是一个相当重要的手段,而且 solrcloud 也提供了相关的功能即可.本来看似很简单就能解决的问题,深究下去,还是有点意思的.再来一种情况就是,有时候需要把几个 code 合并成一个大的 core ,当然了solrcloud 也有提供相关的功能.但似乎实际用起来并非这么的顺手.出现很多类似时间超时,连接超时等一大堆的问题.
...
使用快速分词匹配地区
- 博客分类:
- java
需求的提出
现在的公司数据集群中,已经存在约8亿的数据,现在有一个业务的要求如下,
1. 比如搜索"广东",则需要把包含广东以下市,区,镇,街道等的所有的关键字都给匹配出来.
2. 同时,搜索"天河",则需要返回一个"广东 广州 天河" 这样子详细的路径出来.意思不能是简单的关键字匹配,因为它有地区的层次归属.
3. 比如文章中含有"朝阳",则全国地区中只含有"朝阳"的,: 吉林 长春 朝阳, 辽宁 朝阳, 北京 朝阳,都要全部返回.
4. 如果 ...
最近公司在开发一个功能,具体需要用到这些精确到乡镇及街道.但网上并没有现成并格式化好的列表.所以通过抓取某网站的地区列表取得这个地区列表,精确到乡镇及街道.同时在抓取过程上,因为对方后台网站做了防抓取限制,结果需要做了很多采集工作才能完成.分享一下,让更多人省去这些麻烦的事情.
一共4万4千多的数据
全国地区列表格式(精确到乡镇与主要街道),格式1
地区列表格式(精确到乡镇与主要街道),格式2
欢迎转载,请注明来源作者及文章连接.谢谢.
http://ke ...
现状
当 solr 集群采用了 merger 的合并方式后,会把各台 solr 的结果合并到最终结果并输出,如下图所示:
这种是非常常规的做法,我想各路大神也早明白大概的情况了,那我也不多说了
集群的基本情况就是,因为收录了大量的新闻信息,某些新闻可能某一个小时间段内插入了大量数据,而某些时间段却木有,比如:“车祸“这一个关键字,在早上的9点1分1秒添加了 10W + 条数据,但其他时间段却一条都没有,但因为入索引时采用了轮询的方式,可以认为相同所有关键字在每台 solr 的数据量近似一样。简单一句话,每一个台solr 对应关键字的文档数差不多,但关 ...
最近公司的其中的一个集群的solr出现了一个比较奇怪的事情,先简单说说以下的情况
机器A是前端的逻辑应用
机器B是具体一个 solr 应用
很通用的方式都是从机器A向机器B的 solr 拿搜索结果并呈现给前端,机器A与机器B处于千兆局域网络。
前端的同事反应有时候, solr 返回的 QTime 很快,但实现搜索出来的结果时间却很久,我大概画了一个图,让大家更明白。
如上图所示,前端的同事在请求 solr 的方法前后加了时间计算,就是请求的所有时间,再前去 solr 反回的 QTime ,则就是网络的响应时间了。前端的同事发现,有些情况下,当然不 ...
在搜索的应用中, bitset 的应用相当广泛,而且是 java util 包下面标准的类,很多人也会首先使用,一般都用于记录对应的 document id 有没有选中,除了这一个解决方案,还有通过 new 数组[] 这样子的方式去记录,其实道理都大同小异,都是通过数组的下标确定对应的 document id 有没有选中。
BitSet性能其实不够好
功能差别上基本相似,但问题是性能方面如何?对于搜索应用,速度是搜索应用的生命,特别在大数据方面。我们不妨对此做一个测试,一个 bitset为1000W 的数组,遍历 10次
...
简单说搜索个过程,Lucene 在搜索的程序简单分成两部分,搜索与排序。高手请忽略下面我的讲解。
搜索:
通过倒排的索引找到对应的 docId 集,拿出来,通过 Collector 类的实现类中的 collect(int docId )
就可以拿到了。
排序:
因为拿出来后,还有一个排序的过程,现在我们只讨论按某 ...
每一个人(至少自己是这样子)都希望过上安稳的日子,于是不断去追求安稳的日子。一旦得到了,自己却发现这也不是自己想要的。
从离开刚毕业的第一家待了3年多的公司后,到现在过去2年多的时间了,2 ...
开场白:
这段时间网站搜索功能并不稳定,觅学网 http://www.51mixue.com/ 提供的图书馆搜索功能经常处理停顿或者不稳定的状态,但之前一直都能稳定下来。现在却不行了。
找问题:
网站的图书搜索返回的速度相当比较慢。但内存也有几百M的空闲,所以,不会是内存问题,CPU占用也非常低。到底是什么问题?
解决:
我发觉在更新索引的时候,出现一个很奇怪的现象,就是索引进程式一直停顿在,或者进行得非常慢。不但占用了内存,而且,建立索引是一个硬盘操作。。。所以我怀疑可能是linux的磁盘IO满了,导致其他程序使用磁盘的时候,却在等等了,而且,会遇到一个情况,就是 ssh 去 ...
开场白:
如果应用服务需要多台机协作的时候,但只是一些小应用,并不需要劳烦到分布式这样。举一个例子,现在有分布在A机,B机,C机,需要向D机的数据写入数据,但是呢,写入数据的时候,要写入一个记录的更新时间,大家知道A机,B机,C机上的时间并不一定相同的,有可能相差数十秒的时间,所以需要马时间统一起来,
如何做?
其实看到我的标题,再加上刚才说的问题,大家都应该知道怎么做了,因为A机....C机,他们都需要连接到目标机器数据库,所以,可以在数据库连接那里,多写一个函数,专门用来执行 "SELECT NOW() "语句,这样,就会返回类似 "2010-09-12 1 ...
cron 的用处我就不多说了,最近,在做这样的一个事情,索引进行中,要间隔20分钟就会把索引更新一次,即,索引程序会 sleep 20分钟,但要知道 lucene 的 IndexReader 把硬盘的索引缓存到内存,说明了,就算 sleep 过程中什么也没有做,此索引程序还是占用了系统的内存了。而事实上,我们却希望在休眠期间释放其索引占用的内存。当然我们先要分析一下利弊。
利:
1。 索引程序退出了,即调用了System.exit(0);方法,表示整一个程序退出,那当然是其使用的内存全部释放掉。
2。 在现在约200W的数据量来说,虽然不说得上很大,但其也占用了近1G的内存,至少,释放掉这些内 ...
开场白:
Mina 是一个韩国人写的基本java NIO的一个高性能的传输框架,我们的搜索就是基本它作为一个搜索服务开放接口了。对于系统的TIME_WAIT过多,造成服务器的负载过高,这个问题我也不用多说了,这段时间发现搜索服务器上的TIME_WAIT过多,我们每天大约总处理70W左右的搜索请求,虽然不多,但是造成了TIME_WAIT很多,有好几千个,可以 netstat -antu | grep :端口
就知道了。(安全起见,端口作了模糊处理)
开始:
其实网上很多解决方法的,
1.
就是在启动的脚本文件里面加上 ulimit -n 1024 或者更多就可以了,其实是治标不治本的 ...