Question

我实现了一种算法，根据他的喜欢和不喜欢，返回热门帖子。

要做到这一点，对于每个帖子，我添加他所有的喜欢（1）和不喜欢（-1）来获得他的分数但每个喜欢/不喜欢加权：最新的，最重的。例如，在用户喜欢帖子时，他喜欢权重1.在1天后，它的权重为0.95（如果不喜欢则为-0.95），2天后为0.90，依此类推...... 21天后达到最低0.01。（PS：论文完全是近似值）

以下是我的表格制作方法：

帖子表

id | Title                 | user_id | ...
-------------------------------------------
1  | Random post           | 10      | ...
2  | Another post          | 36      | ...
n  | ...                   | n       | ...

喜欢表格

id | vote | post_id | user_id | created
----------------------------------------
1  | 1    | 2       | 10      | 2014-08-18 15:34:20
2  | -1   | 1       | 24      | 2014-08-15 18:54:12
3  | 1    | 2       | 54      | 2014-08-17 21:12:48

以下是我目前正在使用执行该作业

的SQL查询

SELECT Post.*, Like.*, 
SUM(Like.vote * 
    (1 - IF((TIMESTAMPDIFF(MINUTE, Like.created, NOW()) / 60 / 24) / 21 > 0.99, 0.99, (TIMESTAMPDIFF(MINUTE, Like.created, NOW()) / 60 / 24) / 21))
   ) AS score 
FROM posts Post 
LEFT JOIN likes Like ON (Post.id = Like.post_id) 
GROUP BY Post.id
ORDER BY score DESC

PS：我直接使用TIMESTAMPDIFF与MINUTE而不是DAY，因为我自己计算了这一天，否则它会给我一个整合者，我想要一个浮动值，以逐渐减少加班而不是每天一天。所以TIMESTAMPDIFF(MINUTE, Like.created, NOW())/60/24只给出了自创建之后用小数部分传递的天数。

以下是我的问题：

查看IF(expr1, expr2, expr3)部分：为了设置类似体重的最小值是必要的，所以它不会低于0.01而变为负数（等等，甚至更老）有一点重量）。但我计算的次数相同2次：expr1与expr2相同。难道没有办法避免这种重复表达吗？
我打算缓存此查询并每5分钟更新一次，因为我认为在Post和Like大表上它会非常繁重。缓存真的有必要吗？我的目标是在一个包含50 000个条目的表格上运行此查询，并为每200个相关的喜欢（生成10 000 000个条目Like表格）运行此查询。
我应该在Like表中为post_id创建索引吗？并为创建？

谢谢！

编辑：想象一下Post可以有多个标签，每个标签可以属于多个帖子。如果我想获得带有标签或多个标签的popces帖子，我无法缓存每个查询;因为存在大量可能的查询。查询仍然可行吗？

编辑最终解决方案：我终于做了一些测试。我创建了一个包含30 000个条目的表格，并且有25万个条目。没有索引，查询的时间非常长（超时时间> 10mn），但是Post.id（主要），Like.id（主要）和Like.post_id上的索引需要大约0.5秒。

所以我没有缓存数据，也没有每5毫秒使用一次更新。如果表继续增长，这仍然是可能的解决方案（超过1秒，这是不可接受的）。

Answer 1

2：我打算缓存这个查询并每隔5分钟更新一次，因为我认为它会在一个大的Post和Like表上相当沉重。缓存真的有必要吗？我的目标是在一个包含50 000个条目的表上运行此查询，并为每200个相关的喜欢（这使得10 000 000条目像表格）。

当前硬件上认为10000和50000很小。使用这些表大小，您可能不会需要任何缓存，除非查询将每秒运行几次。无论如何，我会在决定使用缓存之前进行性能测试。

3：我应该在Like表中为post_id创建索引吗？为了创造？

我会为（post_id，created，vote）创建一个索引。这样查询就可以从索引中获取所有信息，并且根本不需要读取该表。

修改（对评论的回复）：

额外的索引会略微降低插入/更新速度。最后，您选择的路径将决定CPU / RAM /磁盘I / O所需的特性。如果您有足够的数据库RAM，以便您希望将整个Like表缓存在RAM中，那么您可能最好只使用post_id上的索引。

就总负载而言，您需要考虑insert和select之间的比率以及使用或不使用索引进行插入和选择的相对成本。我的直觉是指数的总负荷会降低。

关于并发问题（同时选择和插入）。发生什么取决于隔离级别。一般建议是尽可能缩短插入/更新。如果您在insert和commit之间没有做任何必要的事情，那么您应该没事。

具有加权分数的Sql流行度算法

1 个答案: