MySQL key/value存储方案(转)

需求

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类型的数据需要索引其中的内容时。

转载于:https://www.cnblogs.com/ggjucheng/p/3349107.html

总结

以上是生活随笔为你收集整理的MySQL key/value存储方案(转)的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。