Entries tagged with “Flickr” from DBA notes

继续我的学习笔记之旅。Flickr 的 DBA 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--

TechCrunch 前两天报道说 Flickr 针对 Pro 用户新增了一项统计功能。今天有看到 Flickr 的 DBA Dathan Pattishall 描述了一下这个统计功能的实现。

Flickr 统计功能的基本技术信息：

• 所有的信息统计是实时的
• 同时用到 MYISAM 与 INNODB 两种引擎
• 数据因为存储需求跨在 6 个 Cluster 上(12 台服务器，6 台提供服务，6 台做失败接管)
• 没有用 Memcache

Dathan 提到这是他最耗时的一个项目(似乎有点怨言呀)。因为是实时统计，并且还要不影响整体页面响应速度，所以整个项目非常复杂。一旦 DB 设计搞定后，大部分时间都花在如何创建分布锁上了。

其实就我个人而言，真的不觉得这个功能有什么必要(尤其还是实时统计)。这或许是过度设计的一个例子。Flickr 在被 Yahoo！收购之后，这段时间倒是有点颓势。

说起 Dathan 这老兄，在 MySQL 技术圈子算是大名鼎鼎了。曾先后在 Friendfinder、Friendster 做 DBA，并获得国 05、06 两年的 "MySQL Application of the Year Award“。(看他 Blog 的活跃劲儿，估计今年也差不多。)

这老兄加盟了 Flickr 后，一个礼拜解决了 40％ 左右的性能问题。从他的简历来看，Flickr 目前每日 DB 的事务超过 10亿，MySQL 运行在 16G 内存、AMD CPU 服务器上，存储采用本地硬盘而没有用 SAN。数据库采用联邦架构，能做到线性扩展，为公司节省成本达 40 万美元(占40%，从而估计 DB 相关硬件成本为 60万美元).

推荐国内每个 Web 2.0 公司的 DBA 持续关注 Dathan 的 Blog，当然，可能大家都已经一直在看了。

--EOF--

《程序员》杂志在做关于 Web 可扩展性的专题，编辑朱海燕联系上了 Flickr 的 Cal Henderson, Web 2.0 应用最出色的架构师之一, 准备对他进行 e-mail 采访，如果大家有什么关于 Web 扩展性的相关问题，可以在后面留言或者发邮件给 dbanotes@gmail.com , 我代为转交。

五月份阿里巴巴举办的侠客行网络大会 Cal Henderson 因为时间的关系而没能成行，希望这次的采访能弥补一下不少人的遗憾。

--EOF--

深受网民喜爱的 Flickr 这两天被封掉了，不少网友愤怒之余，不知道是否有人产生这样的疑问:雅虎中国会不会把 Flickr 移植到国内来? Flickr 是个好产品，但想到 del.icio.us 的在国内的正宗克隆版: Yahoo! 收藏+ 的发展状况，几乎可以断言，Flickr 进入国内怕也不能有多大作为。

抛开其他的原因不谈，个人觉得雅虎中国(中国雅虎)现在的产品状况有些陷入"焦油坑"，尤其是在技术上，很难真正的施展拳脚。所作的一些产品还是依赖于美国的技术架构，尤其是底层的基础架构，举例来说，对于很多 Web 页面，用户发起的 URL 请求都必须要和美国的服务器发生 IO 交互。有这样的问题存在，无论 UE 工程师怎么在本地改进，都是无济于事的。近日有传言谷歌打算把服务器放到国内一部分，而雅虎中国可是早在 2005 年就把 2000余台服务器搬到了国内。这么久还藕断丝连，只能说已经太过于纠缠，没办法大刀阔斧的调整了。

在另一方面，域名的混乱程度我认为也导致了很多问题。域名是：yahoo.com.cn (跳转到 cn.yahoo.com , 服务大多是三级域名,相册是: gallery.i.cn.yahoo.com, 这么复杂的域名 100个人有 99 不能正确输入，四级域名的服务也有，'博客', blog.i.cn.yahoo.com...), 搜索 yahoo.cn ...... 我一直很好奇 Alexa 怎么正确统计雅虎中国的访问量 :)

