我希望建立一个可扩展的实时聊天应用程序（我只是做这个的乐趣和出于兴趣，所以请不要问为什么！），我知道我将通过redis处理实时消息部分，但我不确定使用什么数据库来存储以下信息：
- 用户关系（朋友）
- 冷聊天历史-这将只在有限的数量查询（也许像50消息）按时间戳排序和反向查询（就像你的消息将加载在imessage或whatsapp滚动查看旧消息时）
- 聊天用户关系
我知道对于冷聊天历史，RDBMS或Cassandra可能是我最好的选择，但在RDBMS或Cassandra中处理朋友关系以及用户聊天关系是丑陋的。我不确定在我的技术堆栈中仅仅为了这个关系Map而拥有一个图形数据库是否必要、值得，甚至是“正确”的。
我认为MongoDB或其他基于文档的存储可能是一个解决方案，但查询数据似乎真的很费力。我的想法是有一个聊天文档，有一个列表的用户，然后我会有几个其他的文件与一个列表的消息id的指向消息文档。这些文档将被Map回chatID。我相信您可以看到，查询一组消息所需的时间和资源将非常多。也许我只是低估了MongoDB的力量，因为我还没有真正使用过它。我也可以更容易地处理聊天用户关系使用的文件以及友谊，只是存储用户ID在一个列表中的文件。
我知道没有完美的工具的工作，但我想有人的想法和投入如何设计的数据存储。
感谢您的评分
3条答案
按热度按时间olmpazwi1#
最好在关系数据库中保持关系。我在我的聊天应用程序中使用PostgreSQL来实现这些目的。
对于聊天记录和其他事件，Cassandra是一个不错的选择（我也使用Cassandra）。但是，这取决于您的数据库大小（记录数量）。如果你不需要为成千上万的用户保留成千上万的历史消息，那么使用Cassandra将是一种矫枉过正的做法。在这种情况下，您也可以使用PostgreSQL或其他关系数据库。在PostgreSQL中，可以使用分区来优化对历史表的访问。
yuvru6vn2#
如果交易量不高，那么你可以选择PostgreSQL，否则Cassandra是满足你所有要求的好选择。在Cassandra中，您应该将多个表去规范化，以实现低延迟和高可用性。
1.用户-创建包含任何用户的所有信息的主表。
1.冷聊天历史-由于Cassandra具有高度可扩展性...不需要这张table。
数据建模是一个需要大量讨论的领域，无论如何，我试图尽可能简单地回答这个问题。
bvpmtnay3#
这可能已经太晚了，但可以帮助其他人：我仍然认为，使用像PostgreSQL这样的RDB进行有效的数据建模要好得多。postgres处理和解析半结构化数据（如JSON）的能力令人印象深刻。所以，对于所有的需求，除非你处理的是Antek提到的大量聊天记录。
This在这方面是一个非常有用的帖子。