近期highscalability上有一篇文章，介绍了由flickr的数据库高人撰写的flicker的数据库设计，作者说，如果你想知道自己的sharding是否做对，一定要拜读该文。（ppt的title中赫然见到”Federation”一词，难道又会创造一个Federation热吗？） （另，这个ppt里其实没有很多有用的内容，可能更多是通过口头表达的）
flickr架构就不多说了，可以参见highscalability.com的文章 或 dbanotes上的介绍
ppt主要介绍flickr 遇到的几个问题，以及是如何解决的：
1. mysql master-slave 拓扑问题
将数据sharding分布
建立master-master ring来解决写入的问题
— 据作者说是为了解决写入点的问题，但是master-master ring可能会使得数据库的写请求量过大，影响读请求的服务
在应用层实现”分布式事务 ”
— web 2.0的shard架构决定了分布式事务比较难做
2. slave lag问题
slide标题是”Getting Rid of Replication Lag” ，但是感觉是一个数据定位以及容错的方法：
$id = intval(substr($user_id, -10));
$id % $count_of_hosts_in_shard
— If host is down, go to the next host in the list
— If all hosts are down, display error page
3. 系统中的单故障点
通过master-master ring，并且每个server(shard)只提供 50%的服务能力，保证随时可以停止其中一半的服务器进行维护，提升维护能力。
4. 系统无法满足用户需求
5. 无法处理搜索请求
提供两种搜索服务，其一是”single tag search”，用shards来实现，其他的后台调用yahoo搜索服务
6. Multiple Second page load times
其他的一些小tips:
1. 把交换区设置为0 ??
2. 将2.6 kernel 的调度器算法调整为”DEADLINE”?
3. 使用 RAID 10 (最近我们内部的测试似乎表明 10跟5之间的差距不大）
4. 使用 “Battery Back cache” — 啥东东？
5. 64bit system
6. 更多的内存，但是要留下足够给系统生成线程；
7. 优化query