开源分词程序ki-analyzer启动
Posted in framework on 六月 18th, 2011 by kafka0102
ki-analyzer 是基于ik-analyzer 修改而来的分词程序，所以名字上只是简单的变了一下，源码方面还是沿用了ik的包名等。之所以在ik-analyzer之上山寨另一个轮子，也实在是因为我的需求ik-analyzer不能很好满足，并且功能、设计、改动方面较ik-analyzer有很大出入，所以另起山寨。ik-analyzer项目现在还活着，前不久发布了新版，貌似只是源码实现细节的调整，项目也不是很活跃。当然，国内的几个开源分词程序基本都停滞了。ki-analyzer程序是上周修改的，这周实际测试了一下，只能说bug方面基本稳定，但尚需进一步检验。因为一些想要的功能暂时还用不上，所以也没着急做。关于ki-analyzer的详细情况可以参考项目首页信息，对该项目感兴趣或有问题的朋友可以联系我。
Double.NaN != Double.NaN
Posted in java on 五月 20th, 2011 by kafka0102
昨天做数据时发现个很诡异的情况，当然，再诡异的技术现象也有起发生原因。抛开我的问题来说，我可以再提出个问题：是否在某种编程语言中，存在着那么一个变量i，使得i!=i成立，也使得while(i==i);可以成功的退出？如果你想到并理解了，你可以终止阅读这篇可能冗长的文章，尽管为了填补这个月的博客空白我刻意小题大作一番。在java语言中，Double.NaN就能使得上面两个表达式成立。
理解mongodb的ObjectId
Posted in nosql on 三月 8th, 2011 by kafka0102
mongodb支持的数据类型中，ObjectId是其自有产物，本文对其做些简单的介绍。
存储在mongodb集合中的每个文档（document）都有一个默认的主键_id，这个主键名称是固定的，它可以是mongodb支持的任何数据类型，默认是ObjectId。在关系数据库schema设计中，主键大多是数值型的，比如常用的int和long，并且更通常的，主键的取值由数据库自增获得，这种主键数值的有序性有时也表明了某种逻辑。反观mongodb，它在设计之初就定位于分布式存储系统，所以它原生的不支持自增主键。而现实的世界是，大量应用在可预见的时空里并不需要分布式的mongodb，所以网上就出现了大量的实现mongodb自增主键方法的文章。恩，我之前也干过这种事情。
夜说mongodb
Posted in nosql on 二月 17th, 2011 by kafka0102
赋闲以后很长没有更新博客了，说忙完全是借口，多半因为没有兴致所致。今天凌晨比赛多多，趁着比赛的前奏和间隙，遂浏览些技术文章。发现了 highscalability.com整理出了wordnik使用mongodb和scala的使用经 验：http://highscalability.com/blog/2011/2/15/wordnik-10-million-api- requests-a-day-on-mongodb-and-scala.html。这个wordnik也算是mongodb的先驱应用者之一，并贡献了一些管理工具给社区，去年的mongoSF大会也有它的参与：http://www.slideshare.net/fehguy /migrating-from-mysql-to-mongodb-at-wordnik。
searchblox–一个基于lucene的搜索产品
Posted in search on 十二月 8th, 2010 by kafka0102
前两天在solr邮件组看到一封广告帖，一个叫searchblox的搜索产品可免费使用，好奇心驱使我简单了解并使用了一下。searchblox是基于lucene的搜索解决方案，现在的版本已经是6.1,看来也有些年头了。searchblox不是个开源产品，有免费的版本，也有收费的版本，看文档介绍，收费版本除了提供服务支持还多了复制功能。
Solr复制bug一例：Unable to move index file from tempfile to indexfile
Posted in solr on 十一月 24th, 2010 by kafka0102
22日下午3时多，收到搜索系统的报警邮件，错误日志如下：
[2010-11-22 15:16:14][ERROR][pool-6-thread-1][SnapPuller.java(650)]Unable to move index file from: /indexpath/index.20101122031500/_21.frq to: /indexpath/index.20101122031000/_21.frq
SnapPuller是Solr复制用到的一个类，我对它做了一些修改，所以把它挪到我的代码里了。报错的代码片断如下：
httpclient的并发连接问题
Posted in java on 十一月 20th, 2010 by kafka0102
昨天的搜索系统又出状况了，几个库同时重建索引变得死慢。经过一个上午的复现分析，确定问题出现httpclient的使用上。搜索系统在重建索引时，是并发多个线程（默认是8个）不停的从PHP客户端取数据（当然，从另一个角度来说，搜索系统是客户端，PHP端是服务端），取回后放到一个队列里由单独的一个线程更新索引。在测试环境复现发现，对于一个请求，PHP端打印耗时是1-2秒，但搜索端打印在4-6秒。这种耗时差别也就两种可能性，一个是PHP端返回到搜索端接受完耗时太长，另一个就是搜索端在真正发给PHP端数据前等待了很久。因为有了之前的jetty7的困顿，起初我怀疑是传输数据的问题。因为请求数据的代码部分我只是简单的使用了httpclient，所以只能从httpclient着手分析。我想到把PHP端和搜索端的请求起始和结束时间都打出来对照一下，不过在这样做之前我把搜索端的并发请求线程数调到了1,看下单线程情况下效果如何，结果惊奇地发现PHP端和搜索端的耗时相近。所以，可以确定，是httpclient的并发连接处理上可能存在问题。
solr拾遗：引用计数
Posted in solr on 十一月 13th, 2010 by kafka0102
据我不完全统计，solr代码中使用引用计数的用途有两种：一个是引用资源，一个是引用对象。技术上来说引用计数的使用没多少可大说的，不过如果没有正确的close获得的资源和对象，泄漏的bug就出现了。
oracle提升mysql售价，误解与无视
Posted in mysql on 十一月 7th, 2010 by kafka0102
前几天就在twitter上看到oracle提升mysql售价的消息，推上的英文圈对oracle的这一举动议论纷纷，但中文圈很是平静，倒是像 csdn、javaeye这样的媒体做头条报道：Oracle提高了MySQL的售价。这一新闻难免又引起大家对mysql前景的悲观，对迁移存储系统到postgre、nosql等蠢蠢欲动。其实多数mysql使用者可以轻松的忽略这一新闻，因为人家 oracle提价mysql影响的是买收费版本mysql的用户，并不会影响我等使用免费版本的用户。
solr拾遗：CopyField
Posted in solr on 十月 30th, 2010 by kafka0102
solr的index schema中，除了支持基本数值类型的field，还支持一些特别的field，比如较常用的CopyField。以下面的schema配置片断为例：
<schema name="eshequn.post.db_post.0" version="1.1"
xmlns:xi="http://www.w3.org/2001/XInclude">
<fields>
<!– for title –>
<field name="t" type="text" indexed="true" stored="false" />
<!– for abstract –>
<field name="a" type="text" [...]
各种java序列化工具性能对比
Posted in java on 十月 24th, 2010 by kafka0102
看到一个很不错的工具http://github.com/eishay/jvm-serializers/，可以用它来评测各种流行的java序列化反序列化工具的性能，使用上也很简单。想试试该工具的，下载源码后参考起README操作即可。而我更关心的是，是各种工具的性能对比，以作选择的一个衡量标准，也就是http://github.com/eishay/jvm-serializers/wiki的图示和数据。本文也就简单转摘其图示，图示中的java-manual指的是根据对象（数据）格式手工操作（当然是最快的，但不具有通用性），java- buildin-in就是内置的序列化方式（ObjectOutputStream、ObjectInputStream），其他工具的使用版本可以查看其wiki。
mysql的多线程复制
Posted in mysql on 十月 24th, 2010 by kafka0102
对于使用主从复制的mysql用户来说，经常会遇到的问题是，当主库的写压力增大时，基于单线程复制的从库跟不上主库的写速度，造成应用从从库读到脏数据。如果在数据库前面使用了cache，那么这种脏数据的影响就更恶劣。更糟糕的是，如果在主库上执行了耗时很长的sql，那么从库就会被完全阻塞，这也限制了程序员们不要在主库执行耗时长的语句，更不要提那些alter schema的语句。对于mysql主从的这个缺陷，可以使用一些其他方式规避它，比如做sharding处理，控制每个master的写压力在合适的范围内，也可以去主从，通过应用来分发请求到各个db（应用相当于主库），但这些做法相比复制无疑会复杂的多。
solr filter query的误用
Posted in solr on 十月 22nd, 2010 by kafka0102
在我整理solr SolrIndexSearcher性能问题分析的时候，我就在想，我是不是误用了SolrIndexSearcher，才出现我所以为的性能问题。当我想到其实现特点，我恍惚确定确实是这样的，根源就是我误用 filter query。上篇文章暂且放下，这篇做个补充。如我上文所述，fq=fid:1这个条件匹配的文档数会很多，不过，如果开启了filter cache，那么只会在第一次调用时慢些，后续的调用都会命中cache而提升速度，而通过query预热是可以解决初次调用的低速问题。所以，如果要使用filter query，就要开启filter cache，并确保filter cache能容纳所有的filter query。这也需要对应用的查询特点做好分析。以fq=atm:[int_time1 TO int_time2]为例，我之前是将它放到filter query中，不过因为每次查询的int_time1和int_time2都几乎不相同，使得总不能命中filter cache，严重影响了查询性能。另一方面，我在做压力测试时也发现，当filter query结果充满了filter cache，最终使得程序内存耗尽。
solr SolrIndexSearcher性能问题分析
Posted in solr on 十月 21st, 2010 by kafka0102
基于solr的新搜索系统已经使用了有段时间，不过之前上的几个库都很小，也没发现什么性能问题。最近上了thread和post库后，性能问题显现出来。这段时间解决的性能问题有好几个，本文只着重于SolrIndexSearcher的search问题。thread库索引大小有400M多，记录数有400多万，原来的基于lucene的系统的查询处理耗时一般在10-30ms，而同样的请求，新系统耗时在50-100ms。而post库索引大小有 6G多，记录数有3000多万，旧系统的查询处理时间一般在30-80ms，而新系统往往需要400-800ms，性能差距还是很明显的。
因为SolrIndexSearcher是基于lucene的IndexSearcher，想必应该是青出于蓝胜于蓝，并且其wiki上给出的性能数据也很不错，所以当我把新系统做完后并没有去细致的测试其性能。但现在系统的性能相比之下确实有些差，并且因为要做多个库的整合搜索，就要避免像thread 这样耗时长的库就成为短板。总之，问题需要定位和解决。
分享：Scalable System Design Patterns
Posted in architecture on 十月 17th, 2010 by kafka0102
Scalable System Design Patterns 一文概括了几种常见的系统设计模式。配图很漂亮，我就索性摘过来，推荐感兴趣的继续围观其博客。
twitter的新搜索架构
Posted in lucene, search on 十月 10th, 2010 by kafka0102
当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇 Twitter’s New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如 新 Twitter，新搜索，我在这也就算是炒冷饭了。
Is Terracotta’s BigMemory a big thing?
Posted in java on 九月 30th, 2010 by kafka0102
Terracotta最近推出了个新东西–BigMemory，使得Infoq上的这篇Terracotta’s BigMemory Aiming to Eliminate Garbage Collection for Java Caches文章引来长长的争论。像GigaSpaces、Infinispan等和Terracotta有竞争关系的商业或开源的对手，对BigMemory的诸多方面提出了疑问和质疑。如果BigMemory真的如Terracotta吹的那般好，那些竞争对手该情何以堪？就算它真的好，也要挑出它的不是，比如就有评论说现在都分布式年代了，还搞什么单JVM实例优化？暂且放下这些争论，看看BigMemory是个怎样的东西，值得大家如此大动神经。
Facebook的Online Schema Change for MySQL
Posted in mysql on 九月 29th, 2010 by kafka0102
Feng的 Facebook 针对 MySQL 开源 Online Schema Change 代码 介绍了 Facebook最新开源的在线修改mysql schema的工具，并对该工具极尽赞扬之辞。于是乎，我这个有大半年没动过mysql的人翻看起该工具的文档Online Schema Change for MySQL，并简单的浏览了其代码OnlineSchemaChange.php。总的来说，尽管其实现思想很朴素，这个工具真的很实用，它借鉴的openark-kit似乎发布了很长时间，只是名头没有Facebook的guys响亮，知道的人似乎不多。openark上的其他工具也很不错，比如ycheckpoint，就是个很不错的监控mysql运行状态的工具。
分享：Playfish’s Social Gaming Architecture
Posted in architecture on 九月 22nd, 2010 by kafka0102
highscalability.com上的Playfish’s Social Gaming Architecture – 50 Million Monthly Users and Growing是篇很不错的大杂烩，内容涉及全球第二大social game公司Playfish的技术架构、产品设计、团队协作、产品运营等诸多经验之谈，尤其对初创团队很有借鉴意义。我这里还只是对文中提到的一些技术经验做些汇总，也推荐大家去浏览原文，重点看看自己感兴趣的段落。但说起架构的事情，其实看多了，往往都是大方向上相似，细节上有自己的考量和特点，以形成自己的架构风格。
mongodb MapReduce使用初步
Posted in nosql on 九月 18th, 2010 by kafka0102
最近在做搜索的查询日志的统计分析，对每一条查询统计日志，我将其解析出来后以特定字段格式存在mongodb中，定时调度做些统计分析。其中有个需求是，统计某个时间段（每天、每周、每月）各个query的查询次数，展示上就是热门查询query了。考虑到处理的数据量不会很大，解决方法也可以简单来之。我现在使用的方法就是mongodb的MapReduce功能，其实这个需求也可以认为是个group操作，而mongodb的group功能就是基于MapReduce的，但group对结果集的大小是有限制的。本文就针对一个示例介绍一下mongodb MapReduce功能。
[Solr实践]自定义SolrEventListener实现searcher的autowarm策略
Posted in solr on 九月 5th, 2010 by kafka0102
Solr的searcher autowarm（预热）有两个时机，一个是系统启动时（firstSearcher），一个是使用新的searcher替换旧的searcher时（newSearcher）。Solr支持在solrconfig.xml中对SolrCore配置SolrEventListener来实现自定义的autowarm。通常来说，Solr提供的默认实现QuerySenderListener就够用了。在我的需求中，希望solrconfig.xml中配置的SolrEventListener是针对多个SolrCore的，这要是因为我的多个SolrCore共用了一个solrconfig.xml配置。就配置autowarm的查询query来说，简单的就是配置一个常见的query，但如果系统有排序查询（sort），可以配置适宜的sort条件以预热lucene的fieldCache。下面是我自定义的SolrEventListener，效果是，如果SolrCore没有配置query，就使用default的，否则使用自己的。
Solr之困
Posted in solr on 八月 22nd, 2010 by kafka0102
重写公司的站内搜索。经过前期一段时间对lucene和solr的熟悉，最后决定使用Solr作为新系统的基础框架。现在已经是第一阶段开发的后期，核心代码行数有11000+（不包含admin及client等）。现已实现的功能要比已有系统要丰富些，但综合比较两个系统总的代码量，其实新系统并不多得太多。新系统使用Solr代替了已有系统实现的部分功能，这减少了新系统的代码量，同是新系统实现了已有系统不具有的功能，也增加了一些代码量。开发的这段时间，因为新系统中很多代码是独立于Solr的，所以和Solr的交互也是时断时续，以使得即便到了开发后期我还能发现Solr实现的一些细节带给我的困扰。
HttpClient的“Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.”警告释疑
Posted in java on 八月 21st, 2010 by kafka0102
使用HttpClient，总是报出“Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.”的WARN日志，定位到HttpClient的源码如下：
public byte[] getResponseBody() throws IOException {
if (this.responseBody == null) {
InputStream instream = getResponseBodyAsStream();
[...]
构建健壮的Java基准测试
Posted in java on 八月 15th, 2010 by kafka0102
本周遇到几篇和基准测试相关的不错的文章，如果不是因为上周末鼓弄了一下各种锁的性能测试，我或许就会错过它们。两篇文章来自dw，分别是 Robust Java benchmarking, Part 1: Issues 和 Robust Java benchmarking, Part 2: Statistics and solutions，作者还有个专页 Java benchmarking article 提供一个Java基准测试的框架，感兴趣的可参考之。本文算是对Robust Java benchmarking, Part 1: Issues的一个简单的总结。在阅读Robust Java benchmarking两篇文章的过程中，我也看了些其中的参考文章，也有一些不错的可以拜读之。
Java中各种锁类型的基准性能评测
Posted in java on 八月 10th, 2010 by kafka0102
周末对Java中各种类型的锁做了基准评测。测试的条件有两个：1）是10、50、100个不同的并发线程，2）是读写比例近似1:1,10:1,100:1,1000:1。测试方法是，对各种加锁的Map方法做性能评测，它们都是实现了MapWrapper接口的封装，测试的就是Map的get和put方法。测试的锁类型有：1）hashtable：直接测试Hashtable，2）synclock：对HashMap的方法直接加synchronized（理论上性能应和Hashtable相当），3）mutexlock：对HashMap的方法显示加Lock锁，4）rwlock：对HashMap加读写锁，5）concrrent：直接使用ConcurrentHashMap的方法，6）对HashMap读操作不加锁，写操作加Lock。
[Solr源码分析]LRUCache和FastLRUCache实现分析
Posted in cache, solr on 八月 9th, 2010 by kafka0102
在 [Solr 实践]Solr Cache使用介绍及分析 一文我有对Solr的LRUCache和FastLRUCache做了一些介绍，本文在此基础对其实现做些补充。
1、LRUCache的实现分析
在分析LRUCache前先对LinkedHashMap做些介绍。LinkedHashMap继承于HashMap，它使用了一个双向链表来存储Map中的Entry顺序关系，这种顺序有两种，一种是LRU顺序，一种是插入顺序，这可以由其构造函数public LinkedHashMap(int initialCapacity,float loadFactor, boolean accessOrder)指定。所以，对于get、put、remove等操作，LinkedHashMap除了要做HashMap做的事情，还做些调整Entry顺序链表的工作。
以get操作为例，如果是LRU顺序（accessOrder为true），Entry的recordAccess方法就调整get到的Entry到链表的头部去：
public V get(Object key) {
Entry<K,V> e = (Entry<K,V>)getEntry(key);
if (e [...]
分析多线程并发写HashMap线程被hang住的原因
Posted in java on 八月 7th, 2010 by kafka0102
在blogjava上看到一文 谁能帮忙解释一下为什么这个程序会死锁？，激发了我那能害死猫的好奇，所以很费劲的琢磨了这个问题。由于涉及的内容较多，就单独发文阐述一下。
文中提到的问题程序如下：
public class TestLock {
private final HashMap map = new HashMap();
public TestLock() {
final Thread t1 = new Thread() {
@Override
public void run() {
for(int i=0; i<500000; i++) {
[...]
PHP中的“syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM”错误
Posted in php on 八月 7th, 2010 by kafka0102
因为需要，今天晚些在本机使用PHP做些测试，PHP脚本依赖了一堆我也不清楚做什么用的库。结果一跑起来，就报出类似下面的错误：“Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/kafka/test/test.php on line 8”。查找代码，发现报错的代码类似：“$class_name::func1();”，也就是使用一个表示类名的字符串变量来调用它的静态方法，并且是解析时的语法错误（我第一眼看到::时，脑子里浮现的是C++里的作用域符号，好长时间后才想起PHP里有::也有这种东西，我也是用过 self::doSomething()的）。
[Solr实践]Solr Cache使用介绍及分析
Posted in solr on 八月 1st, 2010 by kafka0102
本文将介绍Solr查询中涉及到的Cache使用及相关的实现。Solr查询的核心类就是SolrIndexSearcher，每个core通常在同一时刻只由当前的SolrIndexSearcher供上层的handler使用（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache生，SolrIndexSearcher亡则Cache被清空close掉。Solr中的应用Cache有filterCache、queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，并且是SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。
使用JRebel提供对Java web开发的热部署
Posted in java on 七月 29th, 2010 by kafka0102
这几天在写Java Web页面，开发环境是linux+eclipse+maven+jetty。开发java web最烦的就是改个文件需要重启web server，尽管现在的web server（比如小野猫）支持了热部署，不过其实现相当于重启了web server，如果文件多些初始化复杂些，重启的时间也够受的。对于开发的IDE来说，myeclipse是个不错的选择，它能对修改的文件自动部署到web server（eclipse wtp就没做这个支持，但我们也可以投机的对部署目录和开发目录做个软链），不多我试用了其最新的8.5版本，在本本上响应速度有些迟缓，影响编码情绪。而且，因为环境需要，最后开发环境定位eclipse+maven+jetty（maven提供了jetty的plugin用于开发测试），并且找到了JRebel这个强悍的能提供对Web server的热部署到工具，它不像web server那样需要重启服务，而是动态的加载修改的文件，所以反应速度上要好很多，它除了可以热加载class、jsp文件，也可以是spring、hibernate等配置文件。
