[计数] 请问在论坛里怎么计算每个帖子的点计量的？？

北京野狼

原帖由 "wangyih" 发表：


另开一个表记录这些信息，这个注意可能是可行的

最糟糕的主意。
本来在一个表里面，一次数据库操作就读写完成，这样操作两个表也就是两个文件去做I/o.更糟糕的，如果操作时候在一个表中出现阻塞就更麻烦。
存储帖子的表有多少记录这个新表也要有多少记录浪费空间。

论坛读写帖子的时候还会有好多其他的事情要做，象sina和人民日报那样的论坛，讲究层数的，还要计算分数，更新相关父帖子和父帖子的父帖子，记录最后读取的时间和IP等。计数是最基本的事情数据库操作。
如果读写出现阻塞，只能是表结构设计太差或者服务器差。
和写到文件是一样的馊主意

SATAND

原帖由 "北京野狼" 发表：


最糟糕的主意。
本来在一个表里面，一次数据库操作就读写完成，这样操作两个表也就是两个文件去做I/o.更糟糕的，如果操作时候在一个表中出现阻塞就更麻烦。
存储帖子的表有多少记录这个新表也要有多少记录浪费?.........

你忘记了，人家sina等zt有钱，用的是集群

北京野狼

原帖由 "SATAND" 发表：


你忘记了，人家sina等zt有钱，用的是集群

总把集群挂嘴边。再怎么集群也会出现一个板块一个帖子热度高
大量的读和写。而且一般的情况如果数据量没大到无法控制的情况
数据库和存储都必须集中，集群的也都是web服务器。

再说sina的论坛数据库就一台机器，没做集群这我知道

ukalpa

占个层, 我先去把mysql知识补齐了过来会招^^

SATAND

原帖由 "北京野狼" 发表：


总把集群挂嘴边。再怎么集群也会出现一个板块一个帖子热度高
大量的读和写。而且一般的情况如果数据量没大到无法控制的情况
数据库和存储都必须集中，集群的也都是web服务器。

再说sina的论坛数据库就一台机..........

集群是动态分布流量的，其本质就是分流IO
理想的集群是完整集群，但如果如你所说，多台论坛服务器使用了一个raid，至少也避免了单台大队列
另，一个scsi raid的io性能能达到多高呢？没有做过应用级的测试。昨天模拟了一个DDoS攻击，得出结论，用一台机子时，即便到了系统崩溃，raid也不会出问题。
测试方法为两台serv挂一个阵列柜，通过5台域内主机发送攻击数据，在serv（HP UNIX）写一个c端接收攻击数据，并频繁向数据库读写数据（Oracle 9i），并用另一台个人机模拟检测服务器，定时从阵列柜检索数据。攻击7分钟左右hpunix死掉，阵列柜一直保持正常服务。
或者这样的测试能够说点问题。一个接收socket数据后操作数据库的c daemon不过百行，完全可以自己重复一下。

再，业务关系，知道sohu.com的服务器情况，但是小日本的东西还真是没有看过，请教sina的服务器是怎样的体系呢？

北京野狼

原帖由 "SATAND" 发表：


集群是动态分布流量的，其本质就是分流IO
理想的集群是完整集群，但如果如你所说，多台论坛服务器使用了一个raid，至少也避免了单台大队列
另，一个scsi raid的io性能能达到多高呢？没有做过应用级的测试。昨天..........

你的测试和集群也没有关系阿。而且即便一个中型的网站也会在网关上拒绝ddos的.设置apache上就可以，大不了是访问不了了，至少保证不能随便让服务器死掉。

我见过的真正意义上的数据集群（不是多台web那种集群） 只有电信的计费和大的邮件系统。那都是数据量十几个T的才不得不做数据集群。
如果就几百兆的数据就是发布，那要是查询一个人在c语言php两个版的发言，还要到两个机器上去查询。据我所知世界上没有做数据发布的论坛系统，到有设置主从的。
sina的论坛其实不怎么样，也不是sina的主营项目，数据库就是一台好像是dell的机器，他们说10多万人民币。然后有多少台web我不知道。

还有说sina是日本的公司其实都是胡说

jhsea3do

谁说sina是日本的东西了....

SATAND

sina是支那的发音吧
而且前几天盛传的那个流言说只要在sina的论坛谈论sina与支那的意思就会被封
我试过，结果我的免费信箱都不能用了

powerpolly

大家好，
      neoanthropic的一篇贴子看来引起一番唇枪舌剑，两位仁兄各执一词都有一定道理，我这里也补充一下，象贴子计数、网页点击量等涉及到“大量”计数单位的问题，目前普遍采用数据库。我于是提出几个焦点：
      A》凡涉及大量需要计数的对象只可能考虑在数据库里实现；
      B》update包括一次select和一次I/O；
      C》同时的多个请求可以在单独进程执行；
      D》查询请求的执行通过“游标”进行，每个查询ID都有自己的游标，游标实质是一个指针，update操作通过当前指针进行。
      如果不同意上述几点，您不必看下面的文章。
      对A的说明：
         如果只是少量计数单位如部分网页需要计数点击量，完全可以用读写文件来实现，不必大动干戈用数据库，但对于贴子而言，任何一篇贴子均要计数，从几十万到成百上万的贴子规模来看，用读写文件显然是不明智的，又因为贴子都是放在库里，所以只考虑用数据库实现。
      为简化问题，可以假定现在只要求找到一个贴子并显示贴子内容并且还要更新点击量字段，于是我们向DB提交Select，游标指针定位于该记录，于是取出用于前台的数据，并update点击率字段，前面已说明update包括select过程和I/O过程，而此时的游标正指向该记录，所以不必再select，直接I/O，到此，问题的焦点集中在select和I/O谁开销大的问题。
   I/O的开销，包括I/O队列等待、磁盘寻道、读写指定扇区的时间， 大家应该很清楚I/O时间几乎是固定不变，这里无需多说，数据库服务器一般都是高速SCSI接口，读写速度是普通IDE接口（10ms以下）的n倍以上，再看select的开销，容易理解的是：随着贴子数的迅速增加，哪怕最顶尖的服务器，从几十万、几百万的贴子中进行一次select至少在10~100ms级，各位可以亲自检测一下自己的服务器响应时间，由此得出结论是
      select的开销>;>;I/O开销。
      即update开销远小于select开销（条件是先进行select），这个结论应该可以说明楼主所述的问题，关于这个问题希望到此为止，再进行下去无非是口水战。也希望借这个机会能交一些朋友，共同进步。