类似微博、朋友圈这样的帖子类数据库怎么设计？

[SnowFlower]

类似微博、朋友圈的文字+图片的短文，这种需求的数据库是用 MySQL 吗，文章内容文字+图片怎么设计存储比较合适？

[Tn5ohB1Yecdk3qCK]

感觉 mongodb 这种文档数据库会好点

[cgpiao]

图片不都是 ObjectStore 然后数据库里插入对应的 Key 吗，貌似跟数据库类型没啥关联吧。

[qiayue]

楼上别瞎说，图片、视频等原始文件绝对不能存数据里里，所以其实关系数据库足够。
如果是图文混排，可以先这样
文字文字文字[img]path/name.jpg[/img]文字文字[video]path/name.mp4[/video]文字文字

如果类似微博、朋友圈，用不同字段存储就行，文字存文字自动，图片、视频存路径

[qiayue]

@qiayue 更正，1 楼别瞎说

[tyrantZhao]

图片视频绝对不能存 db

[opengps]

123 楼都没错，文件使用第三方对象存储已经是行业常用做法，
数据库基本只是文本类信息
微博朋友圈这种时间线性质应用，“分页”不适合，但不能因此排除关系型数据库，使用关系型可以按照指定起点拉取指定行结果的方式。也可以直接使用非关系型的，例如时序数据库存短篇幅信息，长篇幅则把内容单独拆出来存储

[psychoo]

图片、视频存路径

[gz911122]

学习一下,一直想知道这种表结构的最佳实践是啥

[zhengjian]

我也比较好奇怎么存储顺序图片

https://www.v2ex.com/t/560631

[Dabaicong]

23 楼说的对，原始文件存对象存储，比如阿里云的 oss。
数据库中存放对应的存储路径就行

另外，全文检索在内容查询上会比较好

[LudwigWS]

我很好奇为什么能时间线、推送能做得相应这么快。

[lhx2008]

大概率还是用关系数据

[Tn5ohB1Yecdk3qCK]

@qiayue #4
我瞎说?谁会把图片视屏丢数据库??

[justfortest]

@LudwigWS 消息队列，预处理将要推送的时间线消息 id 放到 redis，从 redis 拉取，过于久远历史消息有必要时再从 db 取，区分活跃不活跃，是否大 v 采取不同的 push/pull 方式

[aut0man]

为什么我接触的从来都是 db 存路径…难道可以直接把图片视频存 db ？？@@ 谁能科普一哈（那啥我是个产品）

[areless]

mysql 做不到的，当时就因为这个造出来那么多 nosql 数据库。关注十万人去 mysql 里捞一个你关注的 timeline 试试。对于普通用户，被关注对象发言直接存进每一个普通用户 timeline 里面～对于 1 万粉以上又另外处理。

[iConnect]

微博和普通 blog 的存储方式并没有本质不同； newsfeed 的推送是推拉结合的方式，活跃用户先推，僵尸用户等自己登录后来拉。

[ooToo]

图片视频是 s3, HDFS 这种, 剩余的就是存 db, 按照需要 nosql or sql

[Jooooooooo]

图片视频肯定是 s3 啊, 要不然同一张图片别人发好多次得存好多次, 肯定是存个 id

[wangyzj]

redis + mysql + hbase
够你玩了