2

鉴于他的好恶，我正在实施一种算法，该算法目前返回热门帖子。

为此，对于每个帖子，我添加他所有的喜欢 (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：我使用TIMESTAMPDIFFwithMINUTE而不是DAY直接使用，因为我自己计算一天，否则它返回我一个整数，我想要一个浮点值，以便逐渐衰减加班而不是每天。所以TIMESTAMPDIFF(MINUTE, Like.created, NOW())/60/24只要给我小数部分自类似创建以来经过的天数。

这是我的问题：

  1. 看IF(expr1, expr2, expr3)部分：有必要为同类的权重设置最小值，因此它不会低于 0.01 并变为负数（等等，即使是更老的还有一点权重）。但我计算的是同一件事的 2 倍：expr1 与 expr2 相同。有没有办法避免这种重复的表达？
  2. 我打算缓存这个查询并每 5 分钟更新一次，因为我认为它在一张大桌子上会Post很重Like。缓存真的有必要吗？我的目标是在一个有 50 000 个条目的表上运行这个查询，并且对于每 200 个相关的喜欢（这会产生一个 10 000 000 个条目的Like表）。
  3. 我应该在Like表中为 post_id 创建索引吗？并为创建？

谢谢 ！

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

编辑最终解决方案：我终于做了一些测试。我创建了一个包含 30 000 个条目的表 Post 和一个包含 250 000 个条目的 Like。如果没有索引，查询会非常长（超时 > 1000 万），但在 Post.id (primary)、Like.id(primary) 和 Like.post_id 上使用索引需要大约 0.5 秒。

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

4

1 回答 1

1

2：我打算缓存这个查询并每 5 分钟更新一次，因为我认为它在一个大的 Post 和 Like 表上会很重。缓存真的有必要吗？我的目标是在具有 50 000 个条目的表上运行此查询，并且对于每 200 个关联的喜欢（这会产生一个 10 000 000 个条目的 Like 表）。

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

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

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

编辑（回复评论）：

额外的索引会稍微减慢插入/更新速度。最后，您选择的路径将决定您在 CPU/RAM/磁盘 I/O 方面所需的特性。如果您有足够的 RAM 用于 DB，以便您希望整个Like表缓存在 RAM 中，那么您最好只在post_id.

在总负载方面，您需要考虑插入和选择有或没有索引的相对成本之间的insert比率select。我的直觉是总负载会随着索引而降低。

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

于 2014-08-19T10:04:34.403 回答