Archive for April, 2009
Wednesday, April 29th, 2009
PERCONA PERFORMANCE CONFERENCE 2009上，来自雅虎的几位工程师带来了一篇"Efficient Pagination Using MySQL"的报告，有很多亮点，本文是在原文基础上的进一步延伸。
首先看一下分页的基本原理：
mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20\G
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)
limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。文中还提到limit n性能是没问题的，因为只扫描n行。
文中提到一种"clue"的做法，给翻页提供一些"线索"，比如还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，如果我们只提供"上一页"、"下一页"这样的跳转（不提供到第N页的跳转），那么在处理"上一页"的时候SQL语句可以是：
SELECT * FROM message WHERE ...
Posted in MySQL | 11 Comments »
Friday, April 24th, 2009
不知大家有没有发现，就算你选择了"记录登录状态"，下次访问kaixin001.com的时候还是官方静态首页，过一会才跳转到个人首页，这样的用户体验反正我是不太舒服，查看kaixin001首页源代码，发现个中蹊跷：
function _bodyonload()
{
....
var v_kx = getCookie('_kx');
if (v_kx.length)
{
....
v_timeid = setTimeout("gotohome()", 2000);
}
}
function gotohome()
{
if ...
Posted in Arch | 14 Comments »
Tuesday, April 14th, 2009
最近几天，被pidgin折腾疯了，一会上线，一会自动退出，一会假死，看到好友发过来消息，可阅读不了具体内容，折腾的身心疲惫，升级到最新版本也无济于事。
由于在pidgin上登录了msn和gtalk帐号，初步怀疑是MSN插件的问题，貌似MSN之前升级了版本。禁用MSN帐号后，pidgin恢复稳定。
郁闷的不行了，找到一个第三方的MSN插件：http://code.google.com/p/msn-pecan/
wget http://msn-pecan.googlecode.com/files/msn-pecan-0.0.18.tar.bz2
tar xjf msn-pecan-0.0.18.tar.bz2 -C /usr/local/src
cd /usr/local/src/msn-pecan-0.0.18/
make
make install
安装之前记得安装libpurple-devel
yum install libpurple-devel
安装好了之后，pidgin中会出现WLM协议，用这个做MSN登录，世界总算清静下来了。
我这边是CentOS 5.3，Pidgin 2.5.5-1.el5，其他版本安装说明，阅读http://code.google.com/p/msn-pecan/wiki/HowToInstall
Posted in 默认分类 | No Comments »
Friday, April 10th, 2009
Web2.0网站，数据内容以几何级数增长，尤其是那些小文件，几K～几百K不等，数量巨多，传统的文件系统处理起来很是吃力，很多网站在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。
YouTube也碰到这样的问题，每一个视频有4个缩微图，这样的话缩微图数量是视频数量的四倍，想象一下YouTube有多少视频，看一下他们遇到的问题：
大量的磁盘寻址，在操作系统层面出现inodes cache和page cache的问题
单个目录文件数限制，尤其是Ext3文件系统，采用目录分级的做法，最新的Linux Kernel 2.6优化了Ext3文件系统，单目录能存储的文件数提高了100倍，但是把所有的文件存一个目录不是一个好的方法
高RPS（requests per second每秒请求数），因为一个页面可能要显示60个缩微图
高负载下Apache性能差
Apache前面加一层Squid，能抗一会，但负载上来之后，性能下降厉害，由300RPS降到20RPS
尝试lighttpd，但是lighttpd是单线程，多线程的话也有问题，线程之间缓存不能共享
加一台服务器的话需要24小时，因为文件数太多了
存在“冷却”的问题，重启服务器后需要6～10个小时才能缓存好
YouTube的解决方案是Google的BigTable，一般人没戏。（原文参见：http://www.hfadeel.com/Blog/?p=127）
Facebook也遇到了同样的问题，他们的方案参见：http://www.dbanotes.net/arch/facebook_photos_arch.html，他们经历了三个阶段：
NFS共享，挂一个盘阵，APP服务器通过NFS读写
加一个中间层Cachr：eventHttp + memcached(lighttpd + mod_memcache实现同样的功能)，后端还是通过NFS连盘阵
Haystacks，详细的去读这里（E文）。
对于一般的网站来说，实用的方案有哪些呢？
一、NFS共享
是的，这个有很多问题，但实施成本低，很多公司都在用（我们也在用），在不是那么多文件，不是那么高并发的情况下还是很不错的，设置Hash目录，不要让一个目录下文件数过多，对于一般的网站来说足够用了。
备份确实是一个问题，如果不是海量的话，根据文件更新时间每天增量备份＋周期性的全量备份应该可以。
二、文件存数据库
真有人这么做，手机之家用MySQL建了256个表来存储超过1T的文件，前端加一个多级缓存（具体未知，也许就是memcached也许还是文件），数据库做数据备份用，他们用起来觉得还不错。
或者觉得MySQL太重，试试key->value的数据库，比如BDB，Tokyo Cabinet等。
三、分布式文件系统
开源的很多，好看簿用的是MogileFS，与memcached师出同门。傲游用MFS来存储用户的收藏夹文件，详细文章参见：分布式文件系统MFS(moosefs)实现存储共享(一) 、(二)，据说数百万轻松处理。
分布式文件系统好处是可以均衡读写压力，数据可靠性大大增加，某个数据节点挂了也没事。
还不行？自己DIY一个去吧，豆瓣就这么做的，TokyoCabinet做为底层存储，封装了一个memcached协议接口（与Tokyo Tyrant何异？），一致性哈希，应用程序根据哈希规则在node中读写数据:
DoubanFS结构图，版权由charlee所有
Posted in Arch | 7 Comments »