Daniel Hu的技术生活博客

项目

不信任的博弈

进度必然是符合质量的功能点的交付，而不是狭隘的代码完成。

需求入门 － 用Kano模型来确定需求优先级

Scalability

HBase vs Cassandra: 我们迁移系统的原因

Management

敏捷个人－认识自我，管理自我

10步让您成为一名优秀的 Web开发人员

SOA

为什么现在SOA成功的关键是数据建模？

数据库

 XtraDB/Innodb内部结构示意图

Data Access Layer（DAL）方案

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的使用