Archive for 十月, 2010
solr拾遗：CopyField
星期六, 十月 30th, 2010
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序列化工具性能对比
星期天, 十月 24th, 2010
看到一个很不错的工具http://github.com/eishay/jvm-serializers/，可以用它来评测各种流行的java序列化反序列化工具的性能，使用上也很简单。想试试该工具的，下载源码后参考起README操作即可。而我更关心的是，是各种工具的性能对比，以作选择的一个衡量标准，也就是http://github.com/eishay/jvm-serializers/wiki的图示和数据。本文也就简单转摘其图示，图示中的java-manual指的是根据对象（数据）格式手工操作（当然是最快的，但不具有通用性），java- buildin-in就是内置的序列化方式（ObjectOutputStream、ObjectInputStream），其他工具的使用版本可以查看其wiki。
mysql的多线程复制
星期天, 十月 24th, 2010
对于使用主从复制的mysql用户来说，经常会遇到的问题是，当主库的写压力增大时，基于单线程复制的从库跟不上主库的写速度，造成应用从从库读到脏数据。如果在数据库前面使用了cache，那么这种脏数据的影响就更恶劣。更糟糕的是，如果在主库上执行了耗时很长的sql，那么从库就会被完全阻塞，这也限制了程序员们不要在主库执行耗时长的语句，更不要提那些alter schema的语句。对于mysql主从的这个缺陷，可以使用一些其他方式规避它，比如做sharding处理，控制每个master的写压力在合适的范围内，也可以去主从，通过应用来分发请求到各个db（应用相当于主库），但这些做法相比复制无疑会复杂的多。
solr filter query的误用
星期五, 十月 22nd, 2010
在我整理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性能问题分析
星期四, 十月 21st, 2010
基于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
星期天, 十月 17th, 2010
Scalable System Design Patterns 一文概括了几种常见的系统设计模式。配图很漂亮，我就索性摘过来，推荐感兴趣的继续围观其博客。
twitter的新搜索架构
星期天, 十月 10th, 2010
当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇 Twitter’s New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如 新 Twitter，新搜索，我在这也就算是炒冷饭了。
