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

Question

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

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

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

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

我知道这项工作没有完美的工具，但我希望有人就如何设计数据存储提出想法和意见。

先感谢您！

标签： databasemongodbdatabase-designchat

Answer 1

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

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

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