Friendfeed的MySQL key/value存储
浏览:2024次 出处信息
这是一篇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中可以放:
Python dict
JSON object
实际friendfeed存放的是zlib压缩的Python dict数据,当然这种绑定一种语言的做法具有争议性。
表结构及Index设计模式
feed数据基本上都存在entities表中,它的结构为
mysql> desc entities; +----------+------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+------------+------+-----+-------------------+----------------+ | added_id | int(11) | NO | PRI | NULL | auto_increment | | id | binary(16) | NO | UNI | | | | updated | timestamp | YES | MUL | CURRENT_TIMESTAMP | | | body | mediumblob | YES | | NULL | | +----------+------------+------+-----+-------------------+----------------+
假如里面存的数据如下
{ "id": "71f0c4d2291844cca2df6f486e96e37c", "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "title": "We just launched a new backend system for FriendFeed!", "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c", "published": 1235697046, "updated": 1235697046, }
如果要对link字段进行索引,则用另外一个表来存储。
mysql> desc index_link; +-----------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+--------------+------+-----+---------+-------+ | link | varchar(255) | NO | PRI | | | | entity_id | binary(16) | NO | PRI | | | +-----------+--------------+------+-----+---------+-------+ 2 rows in set (0.00 sec)
优点是
- 增加索引时候只需要 1. CREATE TABLE,2.更新程序
- 删除索引时候只需要 1. 程序停止写索引表(实际就是一个普通表),2. DROP TABLE 索引表
这种索引方式也是一种值得借鉴的设计模式,特别是key value类型的数据需要索引其中的内容时。
建议继续学习:
- HFile存储格式 (阅读:14538)
- 我对技术方向的一些反思 (阅读:9874)
- 淘宝图片存储架构 (阅读:9838)
- 海量小文件存储 (阅读:7558)
- HBase技术介绍 (阅读:6760)
- 存储基础知识之——硬盘接口简述 (阅读:6157)
- 在perl中连接和使用sqlite做数据存储 (阅读:5059)
- 如果用户在5分钟内重复上线,就给他发警告,问如何设计? (阅读:4872)
- HTML5本地存储初探(二) (阅读:4398)
- Redis新的存储模式diskstore (阅读:4409)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
扫一扫订阅我的微信号:IT技术博客大学习
<< 前一篇:Twitter架构图(cache篇)
后一篇:客户端应该去计算什么? >>
文章信息
- 作者:Tim 来源: Tim[后端技术]
- 标签: Friendfeed 存储
- 发布时间:2009-11-08 11:21:07
建议继续学习
近3天十大热文
- [54] IOS安全–浅谈关于IOS加固的几种方法
- [52] android 开发入门
- [52] 如何拿下简短的域名
- [51] 图书馆的世界纪录
- [50] Oracle MTS模式下 进程地址与会话信
- [49] Go Reflect 性能
- [46] 【社会化设计】自我(self)部分――欢迎区
- [46] 读书笔记-壹百度:百度十年千倍的29条法则
- [36] 程序员技术练级攻略
- [29] 视觉调整-设计师 vs. 逻辑