MySQL key/value 表的两种设计

最新推荐文章于 2024-09-12 10:38:25 发布

iteye_4945

最新推荐文章于 2024-09-12 10:38:25 发布

阅读量2.8k

点赞数

分类专栏： mysql 文章标签：数据库设计模式数据结构与算法

本文链接：https://blog.csdn.net/iteye_4945/article/details/82241242

版权

本文分析了在面临频繁更改表结构需求时，使用MySQL作为Key/Value存储的方案，对比了与Document数据库如CouchDB的优缺点。通过实例展示了Key/Value模式如何简化数据库设计和扩展用户信息存储，同时也指出了该模式在数据类型约束和多字段过滤上的局限性。

摘要由CSDN通过智能技术生成

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