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

时间:2018-10-16 20:02:24

标签: mysql database design-patterns database-design database-normalization

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

它精美而精确地解释了。但是每个喜欢或评论都必须换一个新行。 Instagram的“赞”按钮平均每天被点击约45亿次。这对于likes表来说太大了。 4.5bx30天=每月135万亿!我不相信他们会那样设计。

  • 我们要想到的主要问题:我们如何设计大型公司使用的最合适的设计结构? (Twitter,Instagram等)(最少的查询执行,最优化的等等)

这就是我们的实际想法:

  • 如果有人对帖子发表评论,则JSON将在评论栏中更新。这种方法是否比为每个评论或喜欢添加新行更有效?

database_struct

  • 我们找到了这个类图:https://stackoverflow.com/a/1120491/5685796 该设计于2009年共享。如果我们正在做大型项目,将来实现此架构是否会给我们带来优化问题? (假设每个份额都带有100万个赞和100万条评论。:))

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

1 个答案:

答案 0 :(得分:1)

为注释使用单独的表格。它会显示您指定的5列。

将内容放入JSON会使它们难以访问,搜索,过滤等。对于任何类型的数组,它也是同上。两者都做-将JSON对象数组放在单个单元格中。

了解有关JOIN的信息,以重新连接我要告诉您的分开的内容。

要进入数万亿美元,您还需要“分片”。但是,只有在您进入数以百万计的人群之后,我们才开始讨论它。

(更多建议)

“大公司”的数据集在数百台服务器上“分片”。 Comments很可能在常规表中。不太可能使用JSON;尤其是不要搜索或排序。 JSON非常适合需要保存但无需搜索/排序的其他杂项。

这对您来说真的是最好的

  1. 设计并实现某物(即使它包含JSON);
  2. 投入生产;
  3. 研究出现的问题;
  4. 在几个月的重新设计中-愿意丢弃大部分原始设计。
  5. “冲洗并重复”。经过十年的努力,有很多障碍需要跨越很多障碍。

我一次只能帮您做一次迭代。

喜欢...如果要保留计数器,则在“并行”表中进行操作。这将降低主表上的争用。如果要列出谁喜欢什么的列表,那么这就是一张表格。

ID ...请勿在具有完美PK的表上使用AUTO_INCREMENT。主要示例是许多:许多表-使用两个ID的组合。

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

不要使用EAV(实体-属性-值)架构设计。它的缩放效果不好。

子类化通常变得笨拙。在该链接中,他们具有“照片/文章/位置”为“实体”。否。Photos应该是自己的表,并带有自己的列,怪癖,索引等。

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