Flickr Stats 功能的设计经验

继续我的学习笔记之旅。FlickrDBA Dathan Pattishall 在前几天的 MySQL 大会上分享了 Scaling Heavy Concurrent Writes In Real Time (Record every Referral for Flickr Realtime) ,其中介绍了 Flickr Stats 的设计经验。国内好多 Web 站点其实也在设计类似的功能,只是不知道细节罢了。

数据结构原型

字段               数据类型         
Path_query Varchar(255) PK
Domain Varchar(50)
Owner Bigint
When Date
Object-ID Bigint
Object-Type Tinyint
Counts and stuff Various ints May be some keys

主键是字符串,开销太大。其他的索引如果做主键,也比较大。当表大小超过内存的时候,插入速度很慢,I/O 能力也上不来。

优化数据结构

数据预处理,通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type,这个统计信息很容易抽象到一个数据对象,这个索引的设计也在于此。

另外补充一点,利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理,耗费的存储空间只为原来地 25%,这是个很有趣的技巧。

数据 Sharding

对于海量的数据,以一个礼拜为间隔,水平分割。按照不同的数据力度每周一个表,每年一个全局表,再加上一个汇总表。数据量越大,InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。

所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列,每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。

总体的服务器规模过去 介绍过,对专业版用户的数据是永久保留的,而普通用户则只保留几周,为节省空间,采用 MyISAM 引擎,当用户转为专业版时,迁移数据。

补充一下,抓取 URL 是用的 curl 。最后,这篇 PPT 在线观看

EOF

补充一张图:

Flickr Stats.png

这是该功能的 UI 设计。

  • 1) 请求触发统计。默认不激活统计。从而节省大量不必要的开销;
  • 2) 统计,没必要过度设计;
  • 3) 元素可点击
  • 4) 设计洁癖
此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

  • http://www.36sign.com Confach

    上面的”介绍过”的超级连接有问题吧

  • ccpp0

    力求严谨
    CONV(SUBSTR(MD5(Url),0,16),16,10)
    应该是
    CONV(SUBSTR(MD5(Url),1,16),16,10)