一直比较好奇 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–
我思考了很久得出来的方案跟他们一样。。。
很好的经验,值得我们思考,尤其是”让既有功能满足更多用户而不是添加更多的功能”的哲学。
用表来代替索引,却感觉不一定值得推广。因为表的搜索速度还得依靠索引。宏观上,索引仍然存在,反而增加了运算量,增加了表的空间。唯一的好处是把索引分步到多个文件上了。
个人之见,欢迎斧正。
很好的经验,值得我们思考,尤其是”让既有功能满足更多用户而不是添加更多的功能”的哲学。
用表来代替索引,却感觉不一定值得推广。因为表的搜索速度还得依靠索引。宏观上,索引仍然存在,反而增加了运算量,增加了表的空间。唯一的好处是把索引分步到多个文件上了。
个人之见,欢迎斧正
虽然并不能完全看懂。
不过里面提供了很多有趣的思想。
“对待网站功能的态度: 让既有功能满足更多用户而不是添加更多的功能。”
用空间去换取维护成本。
对于一个DBA来说。数据库的建立总是很矛盾。时间、空间、成本,总是相互矛盾的。想要效率,去用空间换时间,却提高了成本。考虑了成本,却忽略了效率。
对于软件来说,永远没有最好的。
而我个人认为:最好的软件是,在其中找个平衡点,一个让客户最满意的平衡点。鱼和熊掌不能兼得的情况下,更多的应该考虑下胃的感受。
呵呵
最近写代码觉得关系性数据库很难应付这种非结构数据。起码用起来不自然,看了觉得不是这么一回事,不明觉厉