实时可扩展聊天应用程序 - 我应该选择哪个数据库？

Question

我正在寻找构建一个可扩展的实时聊天应用程序（我这样做只是为了好玩和出于兴趣，所以请不要问为什么！）并且我知道我将通过 redis 处理实时消息传递部分，但是我不确定使用哪个数据库来存储以下信息：

• 用户关系（朋友）
• 冷聊天历史记录 - 只会以有限的数量（可能是 50 条消息）进行查询，按时间戳排序并反向查询（就像滚动查看旧消息时您的消息会加载到 imessage 或 Whatsapp 中一样）
• 聊天用户关系

我知道对于冷聊天历史记录，RDBMS 或 Cassandra 可能是我最好的选择，但在 RDBMS 或 cassandra 中处理朋友关系以及用户聊天关系是很丑陋的。我不确定在我的技术堆栈中仅用于此关系映射是否有必要、值得甚至“正确”地拥有一个图形数据库。

我认为 MongoDB 或其他一些基于文档的存储可能是一个解决方案，但查询数据似乎真的很费力。我的想法是创建一个包含用户列表的聊天文档，然后再创建几个其他文档，其中包含指向消息文档的消息 ID 列表。这些文档将被映射回chatID。我相信您可以看到，查询一组消息的时间和资源会相当高。也许我只是低估了 MongoDB 的力量，因为我还没有真正使用过它。通过将用户 ID 存储在文档内的列表中，我还可以更轻松地使用文档和友谊来处理聊天用户关系。

我知道没有完美的工具可以完成这项工作，但我想听听有人对如何设计数据存储的想法和意见。

先感谢您！

Answer 1

如果交易量不高，那么您可以使用 Postgresql，否则 Cassandra 是满足您提到的所有要求的不错选择。在 Cassandra 中，您应该有多个非规范化的表，以实现低延迟和高可用性。

1. 用户 - 创建一个包含任何用户的所有信息的主表。
2. User_Friend_relation - 创建另一个表，其复合主键为 userid 和 freindid，集群键为 is_active(0,1) desc。((userid,freindid),is_active)
3. Chat_user_friend - 这是您的主表，包含所有聊天内容。创建此表，使用时间戳作为集群键，并按降序存储数据，这样您可以通过实时排序来节省时间，并且首先获得最新的数据。
4. 冷聊历史记录 - 由于 Cassandra 具有高度可扩展性...不需要这张表。

数据建模是一个需要进行大量讨论的领域，无论如何，我试图尽可能简单地回答这个问题。