Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/mysql/72.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Php 如何设计一个高效的Like系统?_Php_Mysql_Optimization_Database Design_System Design - Fatal编程技术网

Php 如何设计一个高效的Like系统?

Php 如何设计一个高效的Like系统?,php,mysql,optimization,database-design,system-design,Php,Mysql,Optimization,Database Design,System Design,我正在尝试为网站的现有评论部分创建一个类似于Facebook的类似/不同系统,我需要帮助设计该系统 目前,网站上的每种产品都有一个评论部分,会员可以发表评论或喜欢评论。我需要知道每个成员发表了多少评论,他的每个评论收到了多少喜欢。当然,出于分析目的,我需要知道谁也喜欢什么评论(部分是为了防止用户多次喜欢某个评论) 实现与当前comments模块类似的系统的简单方法是在数据库中创建一个新表,该表具有CommentID和UserID的外键。然后,对于用户给注释的每一个“like”,我都会在这个新表中

我正在尝试为网站的现有评论部分创建一个类似于Facebook的类似/不同系统,我需要帮助设计该系统

目前,网站上的每种产品都有一个评论部分,会员可以发表评论或喜欢评论。我需要知道每个成员发表了多少评论,他的每个评论收到了多少喜欢。当然,出于分析目的,我需要知道谁也喜欢什么评论(部分是为了防止用户多次喜欢某个评论)

实现与当前comments模块类似的系统的简单方法是在数据库中创建一个新表,该表具有CommentID和UserID的外键。然后,对于用户给注释的每一个“like”,我都会在这个新表中插入一行,其中包含目标注释ID和用户ID

虽然这可能会起作用,但大量的注释和用户将导致此表快速增长,从这个巨大的表中检索记录和进行计数将变得缓慢而低效。我可以为其中任何一列编制索引,但我不知道它的效果如何。该网站有超过一百万条评论


我正在使用PHP和MySQL。对于这样一个拥有巨大数据库的系统,我应该如何设计一个类似的系统,使其更加优化和稳定

您主要关心的是大量的计数,因此简单的做法是在您的评论表中保留一个单独的计数

然后,您可以创建一个
触发器
,该触发器根据相似/不同的值递增/递减计数

这样,您只需使用大表来确定用户是否已经投票。

为了可伸缩性,不要在同一个表中包含count列和其他内容。这是一种罕见的情况,“垂直分区”是有益的。为什么?喜欢/不喜欢的人会来的很快,很愤怒。如果执行递增/递减的代码命中用于其他事情(如注释文本)的表,则两者之间的争用量将是不可接受的


这条提示是向能够扩展到Facebook级别的许多步骤中的第一步。其他的建议不是来自一个免费的论坛,而是来自你必须雇佣的聪明工程师团队。(提示:切分、缓冲、显示估计值等)

您可能希望将类似系统设计为非实时系统。以“正确”的方式设计表格,但不要实时读取表格以获得即时计数。每隔几分钟、几小时更新一次计数。@AgRizzo“正确”的设计方式是什么样的?你的“幼稚”方式-即标准化。你需要知道哪个用户喜欢哪个评论,所以两列(至少):user_id和comment_id。我认为这太宽泛了,基于观点,不适合这样做。这里发布的答案已经产生了更多的讨论,而不是单个问答对。正如OP所指出的,这可以通过多种方式实现,探索所有的选择都是困难的。@HPierce我不太理解你的反对票。实现这一点肯定有多种方法。大多数事情可以用不同的方式完成。但你自己实现这一目标的最佳方式可以是这个问题的答案之一。用不同的方法来实现这一点的答案也可以为未来的读者提供很好的参考。因此,我还将有另外两个表,一个用于存储评论的赞数,另一个用于存储用户发布的评论数?我以前也想过类似的事情,但也在考虑,考虑到该网站有大约100多万条评论和几十万用户,该表可能会增长到数千万行以上!所以每次当我需要知道谁喜欢一条评论时,我仍然需要浏览这个庞大的表?另一件事是,假设我需要检查一个用户在发布他的喜欢评论之前是否已经喜欢了一条评论(为了防止他喜欢一条评论不止一次),我仍然需要运行这个巨大的表,不是吗?不,你不需要新的表格,你可以让它们成为你评论表格的一部分。为了防止用户评论/喜欢两次。。。你不需要“浏览”表格。假设您的意思是用“run-through”扫描整个表。有了一个好的索引,这应该是相当快的。对于这样一个简单的数据集来说,数千万是微不足道的。