×

Loading...

专业角度解释分坛和移贴的必要性

关系型数据库的数据存在众多表格中。一个网站的数据库,简化一点说,每个分坛都对应一个表格(或者几个表格,跟设计有关)。

一个表格如果数据过多,表格太大,用户每次刷新页面,速度就很慢。反之,速度就快。也就是说,很可能造成用户打开论坛一很慢,而论坛二很快的情况。

为了用户体验,网站设计者为了不让各表格之间过于不平衡,就希望用户配合,按照分坛的用途发帖,这样数据会自动进到相应的表格。而移贴子,就是把某些数据从表格一挪到表格二。

因此,对普通用户来说,去合适的分坛发帖,也是对网站工作人员的理解和尊重。

估计这也是为什么肉联还有历史区的其中一个原因。最近的帖子对应的数据,被阅读的可能性也大,而久一点的数据,也会挪去另一个表格,这样可以最大限度保证大多数人刷肉联的速度够快。

当然还有很多很多技术甚至运营细节,总之老大不易,维持这么大的免费网站,用户体验还很好,非常牛。

Sign in and Reply Report

Replies, comments and Discussions:

  • 工作学习 / 学科技术 / 专业角度解释分坛和移贴的必要性 +2

    关系型数据库的数据存在众多表格中。一个网站的数据库,简化一点说,每个分坛都对应一个表格(或者几个表格,跟设计有关)。

    一个表格如果数据过多,表格太大,用户每次刷新页面,速度就很慢。反之,速度就快。也就是说,很可能造成用户打开论坛一很慢,而论坛二很快的情况。

    为了用户体验,网站设计者为了不让各表格之间过于不平衡,就希望用户配合,按照分坛的用途发帖,这样数据会自动进到相应的表格。而移贴子,就是把某些数据从表格一挪到表格二。

    因此,对普通用户来说,去合适的分坛发帖,也是对网站工作人员的理解和尊重。

    估计这也是为什么肉联还有历史区的其中一个原因。最近的帖子对应的数据,被阅读的可能性也大,而久一点的数据,也会挪去另一个表格,这样可以最大限度保证大多数人刷肉联的速度够快。

    当然还有很多很多技术甚至运营细节,总之老大不易,维持这么大的免费网站,用户体验还很好,非常牛。

    • 从啥专业角度来分析的? +1
      • RDBMS +1
    • 科技是为人的 needs 服务的。分享不是事,是各个 ego 间的碰撞,强烈碰撞,产生了巨大的非分享型流量。 +1
      • 老陈是从心理和社会学层面进一步丰富
        • My ego. 😂
          • 也得到极大丰富
    • 技术是为客户体验服务的。 +1
      • 对也不全对。技术不是万能的,也不是孤立的。网站需要在技术,某个人和大多数人的用户体验,运营成本,人力投入等多方面找平衡点。举个例,可能数据库和服务器升级到ChatGPT 那么大的后台,那就论坛随便放。但是对肉联来说,不现实。 +1
        • 如果每秒增加一条回复,40字,一个小时3600*40,每天18小时繁忙时间,一年365天,总共365*18*40*3600=946M,大概1G的数据,我觉的没有必要分库分表。 +1
          • 一条记录不止40字节。
            • 你这条不到40
              • 記錄裏包含各種ID,時間戳,你沒算進去。 +1
                • 好,增加10倍400个字节,10.G也远远不到分库分表,索引做好了,一点问题都没有
                  • 我覺的兩張表殼可能夠,當前表和歷史表。要算的話就是一年能產生多少條記錄。假如是20 MILLION,有沒有辦法做到快速的索引。多個表就沒有這方面的考慮。
                    • 什么叫快速的索引,几个TB的表一样索引,在生产线上的表都是几百个billions of records
                      • 哪一條生產綫上能有幾百個BILLIONS records? 你確認這幾百個BILLIONS RECORD 是放在一張表格裏嗎? 你不覺的LZ 知道ROLIA 論壇數據庫表格結構嗎?
                        • 天天看着这些表,如果rolia的表设计的不是最好的,导致现有的数据增长会增加infrastructure 的支出,这个可以理解,解决方案也有很多种,但是楼主说的是通用网站设计,这个就不一样了,象知乎这种网站,也要这么设计吗?
                          • 這個例子好。有可能書庫系統本身就有辦法做到一張邏輯表可以存儲幾個BILLIION 的記錄,不影響查詢, 但是硬件了?
                            • 这个是国内面试必问问题
                              • 這邊面試不會這個樣子,就是問寫數據庫的一些基本概念。工作中很少有機會碰到海量的數據,几十個MILLION 數據在一張表裏已經很大的。
    • 事实上就是一个坛如果足够贴多, +2
      它会从一个3NF隐性存在于某个field一个以上的关系造成塌陷成1NF,所以分坛的目的其实和1NF拆分成3NF的过程。这是个信息论的经典问题,当数据足够大,entropy就会足够小,当entropy足够小,必然会有key产生,这个时候RDBMS会从3NF塌陷成1NF就需要拆分了。
    • 一个字段而已 想多了 +1
    • 真的假的,第一次听说网页加载性能提升靠手动, 而不是靠算法和设计实现 +2
    • 那从专业角度讲,是不是少几个表/论坛速度更快,有很多分论坛内容都有交叉,最好重新分类,精简一下
      • 表越少平均每个表的数据量就越大,遍历/搜索时间越长;表多虽可分担负荷,但表过多同样耗资源,需找到一个平衡点。当然,论坛毕竟是租用的服务器和空间,受服务商的平台条件制约,若不差钱换更好的平台+全面升级系统,很多问题就解决了,但不就是差钱和老大孤独单干么?
    • 论坛的历史数据量已积累到某个级别了,搜索操作越来越耗时耗资源,也牵制/影响了当前操作响应速度,老大为解决这个问题,刚刚才折腾了搜索功能,将查询范围缩小限定于半年内,是为改善/维持响应速度和防止系统崩溃?但估计也只是权宜之计…
    • 谢版主加✴️, 谢各位大侠参与讨论🤝。不一一回复了。我是估摸着写的,疏漏在所难免,毕竟后台也看不见。猜测时考虑了肉联的历史,infrastructure 是二十年前的。感觉老大不易,选论坛发帖的时候大家多花一秒钟选择合适的论坛总没什么坏处。
    • 以后老大用AI机器人帮忙挪贴,不就省事了?