实施评论和点赞系统（如Instagram或Twitter）的最佳方法

Question

我们正在为课程项目设计一个数据库（MySQL）。这正是我们所坚持的：评论和喜欢系统。 因此，我们发现了以下问题：Implementing Comments and Likes in database

它精美而精确地解释了。但是每个喜欢或评论都必须换一个新行。 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应该是自己的表，并带有自己的列，怪癖，索引等。

不要不要使用任何第三方软件。好的，您可以将其用于上述步骤的第一迭代中。但是在第4步中，将其完全丢弃。到那时，您已经被迫学习MySQL的详细信息（因为该软件将无法完全阻止您学习这些详细信息）。