我知道有很多关于聊天系统讨论Db设计的帖子，但是他们没有解释任何有关该设计的可扩展性的内容，所以这里是我的问题。
我想在2个或更多用户之间设计一个实时聊天的Db，让我们先拿2个用户，这是我想出来的。
表1：
名称：用户
字段：id，name
表2
姓名：聊天室
字段：id，user1，user2
表3 ：
名称：消息
字段：Chat_room_id，user_id，消息
现在考虑到Facebook，它每月有大约20亿活跃用户，让他们说10亿人沉迷于聊天，每个用户发送100条消息。
表中有100亿个条目：消息，所以问题是，
“Mysql或Postgres能够处理这么多条目并实时显示特定的聊天室消息吗？”如果不是那么应该遵循的最佳实践，我知道它还取决于安装RDBMS的服务器，但仍然想知道最佳架构。
PS：我使用Django作为后端，AngularJs用于异步行为
答案 0 :(得分：1)
一个表中的100亿行永远不会在线工作。不仅应用所有可能的分区方式来减小大小，而且还应用主动/被动数据策略的分离。但无论如何，所有高级人物，答案都是：
Postgres确实可以有效处理大数据。
然而：
Postgres没有足够的策略来对抗糟糕的设计
看看你的例子：table chat_room 在不同的列中列出两个用户 - 为什么？在引用users.id的消息中有user_id。而且你有chat_room.id，所以你有用户在chat_room中的数据。现在，如果您的想法是预先汇总哪些用户随时间参与chat_room，请将其设置为一个数组列，例如(chat_room.id int, users_id bigint[])，或者如果您想要加入时间和离开时间，请添加相应的属性。主动/被动数据可以使用不同关系的存档聊天室实现，然后是活动的。对参与该聊天室的人进行顺便汇总可以在这种归档中进行...
以上不是行动指示，只是表达。数据库架构没有最佳实践。首先明确计划你的聊天将做什么，然后制作数据库模式，尝试，改进，尝试，改进，尝试，改进等，直到一切正常。如果您对100亿行的工作方式有疑虑 - 请填写并检查......