这是一个创建于 1861 天前的主题，其中的信息可能已经有所发展或是发生改变。
本来公司一直用的 mongodb，也挺好用。现在要开放评论。mongodb 单文档的限制是 16M，能满足绝大部分需求，但是评论这个东西理论上条数大小无上限，这样继续用 mongodb 存评论好像不合适。
我现在该用什么存？ mysql 还是别的什么？或者有什么办法让 mongo 突破 16M 限制？ 用 mongodb 的 gridfs 存储的话性能跟得上吗？看网上评测 mongodb 的 gridfs 的性能好像不太行。 其实如果 mongodb 的 gridfs 性能能达到 mysql 的水平我觉得就可以了，毕竟如果存 mysql 的话冗余数据太多了
第 1 条附言 · 2019-03-13 23:54:32 +08:00
我是这么设计的
{
user:“张三”,
comment：[
{"content":"东西比较靠谱","time":"2019 年 1 月 20 日"},
{"content":"东西很烂","time":"2019 年 2 月 20 日"},
{"content":"卖家很热心","time":"2019 年 3 月 20 日"},
.......//可能有很多条
]
}
{
user:“张三”,
comment：[
{"content":"东西比较靠谱","time":"2019 年 1 月 20 日"},
{"content":"东西很烂","time":"2019 年 2 月 20 日"},
{"content":"卖家很热心","time":"2019 年 3 月 20 日"},
.......//可能有很多条
]
}
第 2 条附言 · 2019-03-13 23:54:54 +08:00
我这么设计是不是有问题，那应该怎么设计？
 |
1
514146235 2019-03-13 15:11:25 +08:00
单条评论超过 16M ？几乎不可能吧。
|
 |
2
Trim21 2019-03-13 15:15:19 +08:00 via Android
啥样子的评论这么大…
|
 |
3
ccoming 2019-03-13 15:19:02 +08:00
这个到底是评论还是论坛回复？
|
 |
4
haozxuan001 2019-03-13 15:27:13 +08:00  1
第一、 图片、音频、视频等适合 gridfs ；
第二、在你的认知中 mysql 能无限存下去的原因，是因为每条回帖记录一条，只要盘不爆，不担心大小限制； 第三、谁跟你说我一个帖子和回帖要存在一个 doc 里面的，你如果设计回帖为数组的话，你现在的操作就是向一个数组中无限制 append 数据，抛开数据库不聊，这个开发模式也是极为糟糕的； 解决方案：只需要在一条 doc 中添加一个 parentId，约定回帖条数超过 200 条，新开一个 doc 存储； PS：mongo 看似随便，但基本的设计理念还是要有的，否则就太随便了。 |
 |
5
marcong95 2019-03-13 15:35:04 +08:00
你应该是把评论内容作为 Embedded Document 塞到一条 Document 里面了，你可以考虑弄成个链表一类的？毕竟超过 16M 的情况应该是挺少的，没必要上 GridFS ？
|
 |
6
xkeyideal 2019-03-13 16:27:08 +08:00
评论小于 16M 的存 mongodb，超过 16M 的存 gridfs，觉得 gridfs 的性能有问题，评论存 ceph，mongo 里存 ceph 的文件地址
|
 |
8
51300520 OP |
|
9
xkeyideal 2019-03-14 09:00:38 +08:00
@51300520 这么设计肯定有非常多的问题
1、用户删除某条评论，你这样怎么删，评论也应该有个唯一 ID 吧？ 2、评论需求后续有扩展，需要加字段，而且某个需求需要在扩展的字段上加索引，你怎么加？ mongodb 虽然没有关系型数据库的设计范式要求，也不能随便来吧，无论哪种 db 的设计在某种程度上至少能满足各第二范式吧 "content":"评论库设计的有很多潜在问题","time":"2019 年 3 月 14 日" |
 |
11
shd 2019-03-14 13:24:20 +08:00
我寻思这最少两张表吧、post,reply
|
Select Language