mysql - 实现评论和喜欢系统（如 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 万条评论。:)）

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

标签： mysqldatabasedesign-patternsdatabase-designdatabase-normalization

Answer 1

对评论使用单独的表格。它将具有您指定的 5 列。

将内容放在 JSON 中会使它们难以获取、搜索、过滤等。对于任何类型的数组也是如此。你正在做这两个 - 将一组 JSON 对象放在一个单元格中。

了解如何JOIN重新连接我告诉你分开的东西。

要进入数万亿美元，您还需要“分片”。但是，在您获得数百万美元之前，我们不要讨论这个问题。

（更多建议）

“大公司”有一个跨数百台服务器“分片”的数据集。 Comments很有可能出现在普通餐桌上。不太可能使用 JSON；特别是不要搜索或排序任何东西。JSON 适用于需要保存但不需要搜索/排序的杂项 kruft。

对你来说真的是最好的

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

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

喜欢...如果你有一个柜台，那就在一个“平行”的桌子上做吧。这将降低主表上的争用。如果您要列出谁喜欢什么，那么这本身就是一张桌子。

IDs...不要AUTO_INCREMENT在PK非常好的桌子上使用。主要的例子是任何 many:many 表——使用两个 id 的组合。

规范化，但不要过度规范化。这是您将在我上面的“第 3 步”中开始理解的内容。

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

子类化经常变得笨拙。在那个链接中，他们有照片/文章/地点“是一个”实体。不 Photos应该是它自己的表，有自己的列、怪癖、索引等。

不要使用任何第三方软件。好的，您可以将它用于我上述步骤的第一次迭代。但在第 4 步中，将其完全扔掉。到那时，您已经被迫了解 MySQL 的详细信息（因为该软件无法完全让您无需了解详细信息）。