一个关于 论坛后台数据架构 的初级问题

[treePerson]

正在构思一个类似于论坛的后台项目，因为没有实践经验，有些问题没想清楚： 假设有两种对象，一种是帖子，包括帖子内容、发帖者的信息等数据；一种是回复，包括回复内容，回复所属的帖子，回复者的信息等数据。 这两类数据在后台怎样存储比较好，或者说有什么常见的方案？

假设有 1 万个帖子，平均每个帖子有 10 条回复。 主要的困惑是，如果在数据库中安排两个表，一个表存全部的帖子，一个表存全部的回复，也许单个表太大了，而且受不了膨胀，恐怕会影响性能。 但如果分成多个表，甚至一个贴子一个表（有这样分的吗？），分的表又太多。听说数据库不建议有 200 个左右以上的表，对么？

所以我的问题可以理解为，将数据涂开抹匀用什么方案比较好？以及，积攒到多厚的数据，就需要涂开抹匀？ 只有一台 40G 硬盘 2G 内存的服务器，大概能承受什么等级的论坛数据？ 或者有其他我尚所不知的思路，也望交流。 谢谢！

[simonlu9]

没必要分表，帖子一个表，评论一个表就够了，再不如评论按帖子 id 分表，参考下 phpwind,和 discuz 性能不是杠杠的

[treePerson]

@simonlu9 谢谢，这两个我去研究研究。那么所以你的意思是，区区几万几百万数据在一个表里，数据库完全能带的动是么。如果分表的话一个帖子 id 一个表也没什么问题对吗？是这样概念吗

[kiracyan]

分表一般是根据 id hash /id 后缀 / 时间

[opengps]

你没有实际经历过的话，所有的听说都不值一提
先做，你能体会到很多“总结”的内层含义

[qiayue]

mysql 单表你放几千万上亿条数据都可以
具体到性能来说，做好索引可以解决 90%的性能问题

[ebingtel]

对于新手而言 不要考虑太多 先碰到问题 再解决问题……当然 1L 说的是对的 千万级问题也不大

[ericgui]

@qiayue +1

[hahaba]

@treePerson 如果你数据库里已经存下几百万帖子数据，那就说明完全能够商业化挣钱了，有钱了有的是方案解决。

不是抬杠，V2EX 的老哥们写个博客都要考虑百万并发、写个小工具都要考虑高可用、搞个没人的论坛还得考虑多地容灾，累不累啊，安安心心用最快的速度把代码撸完。不然一个月过去了，你还在考虑方案，可能这个时候你已经完全不想做了

[lower]

既然表关系这么简单，干嘛不直接用 mongodb 这种的……

[simonlu9]

@treePerson 没到千万级不用考虑分表操作，你想想 b 树千万级的查询只需要 3,4 层 io 操作，足足够以应付，而且论坛这种读多写少的操作，完全可以用缓存来优化

[tabris17]

所有用户提交的 post 一个表，用于检索的索引一个表

[huobazi]

1 》 dz pw 不香吗？
2 》 数据库不建议 200 个表？ 那还好意思叫数据库么。
3 》 多年前那么些个用虚拟主机做大的论坛了解一下 im286, xmfish, xx 的就更多了

看看 v2，你这个帖子的 id 是 727104 。

一个用户一个访问都没有，考虑啥性能啊，随便下个程序就够玩了，等你真的需要考虑性能了，你也发达了。

[rapperx2]

数据亿级可能都是上 ES，热数据缓存，读写分离，分表，堆机器。

我们有个项目单表 2 亿多数据，基本上都是秒查询 (SQLServer)。

一般真正数据多的，都会根据每个需求做相应的方案。

就比如你查询帖子里一些统计数据，是实时查询出来，还是定时任务隔天统计到表储存。那你数据只需要实时查询统计当天的在做总和就行了。


借 4 楼的话:
"你没有实际经历过的话，所有的听说都不值一提
先做，你能体会到很多“总结”的内层含义"

[MrWhite]

@lower 我们上次用 mongodb 然后又改回 mysqll 。 都不咋会用... 不过感觉好使。