这是一个创建于 1457 天前的主题，其中的信息可能已经有所发展或是发生改变。
正在构思一个类似于论坛的后台项目，因为没有实践经验，有些问题没想清楚： 假设有两种对象，一种是帖子，包括帖子内容、发帖者的信息等数据；一种是回复，包括回复内容，回复所属的帖子，回复者的信息等数据。 这两类数据在后台怎样存储比较好，或者说有什么常见的方案？
假设有 1 万个帖子，平均每个帖子有 10 条回复。 主要的困惑是，如果在数据库中安排两个表，一个表存全部的帖子，一个表存全部的回复，也许单个表太大了，而且受不了膨胀，恐怕会影响性能。 但如果分成多个表，甚至一个贴子一个表（有这样分的吗？），分的表又太多。听说数据库不建议有 200 个左右以上的表，对么？
所以我的问题可以理解为，将数据涂开抹匀用什么方案比较好？以及，积攒到多厚的数据，就需要涂开抹匀？ 只有一台 40G 硬盘 2G 内存的服务器，大概能承受什么等级的论坛数据？ 或者有其他我尚所不知的思路，也望交流。 谢谢！
第 1 条附言 · 2020-11-19 15:13:06 +08:00
诸位是远方的灯火，是天上的明星。
 |
1
simonlu9 2020-11-19 14:06:57 +08:00
没必要分表，帖子一个表，评论一个表就够了，再不如评论按帖子 id 分表，参考下 phpwind,和 discuz 性能不是杠杠的
|
 |
2
treePerson OP @simonlu9 谢谢，这两个我去研究研究。那么所以你的意思是，区区几万几百万数据在一个表里，数据库完全能带的动是么。如果分表的话一个帖子 id 一个表也没什么问题对吗？是这样概念吗
|
 |
3
kiracyan 2020-11-19 14:11:20 +08:00
分表一般是根据 id hash /id 后缀 / 时间
|
 |
4
opengps 2020-11-19 14:11:33 +08:00  1
你没有实际经历过的话，所有的听说都不值一提
先做，你能体会到很多“总结”的内层含义 |
 |
5
qiayue 2020-11-19 14:12:31 +08:00
mysql 单表你放几千万上亿条数据都可以
具体到性能来说，做好索引可以解决 90%的性能问题 |
 |
6
ebingtel 2020-11-19 14:26:10 +08:00
对于新手而言 不要考虑太多 先碰到问题 再解决问题……当然 1L 说的是对的 千万级问题也不大
|
 |
8
hahaba 2020-11-19 14:38:04 +08:00 4
@treePerson 如果你数据库里已经存下几百万帖子数据，那就说明完全能够商业化挣钱了，有钱了有的是方案解决。
不是抬杠，V2EX 的老哥们写个博客都要考虑百万并发、写个小工具都要考虑高可用、搞个没人的论坛还得考虑多地容灾，累不累啊，安安心心用最快的速度把代码撸完。不然一个月过去了，你还在考虑方案，可能这个时候你已经完全不想做了 |
 |
9
lower 2020-11-19 14:52:27 +08:00
既然表关系这么简单，干嘛不直接用 mongodb 这种的……
|
|
10
simonlu9 2020-11-19 15:58:42 +08:00 1
@treePerson 没到千万级不用考虑分表操作，你想想 b 树千万级的查询只需要 3,4 层 io 操作，足足够以应付，而且论坛这种读多写少的操作，完全可以用缓存来优化
|
 |
11
tabris17 2020-11-19 16:04:21 +08:00 via iPhone
所有用户提交的 post 一个表，用于检索的索引一个表
|
 |
12
huobazi 2020-11-19 16:15:12 +08:00
1 》 dz pw 不香吗？
2 》 数据库不建议 200 个表？ 那还好意思叫数据库么。 3 》 多年前那么些个用虚拟主机做大的论坛了解一下 im286, xmfish, xx 的就更多了 看看 v2，你这个帖子的 id 是 727104 。 一个用户一个访问都没有，考虑啥性能啊，随便下个程序就够玩了，等你真的需要考虑性能了，你也发达了。 |
 |
13
rapperx2 2020-11-19 16:25:53 +08:00
数据亿级可能都是上 ES，热数据缓存，读写分离，分表，堆机器。
我们有个项目单表 2 亿多数据，基本上都是秒查询 (SQLServer)。 一般真正数据多的，都会根据每个需求做相应的方案。 就比如你查询帖子里一些统计数据，是实时查询出来，还是定时任务隔天统计到表储存。那你数据只需要实时查询统计当天的在做总和就行了。 借 4 楼的话: "你没有实际经历过的话，所有的听说都不值一提 先做，你能体会到很多“总结”的内层含义" |
Select Language