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

treePerson 11天前 4

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

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

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

最新回复 (14)
  • simonlu9 7天前
    引用 2
    没必要分表,帖子一个表,评论一个表就够了,再不如评论按帖子 id 分表,参考下 phpwind,和 discuz 性能不是杠杠的
  • 楼主 treePerson 7天前
    引用 3
    @simonlu9 谢谢,这两个我去研究研究。那么所以你的意思是,区区几万几百万数据在一个表里,数据库完全能带的动是么。如果分表的话一个帖子 id 一个表也没什么问题对吗?是这样概念吗
  • kiracyan 7天前
    引用 4
    分表一般是根据 id hash /id 后缀 / 时间
  • opengps 7天前
    引用 5
    你没有实际经历过的话,所有的听说都不值一提
    先做,你能体会到很多“总结”的内层含义
  • qiayue 7天前
    引用 6
    mysql 单表你放几千万上亿条数据都可以
    具体到性能来说,做好索引可以解决 90%的性能问题
  • ebingtel 7天前
    引用 7
    对于新手而言 不要考虑太多 先碰到问题 再解决问题……当然 1L 说的是对的 千万级问题也不大
  • ericgui 7天前
    引用 8
    @qiayue +1
  • xunbug 7天前
    引用 9
    @treePerson 如果你数据库里已经存下几百万帖子数据,那就说明完全能够商业化挣钱了,有钱了有的是方案解决。

    不是抬杠,V2EX 的老哥们写个博客都要考虑百万并发、写个小工具都要考虑高可用、搞个没人的论坛还得考虑多地容灾,累不累啊,安安心心用最快的速度把代码撸完。不然一个月过去了,你还在考虑方案,可能这个时候你已经完全不想做了
  • lower 7天前
    引用 10
    既然表关系这么简单,干嘛不直接用 mongodb 这种的……
  • simonlu9 7天前
    引用 11
    @treePerson 没到千万级不用考虑分表操作,你想想 b 树千万级的查询只需要 3,4 层 io 操作,足足够以应付,而且论坛这种读多写少的操作,完全可以用缓存来优化
  • tabris17 7天前
    引用 12
    所有用户提交的 post 一个表,用于检索的索引一个表
  • huobazi 7天前
    引用 13
    1 》 dz pw 不香吗?
    2 》 数据库不建议 200 个表? 那还好意思叫数据库么。
    3 》 多年前那么些个用虚拟主机做大的论坛了解一下 im286, xmfish, xx 的就更多了

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

    一个用户一个访问都没有,考虑啥性能啊,随便下个程序就够玩了,等你真的需要考虑性能了,你也发达了。
  • rapperx2 7天前
    引用 14
    数据亿级可能都是上 ES,热数据缓存,读写分离,分表,堆机器。

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

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

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


    借 4 楼的话:
    "你没有实际经历过的话,所有的听说都不值一提
    先做,你能体会到很多“总结”的内层含义"
  • MrWhite 7天前
    引用 15
    @lower 我们上次用 mongodb 然后又改回 mysqll 。 都不咋会用... 不过感觉好使。
  • 游客
    16
返回