Archive for January, 2009
Wednesday, January 28th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/bdb-cache/
做网站，好像大家都比较喜欢文件缓存，把那些读操作多写操作少的内容缓存成一个文件放服务器硬盘上，下次直接读取或者更新。针对每一个key缓存成一个文件，当需要缓存的内容多的时候，文件数也就相应的多，这么多文件的同步和备份都是大问题，数据的可靠性也无从保证。
可是为了"效率"，我们也忍了，但文件缓存的效率真的好吗？有没有更好的方案？当然，memcached是很好的解决方案，今天这里测试另外一种方案：使用Berkeley DB作为网站数据缓存方案。
测试环境：CentOS 5.2，Core2 T5500@ 1.66GHz，1.5G内存，Ext3文件系统，apache 2.2.3，php 5.2.8 with php_dba
数据初始化：为了不至于在一个目录下文件数目过多，文件缓存分了两级hash目录，初始化数据数10万条。
/**
* 初始化缓存
*
* @param int $limit
*/
function init_cache($limit = 100000)
{
$str = 'good good study,and day day up.';
$bdb = dba_open('./bdb.db', 'c', 'db4');
for ($i = 0; $i < $limit; $i++)
...
Posted in PHP | 2 Comments »
Tuesday, January 20th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/key-value-stores/
早上看到博客Anti-RDBMS: A list of distributed key-value stores（抵制关系型数据库：分布式key-value存储列表），最近的项目中也有用到类似Key-Value的存储。
memcached是最典型的key-value型存储，估计也是使用最广泛，但是由于memcached数据存放在内存中，服务重启或者系统down机之后就会丢失，只能用来缓存非关键数据（丟了没关系，重建就可以），或者考虑memcached的持久化方案：memcachedb，不过还是建议缓存次关键数据，比如文章点击数，写入失败或者丢了数据也不是太要命。
有时候我们的数据本身就是key-value型的，比如字典数据，就两列：单词->释义，这样的数据存mysql之类的关系型数据库就有点太"重"了，大可采用key-value型的存储方案，Berkeley DB就足够用了。
一直在关注CouchDB，已经是Apache的顶极项目了，系统稳定和版本更新自然有保障一些，居于Erlang语言开发，高并发也不是问题，relication也集成在里面，分布式也很容易做到，提供HTTP Restful接口，方便调用。个人觉得最适合股票类的网站，需要实时更新股票价格，用这个简直就是就像是定制的，不知道新浪财经的同事有没有关注。
Anti-RDBMS: A list of distributed key-value stores还提到HyperTable，百度居然赞助了这个项目，实在难得，说明项目确实不错，希望百度也分配一些工程师进去，完善开发HyperTable，到那个时候平民百姓也能用到BigTable了。
今年的也准备写个key-value的项目，计划中，关键字：Python,stackless,UDP,BDB ,memcached protocol,Low mem use.
Posted in 默认分类 | No Comments »
Saturday, January 10th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/cu-net-opt-salon/
特意把调休放在1.9，主要是想去听听CU组织的网络优化论坛，报名的时候有点意外，貌似丢失了报名信息，和组织者沟通了一下，感谢周平同学的热心帮助，说到的时候找他就可以，去的时候其实也没有查邀请函什么的，还给了件CU的T-Shirt，甚是感谢，一般这种开源技术研讨会都是很开放的。
首先是TOM网的曹刚带来的“浅析系统架构”，主要讲的是Myspace和SOHU社区架构的演变过程，基本的内容可以参考构建可扩展网络应用的七个步骤，一般他们的历程都是从第一步到第四步，大体上差不多，我这里列举这个关键词：
64位：Myspace为了让服务器管理更多的内容，操作系统由32位升级到64位，我们都知道32位的操作系统最多支持4G内存（当然有方法可以实现超过4G，不推荐。），64位操作系统理论上支持4G个G，估计我是看不到用完的那天，这里要注意的是32位操作系统下，一个处理器最多处理2G内存，所以如果是Memcached服务器，不要一个进程给超过2G内存，浪费。好的做法是多开几个服务，或者直接把Memcached服务器和APP服务器合二为一，很多公司都这样。
分表：论坛的特点是数据一般是按照板块分组，所以对于论坛这样的应用来说，最好是按照板块ID分表甚至分库分机器。
板块帖子列表页：论坛的特性是新帖子、新更新的帖子排在最前面，所以可能的情况是每次刷新的时候页面都在变，SOHU社区的做法是把板块新帖子保持在一个链表里面，链表的特点是插入和删除都很快，问题是查询的时候只能遍历。
其实对于一个论坛板块来说，热门的帖子不会太多，估计大家也就翻前几页，大可以把这个数据放进缓存中，比如维护一个队列，最新的500个帖子ID，帖子Title，新帖子放在最前面，自动顶掉最后一个，大可以用数组而不用链表，虽然插入的时候慢点，读取的时候却不用遍历链表。
对于跟帖数据，一般都是按照时间顺序排列，新增加的帖子自动在最后，压力不会很大。
google去搜一下Carp算法，一致性哈希算法consistent hashing（可以参考http://tech.idv2.com/2008/08/17/memcached-pdf/），Amazon S3 环形算法（是不是就是consistent hashing?不知）。
曹刚最后做了个总结，个人觉得：熟悉业务需求应该是核心。
第二位演讲者是来自占座网的吴炳锡，讲的是LVS和Nginx的负载均衡，这块以前只是从资料上看过，接触比较少，不过炳锡的介绍深入浅出，以前觉得LVS晦涩难懂，不敢动手，听完之后无知者无畏了，有机会试试看去。其实很多事情都这样，看上去挺难，做起来就容易了，下面是几个关键字：
DR模式：LVS有NAT、TUN、DR模式，推荐使用DR模式，更多的信息去google吧。
LVS->Nginx->Squid：组合的模式，LVS是四层的转发，Nginx是七层的转发，可以支持URL规则的转发，组合起来用就可以随心所欲了。
性能：Nginx的性能和LVS NAT模式相当，都是很好的解决方案，熟悉哪个就用哪个吧，性能都不是问题。
keepalived：LVS居家旅行、杀人灭口必配武器。
搜房网：搜房网前端采用LVS做负载均衡，中间用Nginx做URL负载均衡，动态的URL跳到App服务器，静态的URL跳转到Squid服务器。
第三位演讲者来自某个赞助商，感谢他们对活动的赞助，就不做广告了，一句话概括：适合钱多人傻。
第四位演讲者来自SOHU的MySQL DBA叶金荣，报告的内容网上大多有，这里也列出一些关键字：
发现问题：系统响应慢、load avg >=5、IO wait >= 10、swap使用情况、mysql status、mysql report、mysql 5.1 profline
xfs：如果可能，mysql数据文件系统分区采用xfs，效果高30％～50％
innodb_buffer_pool_size：如果是专用的数据库服务器，设定为内存的80％吧
MyIsam适合低并发、低更新、高读取的需求，InnoDB适合高并发、高更新、高读取的需求，MyIsam读取的速度比InnoDB快许多。
Explain：查询检查、查询优化
联合索引：貌似MySQL一次查询只用到一个索引，联合索引要注意先后顺序的问题，“左派”比较吃香。
字段按需配置，能用TinyINT的不用INT，字段越短越好，具体差别可以参见：http://chaoqun.17348.com/2008/11/mysql-data-types-int/
把大表拆成小表，如果表字段里面有Text，尽量拆开吧。
缩短事务周期
字符型的字段，最好采用前缀索引。
复杂的查询拆成小的简单的查询，比如用循环查询替代。这点不敢苟同，还是按照自己的业务测试一下吧。一条sql语句总比N条要快吧，除非有问题。
left join：把条目数少的放左边，如果你了解left join的话，这个是肯定的。
实时备份：用slave做实时备份吧，一个slave就是一个备份。
第五个演讲最为精彩，走了的人实在可惜，掌声和笑声不断，田逸这个家伙说话太有意思的，有机会要认识一下。讲的是CDN方面的事情，关键字：策略，技术很重要，策略更重要。
昨天的网络优化论坛受益匪浅，演讲者都有丰富的经验，其实网站架构就那么点事情，多分享才能共同进步，不过从互动环节可以看出国内做技术的对这方面关注还是比较少，有些问题比较原始，多关注一些就不会那样了。
PS:报告盖茨：我上周四叛逃到Linux了。
Posted in Arch, Open Source | 3 Comments »
Tuesday, January 6th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/slope-one-on-netflix-prize/
前段时间做了个slope one算法在Netflix Pirze上的测试，关于slope one算法可以参考我之前写的文章:Slope one:简单高效的推荐算法，Netflix Prize是DVD在线租赁商Netflix于2006年10月2日发起一项竞赛：任何组织或个人只要能够提交比它现有电影推荐系统Cinematch效果好10%的新方法，就可以获得100万美元的奖金。竞赛最多持续到2011年10月2日。同时，NetflixPrize还提供每年5万美元的年度进步奖。为什么是五万美元的年度进步奖呢？因为100万美元大奖存银行，每年的利息是5万美元，看来老外是挺有意思的。
Netflix Pirze采用RMSE作为评测的标准，RMSE中文的意思是均方根误差，计算的公式：
其中Ot是原始数据，Ft是预测数据，n是样本数。
目前最好的成绩是有BellKor in BigChaos创造的0.8598（2009.01.05数据），比官方数据提高9.63％，这样可以推算出官方的数据应该是0.9492左右，BellKor in BigChaos也是2008年度进步奖的获得者，他们更新数据的频率很高，如不出意外，最后的大奖应该是他们的。
目前的方向大多是SVD奇异值分解，可以参见BellKor in BigChaos他们的文章http://www.netflixprize.com/community/viewtopic.php?id=1193，这里有一个开源的项目nprize，也是一个SVD处理Netflix Prize的模型，大部分代码是Python的（国外很多用Python做数据挖掘和自然语言处理的案例），成绩到了0.9046，折算比官方数据要高4.70％，如果你想拿SVD热热手，可以看看这个开源项目，过些日子我会写一些SVD应用在推荐系统方面的文章，着急的可以阅读吴军的文章数学之美 系列十八 － 矩阵运算和文本处理中的分类问题。
由于对slope one算法比较熟悉，决定看看slope one算法在netflix pirze上的表现如何，netflix prize训练数据太大，大概有1亿多条的打分记录，OpenSlopeOne在运行效率方面不是很好，OpenSlopeOne处理几百万上千万的打分数据还是非常不错的，更多的话需要更多的机器水平扩展，如果有好的Mysql DBA可以尝试优化一下mysql server的参数，估计效果会很好，当然也需要有好的机器配合，我这里是用Python写的一个程序，多进程＋多线程＋手工Map-Reduce，需要源代码的话可以找我拿。
跑出来的结果不是很好，我的得分是0.9829，比官方数据差0.0337，大概差3.55％，分析原因可能是用户打分的数据普遍偏高，人们大多给自己喜欢的电影打分，对于不喜欢的数据打分就少很多了，下面是打分数据的分布情况：
mysql> select rating,count(*) as times from nf_log group by rating;
+--------+----------+
| rating | times |
+--------+----------+
| 1 | 4617904 |
| 2 | 10131945 |
| 3 | 28810978 |
| 4 | ...
Posted in Data Mining | 4 Comments »