实现 Instagram 或 Twitter 等评论和点赞系统的最佳方法

Question

我们正在为课程项目设计一个数据库（MySQL）。这正是我们所陷入的困境：评论和点赞系统。 所以我们发现了这个问题：在数据库中实现评论和点赞

它的解释非常漂亮和精确。但每一个点赞或评论都必须是一个新行。 Instagram 的“点赞”按钮平均每天被点击约 45 亿次。这对于

likes

桌子来说太大了。 4.5bx30 天=每月 135 万亿！我不相信他们会那样做设计。

• 我们想到的主要问题：如何设计出最适合大公司使用的设计结构？ （Twitter、Instagram 等）（最少查询执行、最优化等）

这就是我们实际的想法：

• 如果有人对帖子发表评论，JSON 将在评论栏中更新。这种方法比为每个评论或点赞添加新行更有效吗？

• 我们找到了这个类图：https://stackoverflow.com/a/1120491/5685796 这个设计是在 2009 年分享的。如果我们正在做大型项目，实现这个模式是否会给我们将来带来优化问题？ （假设每个分享有 100 万个点赞和 100 万条评论。:)）

编辑：我们正在设计为关系数据库。

Answer 1

使用单独的表格进行评论。 它将包含您指定的 5 列。

将内容放入 JSON 会使它们难以访问、搜索、过滤等。对于任何类型的数组也是如此。 您正在同时执行这两项操作——将 JSON 对象数组放入单个单元格中。

了解

JOIN

重新连接我告诉你要分开的东西。

要达到数万亿，您还需要“分片”。 但是，在您拥有数百万美元之前，我们不要讨论这个问题。

（更多建议）

“大公司”拥有一个分布在数百台服务器上的数据集。

Comments

很可能出现在常规表中。 JSON不太可能被使用；特别是不适合搜索或排序的任何内容。 JSON 非常适合需要保存但不需要搜索/排序的杂项。

这对你来说真的是最好的

1. 设计并实现某些东西（即使它包含 JSON）；
2. 投入生产；
3. 研究出现的问题；
4. 在几个月内重新设计 - 愿意丢弃大部分原始设计。
5. “冲洗并重复”。经过十年和数十名工程师的努力，大公司要达到的目标有太多的障碍需要跨越。

我一次只能帮助您进行一次迭代。

喜欢...如果您要保留计数器，请在“并行”表中进行。 这将减少主表上的争用。 如果您要保留一个谁喜欢什么的列表，那么它本身就是一张表格。

ID...不要在具有完美 PK 的桌子上使用

AUTO_INCREMENT

。 主要示例是任意多：多表——使用两个 id 的组合。

正常化，但不要过度正常化。 您将在上面的“第 3 步”中开始理解这一点。

不要使用EAV（实体-属性-值）模式设计。 它不能很好地扩展。

子类化通常会变得很笨拙。 在该链接中，他们的照片/文章/地点“是一个”实体。 不。

Photos

 应该是它自己的表，有自己的列、怪癖、索引等。

不要

使用任何第三方软件。 好的，您可以将它用于我上面步骤的第 first 迭代。 但在第 4 步中，将其完全丢弃。 到那时，你就被迫学习MySQL的细节了（因为该软件无法完全阻止你学习细节）。

Answer 2

count

查询即可获得良好的性能。