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