一直比较好奇 FriendFeed 网站背后的技术信息。Bret Taylor 的一篇 How FriendFeed uses MySQL to store schema-less data 给出了不少有价值的经验。
概览
FriendFeed 用 MySQL 存储绝大部分数据，超过 2.5 亿条记录。对待网站功能的态度: 让既有功能满足更多用户而不是添加更多的功能。
少添加新功能的好处是数据库 Schema 变化更小。在数据库Sharding 的情况下，如果修改 Schema 结构，必然会影响可用性。此外，几乎不进行复杂一点的关系型查询(比如 不做 JOIN 操作 — 这要用到传统意义上的索引机制 )。FriendFeed 也没有采用什么更新的数据库解决方案(比如 CouchDB )，原因无他，对 MySQL 更谙熟，知道其短长，扬长避短同样能发挥更大的作用。
Schema-Less
这是 FriendFeed 对付数据库的基本策略。只存储基本的对象属性，如果需要修改 Schema 层面的东西，只需要存储新的属性即可。其实就是更加”面向对象”，由基本的「元数据」一步一步衍生到所有的数据对象。
坚持「去索引化」，因为维护索引带来了复杂度，将索引数据存储到到表上。我认为这也是反范式的一个新的思路。在 Bret Taylor 文章的 「Details」 一节中给出了具体的例子。比如要在 user_id 上进行索引，那么创建 index_user_id 表(存储来自所有 Shard 的数据)，以 user_id 和 entity_id 为主键即可。这样在修改基表的时候，不需要对其他「索引」表做变动。而删除「索引」也极为方便–删除创建的「索引表」即可。
一致性与原子性
关于一致性可能会有问题，但是可以确定基本原则：
- 主条目表中存储的属性数据是规范的
- 索引可能不对应实际的值(这和关系数据库本身的索引有些不同之处)
写入数据的时候按照如下顺序：
- 写入条目表用 InnoDB 的 ACID 属性来保证
- 把数据写入到其他 Shard 上的索引表中(猜测可能还是要延迟写)
在读取的时候可能会有短暂的数据不一致性的现象，但很快就能校正。考虑到 FriendFeed 业务的容忍性，这个问题并不严重。
笔记总结
总体感觉，FriendFeed 用了一种非常巧妙的方式进行数据库扩展（多耗费了一点存储空间)。不过这个方式总体上看来，极大减少了手工维护成本。相信 FriendFeed 分享的这个经验能给国内一些需要处理即时信息的站点一些启发。以上只是我的个人理解，如果去看一下 Bret 文章后面的留言，你肯定能得到更多信息（比如为何使用 UUID )。
最后提一下，FriendFeed 用 pickle 做 Python 的对象序列化。当然 Memcached 也是居家旅行必备佳品。
–EOF–
