未分類
8 11 月 2020

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

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

資深大佬 : treePerson 2

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

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

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

大佬有話說 (14)

  • 資深大佬 : simonlu9

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

  • 主 資深大佬 : treePerson

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

  • 資深大佬 : kiracyan

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

  • 資深大佬 : opengps

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

  • 資深大佬 : qiayue

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

  • 資深大佬 : ebingtel

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

  • 資深大佬 : ericgui

    @qiayue +1

  • 資深大佬 : xunbug

    @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 。 都不咋会用… 不过感觉好使。