雅虎最近的动作不可谓不多，比如新推出的 Omni-Search ，的确让人眼前一亮，可是看业界的反应，总有些怪怪的，对，就是不够轰动，没有神秘感。试想，如果是 Google 发布这样的产品，业界的反响会是怎样的?

对于一些除搜索外的其他老牌产品，比如电子邮件，现在越来越不够重视。我觉得电子邮件是一个很好的突破口，如果可以做到市场第一，为什么偏偏要跑到第二去呢? 电子邮件本身或许不赚钱，但是带来的相关收益可绝对不容忽视。远的不说，腾讯不也是 QQ 一个产品带活了一大片麽 ? 而现在，埋头做社区、SNS 那一套玩意儿，胜算不知几何。

BTW: Blog 首页最下方有文责声明.

--EOF--

好久没怎么正式更新 Blog 了，快荒芜了，长满了 Spam 的荒草。

最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：

Squid Cache 中共有 3500 万张图片；
在 Squid RAM 中有 200 万张图片；
4.7亿的图片，每张图片有4到5种尺寸；
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)

三个主要步骤：

计划

基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。

部署

Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。

度量(图形化展现)

Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。

Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。

--EOF--

Yahoo! 中国这几天接连发布产品。昨天看到 雅虎空间测试版上线。不少试用者的评价都是负面的，影响最大的应该是 Keso 的寥寥几语。其他人的评价也基本上是基于没有 Flickr 集成、没有 RSS 导入这些。我觉得这多少有点不公平的。Flickr 这个产品考虑到被 Yahoo! 收购的时间，应该不在雅虎中国可引入的范围内，自然不能汉化到中国来，而且雅虎空间是集成雅虎相册的，对国内很多普通用户来说，雅虎相册更为熟悉。至于 RSS 功能，现在没有不排除以后的版本中加进来，现在还是 Beta 版嘛。我这么说当然不是说雅虎中国没有缺点，我在使用的过程中第一个感觉是不够简洁，这个"简洁"不是指功能简单，而是说要让用户对一些功能一目了然，对一些提示不产生歧义，能够无障碍上手开玩。

今天雅虎中国正式发布了 雅虎通网页版。其实我在中午的时候已经看到 CWR 在报道 Yahoo China Launches Ajax Web Messenger。 这篇文章中提到了我的 Blog 名字，通过 egosurf 的机制几乎是第一时间看到的。这个产品因为时间问题，我还没有进行试用。

正如有人说的我们对Google 太不厚道了，对于雅虎中国在新产品上的努力，我倒是我觉得我们也有些太苛刻了。雅虎中国一直在进步，或许我们应该给雅虎中国、也给谷歌一些鼓励，给一些掌声!

BTW：个人观点，个人观点。

--EOF--

另外一个消息，微软准备支持 OpenID 了。

在 Firefox 1.5x 中我用 Bookmarklet 来实现一键点击网页中的图片即可上传图片到Flickr这样的功能，基本上可以满足需求了，Firefox 升级到 2.0 RC1 后发现过去的那段代码失效。

Firefox 的插件虽然众多，但是能够实现我需要的功能的插件一直没找到。查找 Firefox 2.0 的插件， 在网络上也问了几个朋友，都说没有这样的插件。

无奈之下，只得使用 Send To Flickr Bookmarklet Javascript Code 这个页面里的代码新建立了一个书签。这个代码是好用的。

Hung 告诉我 Yupoo 的插件是支持这样的功能的。不过很不巧，这个插件目前还不支持 Firefox 2.0. 我只得把插件下载，解压缩，修改 install.rdf 的版本限制，然后重新把这个文件扔到 yupoobookmarklet.xpi 文件中。

一键上传或一键发送这样的功能好比 Web 2.0 应用程序的"最后的一公里"。Yupoo 相比 Flickr ，是一个进步。虽然直接上传网页上的图片似乎容易带来版权问题，但我想有这样需求的用户应该不在少数--我用来做知识积累或图表分析。

