Tag Archives: FriendFeed

FriendFeed 使用 MySQL 的经验

一直比较好奇 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

FriendFeed 给了我们什么?

如果说 2007 年最佳小型 Web 2.0 应用是 Twitter,那么 2008 年最耀眼的 Web 2.0 应用很有可能就是 FriendFeed,虽然现在下断言还早,但是看看FriendFeed 团队的背景,清一色的 Google 帮……

个人觉得这个应用的”卡位”很好,试图在各个 Web 2.0 应用(尤其是 SNS 站点) 之上形成一个信息出口。让我想起了 Yahoo!Pipes

我从 FriendFeed 的测试阶段就开始使用,我的 FriendFeed 原来大约有几十个订阅者,不过在 正式发布后的这几天,我每天都要收到大量的订阅通知,很多朋友也都惊呼 FriendFeed “爆发“。

FriendFeed 给我带来了什么? 用了这个服务这么久,我在 FriendFeed 站点上停留的时间可以说是非常之短。每天会检查一下每日发到我邮件里的 “FriendFeed Activity”,说句实话,到现在我才发现,几乎没有从这些 “activity” 里面发现任何”新”的信息! 很奇怪吧? 虽然 FriendFeed 号称 “offers a unique way to discover and discuss information among friends”,方法是提供了,但是并不能让我有效的发现信息热点。面对每天大量来自朋友的更新信息,用户总不能每天 “披沙简金” 吧?

另外一个比较严重的问题是大量近似的冗余信息让人不厌其烦,缺乏必要的过滤方法也容易让人对 “discover“ 更有价值的信息失去兴趣。 (BTW,Google Reader 上这个问题也很严重) 。当然,朋友们最为关注的信息很可能也是我最感兴趣的信息, 但是希望能有一个好的形式为用户展现出来,这一点我倒是比较欣赏 Techmeme 的模式。

考虑到 FriendFeed 测试阶段的改进频率,相信会逐渐解决这些问题的,毕竟这是出身 Google 的金牌团队啊。

EOF

年度回顾:2007 年最常用的 Web 2.0 服务

2007 年就快过去了。这一年中, Web 2.0 应用对我的网络生活影响程度更大了一点。回顾一下,除了过去经常用的 del.icio.us、Flickr 等”老一辈“的 Web 2.0 服务外, 今年新熟悉了几个 Web 2.0 服务。

Twitter — Micro-blogging Service

截止到写这篇 Blog 为止,我在 Twitter 上有超过 1000 条更新,Followers 接近 250 个。算得上是个中度用户,中毒还不算深。

Twitter 刚上手不知道怎么玩,但是玩起来还有点容易上瘾。必须要承认 Twitter 是个时间杀手,我过去也担心这东西带来的信息过载,有的时候会有比较大的信息噪音,比如那些绑定了 Feed 到 Twitter 上的朋友,对于 Feed 通知更新太频繁的我都屏蔽掉了,现在尽管每天接收大量 Twitter 的 Updates ,但总体感觉信息还是比较有质量。

顺便说一下,我用 TwitterFox 这个 Firefox 插件。用 IM 收发更新容易受到被动干扰。有些担心有一天 Twitter 会被阻尼,但我不打算用国内的克隆版,使用这些 服务也是为了体验创新的产品设计。

LinkedIn — SNS Service , Business-oriented

在尝试 LinkedIn 之前,我是若邻 (Wealink.com) 的用户,但若邻的整体用户氛围现在非常让我比较反感,尤其是很多人打着”猎头”的头名来套瓷,还有社区内的很多人一天到晚的转发帖子,信息噪音太大了。LinkedIn 上的用户还是比较规矩的,没事也没人来干扰你。

LinkedIn 是《连线》杂志评选的 2008年十大最值得关注创业公司,符合我要用就用同类站点中最好的习惯,你总不想某天找不到自己辛苦积累的信息吧? 之所以起用 LinkedIn 这样的服务,还是觉得有必要积累一点个人资本,认识一些国内外业内的朋友,互相通通气。我在 LinkedIn 上的 Profile 连接超过了 75 个,估计还能逐渐增加一些,话说回来,LinkedIn 上 Google 的员工,平均每人也只有 47个联系人“。车东在上面有超过 500 个连接,可以作猎头了。

其实面临求职的朋友不妨在 LinkedIn 或者类似的服务上维护一份自己的简历,事半功倍。

其他的 SNS 服务,如 MySpace 或者是 Facebook ,我不打算用。没那个精神头了。

Google Reader — Information Gateway

自从 Feedburner 被阻尼了之后,不得不抛弃客户端工具 GreatNews,而起用在线 RSS 阅读工具,另外一个考虑是性能问题,订阅 Feed 超过 1000 个后,GreatNews 更新非常消耗本地资源。虽然抓虾也不错,但我基本上是用抓虾看看热文,大部分的阅读还是在 Google Reader 内,看到不错的文章就 Share 一下,通过 RSS 集成到 CNOUG.net 上,便于 DBA 圈子内的其他朋友也及时看到,共享嘛。

Google Reader 最近的好友间阅读共享功能也很有意思,虽然多数人都在质疑这个功能有泄漏隐私之嫌。我个人觉得可以通过算法来调整这个设计上的漏洞。Google 不是一项强调数据说话麽? 那就来点更智能化的东西吧。

这两天也在尝试 Soup.ioFriendFeed 这两个东西,直觉中明年要启用其中的一个。你在去年尝试并喜欢那些 Web 2.0 服务? 说一下吧

EOF