这是一篇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表中，它的结构为

<pre class="prettyprint <a href=" http:=" data-ke-src=" www.ahlinux.com="" php="" "="" target="_blank" style="word-wrap: break-word; margin-top: 0px; margin-bottom: 0px; padding: 0px;">php"> 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类型的数据需要索引其中的内容时。

from:http://timyang.net/data/friendfeed-mysql-schema-less/​