del.icio.us 针对 Firefox 的插件完全解决了这样的问题。 或许 Flickr 更为关心那些直接上传数码作品的用户，不过 Flickr 也应该推出功能更多一点的客户端工具，来更好的实现与用户交互的最后一公里。

--EOF--

Cal Henderson　是大名鼎鼎的 Flickr 网站的开发者之一．在一篇名为 Serving JavaScript Fast 的文章中，他介绍了用于 Flickr 站点应用优化的技巧，读罢感觉获益良多．"嚼一下别人的馍"，概括一下该文的主要内容．

Flickr 是 Web 2.0 的代表站点。面对的网络问题除了一般 Web 站点都会有的内容优化之外, 还有必须要灵活处理 JavaScript 与 CSS 的频繁变化后部署分发带来的复杂性。

设定文件大小的策略 首先面临的一个问题是把所有的 JavaScript 与 CSS 放到一个文件中好呢，还是分割成多个文件 ? 从减少网络请求的角度上考虑, 前者更好，后者差。但是从并行的角度考虑, IE 与 Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良的使用体验--必须所有的文件都下载完毕才可以看到像样的页面. Flickr 采用了折衷的办法--在保持文件数量尽可能少的情况下，把 JavaScript 与 CSS 分成多个子文件. 这在开发上带来了复杂性，但是对性能的收益是巨大的。

压缩的优化问题 毫无疑问，对站点内容进行压缩是一个比较常用的 Web 优化手段．但是并不一定都能达到理想的效果．原因在于 mod-gzip 模块不但消耗服务器端 CPU 资源，也消耗客户端 CPU 资源. 而且, mod_gzip 压缩文件后创建的临时文件是放到磁盘上的，这也会给磁盘 IO 带来严重的问题. Flickr 采用的是 Httpd 2.x 以后支持的　mod_deflate 模块．压缩操作都在内存中进行．mod_deflate 在 Httpd 1.x 是不可用的, 不过可以通过创建 RAM 盘的方式来间接提高性能．

当然, mod_gzip 到也不是一无是处, 对于预压缩的文件, 还是有好处的. 而且, 采用压缩的时候,也要注意策略. 图片文件压缩就没什么必要了(Flickr 上图像多, 而且压缩得不到什么好处). Flickr 只对 JavaScript 和 CSS 进行压缩. mod_gzip 新一点的版本能够自动通过配置 mod_gzip_update_static 选项自动处理 预压缩的文件. Cal 也指出这个特性在一些旧版本的浏览器上会出问题.

压缩的另一个主要手段是内容的压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑的语法等小技巧(Google 的所有脚本都非常难读，而且非常紧凑，思想类似).当然，经过这样处理的 JavaScript 可能带了很多括号不容易解析，Flickr 使用了 Dojo Compressor 来构建解析树。Dojo Compressor 开销很低，而且对于最终用户是透明的. JavaScript 的处理方法介绍过，CSS 处理则相对简单.通过简单的正则表达式替换(比如把多个空格替换为一个空格符), 最高可以获得 50% 的压缩比。

Caching 的优化 Flickr 的开发者充分利用了 Http 1.1 规范定义的 Etag 与 Last-Modified 机制 来提高 Caching 的效率. 值得注意的是，Cal 介绍了一个在负载均衡条件下的 e-Tag 小技巧. 即可以设定 Apache 通过文件调整时间与文件大小获得 E-Tag ,而默认情况下, Apache 是通过文件节点获取 e-Tag 的。当然，这也不是很完美，因为会影响 if-modified-since 。

灵活运用 mod_rewrite 据说 Flickr 网站应用是进行每日构建的(Daily Build)。 如果没有一个灵活的机制恐怕这是不可想象的。而且，在 Flickr 这样的站点, 内容的修改同步的处理都是很让人头疼的难题. 他们的利器是 mod_rewrite 的灵活运用。通过配置 URL 重写规则，很容易切换到不同的环境下。听起来很简单, 但是没有一定的 Web 技术功力谈何容易做到 ?!

通过这几个主要方法的运用，我们看到了如梦幻一般高性能的 Flickr .

BTW: 因为在 Flickr 在国内没有服务器, 大陆用户访问的速度就别提了 :(

--End.