最近 Twitter 和 Digg 的技术团队都放出话来说要从 Mysql + Memcached 的组合迁移到 Cassandra 环境（Refer 1、2)，这些消息又会让不少人跃跃欲试，恨不得也把自家网站迁移到 Cassandra 下面过把瘾，我相信有些公司的团队又要言必称 Cassandra 了。

Twitter 和 Digg 对数据存储引擎的需求相当独特：写操作密集，基本无修改需求，读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说，Sharding 后几乎是被当作简单的存储引擎来用的，即使是加上 Memcached ，对数据读取开销相当大(Refer)，因为这时候即使是最合理用索引，I/O开销也不是最优的--走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果，这要得益于其 Flexible schema 特性，按照既定规则写入，读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用，而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂，尤其是 Twitter ，相当的简约（当然并不简单）。或许有人说，把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么？没错，Facebook 数据结构很复杂，不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的---只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ，如果应用场景不合适，那么对你来说永远都只是个传说。。

--EOF--

日前参加了一场淘宝网架构师黄裳带来的技术分享，在最后他总计了淘宝这几年来的架构经验，这里和大家分享一下：

• 1、适当放弃一致性
• 2、备份和隔离解决稳定性问题
• 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
• 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
• 5、产品化管理

在这里不妨对比一下 eBay 的架构经验：

• 1、 Partition Everything
• 2、 Asynchrony Everywhere
• 3、 Automate Everything
• 4、 Remember Everything Fails
• 5、 Embrace Inconsistency
• 6、 Expect (R)evolution
• 7、 Dependencies Matter
• 8、 Be Authoritative
• 9、 Never Enough Data
• 10、Custom Infrastructure

关于一致性，可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外，强调了"放弃集中的紧耦合处理"的原则。"备份"这里可以理解为"提供可用的副本"。"分割"是说水平拆分。

架构这东西说起来大致原则，其实都是类似的，但是具体如何在一些通用原则上做到运用自如，是很难的事情。前几天我还感慨，很多架构师对与"异步"与"批量处理"所能带来的益处的理解仍然相去甚远。

--EOF--

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点，在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建，最初提供面向游戏的视频服务，随后转型为现在的模式。网站流量现在是全球 1800 多，盈利能力自称良好。

在 MySQL Conf 2009 上，SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris)，300 多台 4 核（或更多）的服务器（大多是 AMD 的 CPU） ，分散在四个机房，两个运营的人员。SmugMug 充分运用了云计算服务，是 Amazon 的一个大客户，图片和视频总计达到了 PB 级，托管在 Amazon S3 上，图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速，主要是 JavaScript/CSS 等文件的加速，此外，DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中，存储引擎多数用的 InnoDB，数据超过 2TB 的空间，数据库服务器为 4 核或更高配置，内存多达 64GB。缓存方面，用了 Memcached 做加速，有 1TB 的数据在这里面，平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据，减小对 DB 的冲击。数据库设计思路是尽量做垂直分区，没有 Sharding。不过在反范式(denormalized)方面做得比较彻底，不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键，更新或者删除数据也是单行，依赖主键。InnoDB 引擎打了 Percona 的 Patch，并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高，而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方，备份也成问题。ZFS 倒是能满足相关的需求，可惜不支持 Linux(妈的，早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外，对于复制中可能出现的风险，尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后，MySQL 放在 Sun Sushi Toro(Storage 7410，这个东西也支持 SSD ) 上，走 NFSv3 协议。写到这里，发现 SmugMug 的解决方案非常不具有通用行，看起来 Sun 是给了他们不小的硬件优惠，否则一般情况下不会有人这么搞的，用 NFS 协议走数据库，除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走)，产品上真的有人跑么?

网站架构的进化，其实也是选定一个方向(比如用开源工具解决)，然后一直试错的过程。

--EOF--

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长：

• 24 TB 的 MySQL 数据
• 每秒钟 MySQL 有 3.2 万次写操作
• 每秒钟 MySQL 有 12万次读操作
• 图片容量 6 PB
• 每天要用掉 10TB 存储
• 超过 15000 个服务监控点

在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手"裁"掉机器，也会省钱嘛...

Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：

• 使得机器自动构建 (Teach machines to build themselves)
• 使得机器自监控(Teach machines to watch themselves)
• 使得机器自修复(Teach machines to fix themselves)
• 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 ... "信息查找"，是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。

--EOF--