2014年04月_jollyjumper

原创 Lucene 4.0 TieredMergePolicy

默认的merge policy。findMerges:先将所有段按照扣除删除文档之后的字节数(bytesize * (1.0 - delRatio))降序排,对其中size() > 2.5G(maxMergedSegmentSize / 2)的段排除在外，其他只要不是正在归并的段,加入候选。这个候选的列表如果大于allowedSegCount(allowedSegCount计算方法如下

2014-04-30 13:46:10 2017

原创 git rebase和merge 区别和应用场景

对于两个分支而言，rebase和merge没有区别，但是rebase更干净，因为log hisitory是线性的，但commit不一定按日期先后排，而是local commit总在后面,merge之后history变得比较复杂，但是commit按日期排序,stackoverflow上有个图示很好:http://stackoverflow.com/questions/16666089/whats

2014-04-29 23:10:17 20361

原创 Lucene新版本对ConjunctionScorer的优化

Lucene 4.0版本的DocIdSetIterator中没有cost方法，而4.7.0则有这个方法，表示遍历整个DocIdSet的代价,对于DocsEnum就是其长度了,对于Scorer就可以是符合查询的个数了。ConjunctionScorer可以取其中cost最小的那个scorer,做and操作，而4.0中则是猜测，认为第一个doc最大的那个应该最稀疏，从那个scorer开始做。

2014-04-27 18:11:25 1233

转载重复数据删除技术

应该比较适合wanghttp://article.yeeyan.org/view/156578/109158

2014-04-27 18:10:07 590

原创关于使用Filter减少Lucene tf idf打分计算的调研

将query改成filter,lucene中有个QueryWrapperFilter性能比较差，所以基本上都需要自己写filter，包括TermFilter,ExactPhraseFilter,ConjunctionFilter,DisjunctionFilter。这几天验证下来，还是or改善最明显，4个termfilter,4508个返回结果,在我本机上性能提高1/3。ExactPhrase

2014-04-27 15:48:43 2016

原创关于numa

服务器是numa架构的，有两个node,经测试加入numactl --interleave启动searcher并没有加速。关于numa,淘宝莫枢的slides: http://www.slideshare.net/RednaxelaFX/usenuma-on-jdk6linux指出仅UseParallelGC,UseParallelOldGC可以配合-X:+UseNUMA，可以提高性能(e

2014-04-22 21:34:41 2142

原创使用ByteRef加速String类型DocValues的加载

目前商户索引DocValues非常大,warmup时花费70-80秒(在beta环境),有62秒在加载DocValues,发现其中有54秒时间在加载string docvalues,string docvalues涉及的总数达到138M,平均一个字符串13字节,但如果只是读,只要花费大约2秒时间(之前已经通过cat加入page cache),为什么花这么多时间?大部分时间花在String(byte

2014-04-21 21:42:40 1964

原创 Sun JDK 1.6中String Constructor的一个bug

Java Performance Tuning Guide中看到的: http://java-performance.info/inefficient-byte-to-string-constructor/大致是传递byte array,offset,len, 还有charset时其在内部会arrays.copyOf整个数组(而不是那个slice),这样如果数组本身很大,slice很小,byt

2014-04-21 21:25:17 1066

原创 Lucene TFIDFSimilarity

读了Lucene打分文档之后，有必要了解一下TFIDFSimilarity中的调用堆栈。public abstract class TFIDFSimilarity extends Similarity { public TFIDFSimilarity() {} @Override // overlap overlap

2014-04-20 22:38:06 2790

原创 Lucene TFIDF打分公式

还没读TFIDFSimilarity的代码，读了一下lucene的文档，没有特复杂，感觉还是很严谨的。对于查询q和文档d,假设查询为纯token查询，套用向量空间模型(VSM),相似度度量使用余弦，另外再加一个coord(q,d)即d中满足q中must和should查询条件个数的度量(估计一般是m / n了）。cos直接用向量点积除以两个向量的模(euclidean norm)。cos =

2014-04-20 13:13:32 2865

原创 Java String.intern()相关

为了节约内存，java String中内置intern方法，保留String的弱引用哈希表。在Java 6中这个表放在永久代，永久代的内存配置很固定，而且pool size不可配置，不方便。升级到java7之后，可以使用-XX:StringTableSize(默认1009)设置pool size（为了性能应使用素数)。从参考资料看，只要pool size够大，性能是很不错的。而且相比自己手工写

2014-04-19 23:28:13 1184

原创 vm.overcommit_memory和vm.overcommit_ratio

有两台新配的服务器内存128G,但在空余内存还有20G,page cache 60G时jps启动不了，提示java heap space,c中调用malloc无法分配5G以上的内存，很奇怪。倒是在网上有看到显卡没装风尚导致该问题的,最后换了一个带风扇的显卡就解决的: http://ubuntuforums.org/showthread.php?p=11649751后来同事问了运帷，原来

2014-04-19 18:45:39 14266

原创 KD树

在地图上画一条线，找出沿线一定宽度的POI点，现在的做法时线上取若干点，用kd树保存,查询一个点是否在沿线时，找到kd树中离改点最近的点，判断距离到改点是否小于指定距离，虽然不是很完美（点要取得足够多才能避免落掉一些点)，也不失为解决方法。kd树(k dimension tree)实际上是决策树，每次找区分度最大(方差最大)的一条轴线进行二分，二分至叶子节点只包含一个点，查找最邻近点时先找到叶

2014-04-19 18:11:27 4639 1

原创 Google Dense Hashmap和Sparse HashMap

google code上有个著名的hash map类库，今天看了一下文档,聊做记录:sparse hashmap: 空间高效dense hashmap:时间高效sparse hashmap使用的数组(sparsetable),按M分为一组,每组用数组存储数据(虽然链表速度更快，但空间多),bits做查找。M越大内存overhead越小,在323位机器上是2bits,64位机器上是2.5

2014-04-13 23:30:44 13563

原创圈图的geo query处理解决方案

一般的geo query是在一个点找附近多少米，几公里的poi点，现在有个产品可以在地图上圈一块地方找其中的poi点,“一块”其实是用户鼠标或触屏经过的点组成的多边形(可凹可凸）。目前的做法是找出x,y的最大最小四个坐标，这样构成一个矩形，但矩形不方便直接拿geo hash的grids, 所以取最长边，放大成一个矩形，再取它占用的grids，这样几个termquery最后再加个过滤操作。感觉上

2014-04-13 09:45:06 1591

原创 Lucene中Filter的性能问题

缘起于对geo filter的优化(http://blog.csdn.net/jollyjumper/article/details/23120197),当时模仿lucene的filter写了一个geo filter,其中getDocIdSet返回的时一个FixedSizeBitSet对象，在小的索引（1G）上测试出来性能比之前有明显提升，但在大的索引（23G）上反而比原来更慢。于是改成自己实现一

2014-04-13 08:56:38 1897

原创 Hotspot VM中jit的触发条件

使用-XX:CompilationThreshold来控制，看起来这是循环次数，达到这个数目就触发jit.默认是10000,但在server上1500比较理想(stackoverflow上的说法),实测以下1500跑lucene search的确比默认的略快一些。

2014-04-08 13:38:00 1543

原创 BooleanScorer和BooleanScorer2的差别

几个termquery or起来(全部and起来用ConjunctionScorer),如果collector acceptOutOfOrder返回true,默认使用BooleanScorer,它按照2048一个窗口一个窗口地计算分数，由于nextDocID没有顺序要求，速度较快。如果collector acceptOutOfOrder返回false,则使用BooleanScorer2，归并链表时

2014-04-08 13:36:46 1830

原创 HAProxy

http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#bottom文档大体上看了一遍，转发规则可能没有nginx丰富，但性能更好，支持虚拟主机，更像一个load balancer。最后使用socat连接stat socket也很有意思。

2014-04-08 13:35:35 979

原创关于Lucene Collector

Lucene Collector用于收集搜索之后的文档，可以方便做filter等，主要接口有setScorer,collect,setNextReader,acceptsDocsOutOfOrder。一般和scorer配合使用,acceptDocsOutOfOrder这个选项很重要，表明是否接受doc id乱序，返回true的话对于or操作，不需要从堆中选最小的将快很多，但对于分页时如果指定顺

2014-04-07 19:57:11 3069

原创记Lucene GEO Query的一点优化

目前我们使用的是Lucene 4.0，上面对GEO query的使用是这样的，索引阶段使用geo hash索引多个级别的geo grid,检索阶段获取geo grid做termquery,or起来，最后search之后在collector中按照距离做一次手动的过滤，这样做不方便的是geo query不能任意和其他query做or组合。又查看了lucene spatial中的实现，是直接确定精度

2014-04-07 18:05:33 2447

jollyjumper的专栏