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

Posted 2023-02-23

【中文标题】实时可扩展聊天应用程序 - 我应该选择哪个数据库？

【英文标题】：Realtime Scalable Chat App - which database should I choose?

【发布时间】：2021-06-30 21:42:24

【问题描述】：

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

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

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

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

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

提前谢谢你！

【参考方案1】：

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

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

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

【参考方案2】：

最好在真实数据库中保持关系。 我在聊天应用程序中将 PostgreSQL 用于此类目的。

对于聊天记录和其他事件，Cassandra 是一个不错的选择（我也使用 Cassandra）。但是，这取决于您的数据库大小（记录数量）。如果您不需要为成千上万的用户保留数以万计的历史消息，那么使用 Cassandra 将是矫枉过正。在这种情况下，您还可以使用 PostgreSQL 或其他关系数据库。 在 PostgreSQL 中，您可以使用分区优化对历史表的​​访问。