Friendfeed的MySQL key/value存储
这是一篇2009年初的资料
How FriendFeed uses
MySQL
to store schema-less data
,相信大部分人已经看过了。如Fenng的中文介绍
FriendFeed 使用 MySQL 的经验
。本文从不同的角度再补充下。作者几个月前也曾经在广州技术沙龙作过一次
Key value store漫谈
的演讲，许多参会人员对key value方向存在强烈的使用意愿，但同时也对完全抛弃MySQL存在疑虑，本文介绍的方案也可以给这些人员一些架构参考。
需求
250M entities
, entities表共有2.5亿条记录，当然是分库的。
典型
解决方案
:RDBMS问题：由于业务需要不定期更改表结构，但是在2.5亿记录的表上增删字段、修改索引需要锁表，最长需要1小时到1天以上。
Key value方案评估Document类型
数据库
，如CouchDB
CouchDB问题：
Performance？ 广泛使用？ 稳定性？ 抗压性？
MySQL方案MySQL相比Document store优点：
- 不用担心丢数据或数据损坏
- Replication
-
非常熟悉它的特性及不足，知道
如何
解决
结论综合取舍，使用MySQL来存储key/value(schema-less)数据,value中可以放：
# |7 u. ~& s: q! y. C0 T% I( m
Python dict
+ N5 W# e/ |+ w; i
JSON object
– B$ l. K5 b! `2 O” `0 o: D6 |- |
实际friendfeed存放的是zlib压缩的Python dict数据，当然这种绑定一种语言的做法具有争议性。
5 l4 W* s: h” |* [- \
表结构及Index设计模式feed数据基本上都存在entities表中，它的结构为