Mysql 聊天系统的数据库设计

我知道有很多帖子都在讨论聊天系统的Db设计，但是他们没有解释该设计的可伸缩性，所以这里是我的问题

我想设计一个两个或更多用户之间实时聊天的数据库，让我们先考虑两个用户，这里是我的想法

表1:

姓名：用户

字段：id，name

表2

姓名：聊天室

字段：id、user1、user2

表3：

姓名：信息

字段：聊天室id、用户id、消息

现在考虑到Facebook，它每月大约有20亿活跃用户，其中10亿人沉迷于聊天，每个用户发送100条消息

表中有1000亿个条目：消息，所以问题是

“Mysql或Postgres能够处理这么多条目并实时显示特定的聊天室消息吗？”如果不能，那么接下来的最佳实践应该是什么，我知道这也取决于安装RDBMS的服务器，但仍然想知道最佳的体系结构

---

PS：我使用Django作为后端，AngularJs用于异步行为

一个表中的1000亿行永远不会在线工作。不仅应用了所有可能的分区方法来减小大小，而且还分离了主动/被动数据策略。但尽管如此，所有的高质量问题，答案是：

Postgres确实能够有效地处理大数据本身。

然而：

博士后没有足够有效的策略来对抗糟糕的设计

看看您的示例：table chat_room在单独的列中列出了两个用户-为什么？您在引用users.id的消息中有user\u id。其中包含chat_room.id，因此您可以获得该聊天室中的用户数据。现在，如果您的想法是预先聚合一段时间内或根本没有参与聊天室的用户，请将其设置为一个数组列，如

（chat\u room.id int，users\u id bigint[]）

，或者如果您想要加入时间和离开时间，请添加相应的属性。主动/被动数据可以使用与主动聊天室不同关系的存档聊天室来实现。顺便说一句，关于谁参加了聊天室的聚合可以在这样的存档上执行

---

以上不是行动说明，只是表达。数据库模式没有最佳实践。首先制定一个清晰的聊天计划，然后创建db模式，尝试、改进、尝试、改进、尝试、改进等等，直到一切正常为止。如果您担心它将如何处理1000亿行，请将其填满并检查…

似乎是糟糕的设计。通常，每当您枚举列时，都可以确定设计有缺陷。这种情况当然不例外。是的，你是对的，这是一个糟糕的设计，这是我的问题，在这种情况下，一个好的设计应该是什么样子？除此之外，设想的规模是完全不成比例的。Facebook采用多种架构来管理其数据集。当你的竞争对手技术超越Facebook时，我相信你要么足够富有，可以聘请专业人士为你研究这些问题，要么太富有而不在乎。完全同意你的观点，我不是在竞争Facebook，我是一名学生，所以我想知道我应该使用什么样的技术和工具来完成这项任务，让我们不要假设1000亿太多，但让我们假设1000万一个标准化设计可能有一个聊天室参与者表，其中有一个聊天室列，一个参与者列，每个列中输入一个值，并在这两个列的组合上形成一个主键。