friendfeed如何使用mysql

读完这一篇How FriendFeed uses MySQL to store schema-less data ，颇有感触

 

文中主要表达了几个意思：

＊数据量相当大的时候，维护mysql本身的索引非常困难，新增／删除索引都很费资源

＊新的方案使用mysql，但是只是用他基本“数据库”的功能，而不使用“关系”的功能，就是说，只用mysql来保存数据，以及简单的单表查询，不使用join之类的功能

＊没有schema，表结构很简单，只有id,last_updated,content，这样的几个字段，其中content是一个大字段，所有内容放在这里面

＊索引由应用来维护，为每一条索引创建一张表，数据的增珊改由应用来进行

＊查询索引由应用来进行，先查索引，然后取数据

＊提供api来封装以上这些逻辑，包括数据分区逻辑的实现

 

这里其实是有一点问题需要解决的，由于索引自己去维护，和主表的数据肯定会有一些不一致，特别是新增索引的时候，需要异步的去初始化这个索引，而且还需要做增量，只有应用对这个一致性要求不高的时候才能使用这个方案。

 

还有一个问题，如果某次查询要查两个索引，同时每个索引过滤出来的数据比较多的时候，在应用这端的处理就会消耗比较大了，要对多个结果集进行处理（交集或者幷集），这个问题其实主要要根据应用的特点来看的，采用了这种数据切分的方案，对应用本身就有一些限制的，换一个角度讲，只有应用的特征适合做这种数据切分，才能应用这种方案。看起来像废话，但是是真的，没有完美的方案，只有合适的方案 。

 

其实以上的功能，除了分区以外，couchdb 都能支持，不过couchdb还不够成熟，至少没有一个大规模部署的先例存在。而且couchdb更彻底，索引都帮你维护了，你只需要保存你的entity，再告诉他哪些内容要索引，而且索引都是你自己写一个函数的，期待couchdb的成熟。

 

类似的方案以前我想过，不过不是用mysql，而是使用bdb来做存储，不过只是想了一下，没做，现在看到人家在使用了，才想起来。

 

还可以看看：Quick Reference to Alternative data storages