×

《How FriendFeed uses MySQL to store schema-less data》阅读笔记

天外来信 天外来信 发表于2012-09-29 11:47:12 浏览3964 评论0

抢沙发发表评论

How FriendFeed uses MySQL to store schema-less data 这篇文章发布已经有一段时间了,之前也读过没留下什么映像,最近又重读了一遍做了一些笔记,内容如下。

  • 数据库查询需要得到索引的支持,索引在加速查询的同时,也会直接影响了数据插入、更新的速度。另外,由于FriendFeed的数据量比较大,维护索引而引起的相关表的锁表时间会比较长。
  • FriendFeed使用了读写分离技术和memcache来提升数据读取吞吐量
  • FriendFeed使用了Sharding技术来提升数据写入吞吐量
  • 由于Sharding技术的使用,有些很基础的关系运算就不能被支持了,例如Join。这样Mysql退化成了一个键值(KeyValue)数据库。
  • 键值数据库很多。FriendFeed没有使用专门的键值数据库可能考虑多种原因
    • FriendFeed对Mysql有比较好的掌握,而其他的相关技术没有深入的研究和使用经验
    • CouchDB还不能满足某些系统的高吞吐量需求,参考http://userprimary.net/user/2007/12/16/a-quick-look-at-couchdb-performance/
    • Mysql已有的一些功能,CouchDB还不能提供
  • 存储表的物理主键是autoincremen,而逻辑上的主键使用的是uuid。之所以这样做是因为uuid的不重复性对数据分布有好处,但因为InnoDB表类型会按照主键排序,此时如果使用类似uuid这样的无序串作为主键的话,那么当插入新行的时候,新行在数据文件中的位置是不确定的,这就会带来一个沉重的IO负担,而如果采用自增字段作为主键的话就不存在这个问题,因为新行始终位于数据文件的结尾。

 

关于FriendFeed如何保存schema-less数据的细节,这里就不在描述了,大家可以参考How FriendFeed uses MySQL to store schema-less data 或是老王的解读FriendFeed对MySQL的使用

 

参考资料

How FriendFeed uses MySQL to store schema-less data 原文

解读FriendFeed对MySQL的使用

评论列表

访客