我在图形数据库的世界中潜水，我只是惊讶于它的强大程度。我选择OrientDB来开始我的第一个用例，但我不确定我的域是否适用于我的应用程序的这个特定部分。
用户跟随另一个用户。
用户可以成为对话的一部分。
可以将消息（带有时间戳）发送到对话。
用户可以读取消息（带有时间戳）。
我担心最终会有数百万（甚至数十亿）的Message节点以及发送或读取边缘，从而影响系统的整体性能。消息传递部分不是应用程序的主要概念，它只是它的一小部分。
对于OrientDB来说，这是一个问题吗？它是图形数据库的一个很好的应用程序吗？
感谢大家的耐心，Vinicius
不要认为图形数据库是消息传递系统的最佳候选者。消息系统本质上是关系型的，适合我的MySQL。
尽管Facebook使用面向文档的数据库用于其消息传递系统，但您不会感到惊讶。
Facebook目前是Cassandra最大的安装，它具有出色的可扩展性。我们已经从Facebook了解到这一点。此外，由于其分布式特性，它非常适合存储消息。
看一下使用OrientDB和类似用例的建议方法：
图形数据库的选择最终取决于您要对数据做什么。在您的情况下，您是否计划使用任何图形处理算法或图形遍历？
图论中的边表示节点（对象）之间的关系。在读取和发送时间戳的情况下，它并不真正适合，最终会产生数十亿个边缘，从而导致系统性能下降。
跟随者概念非常适合数据库。现在关于对话，它可以是节点的属性。您是否需要创建边缘来表示所有权以查询对话ID？
如果消息传递只是应用程序的一小部分，我建议使用最适合您需求的工具，并结合使用面向列的数据库（Cassandra）并使用Orient-DB来表示关系或使用Orient-DB，如同Chat use case（谢谢@Lvca）
我们建议避免使用与边连接的边或顶点作为消息。最好的方法是使用文档API，通过为每个聊天室创建一个没有索引的类来快速访问最后的X消息。
也想知道这个话题，但我认为任何RDBMS将更好地完成这项任务。
此外，聊天是一种日志。所以ElasticSearch（和类似的）可以完美匹配存储Terra字节的聊天数据。
这里有很多不和谐的答案。根据经验，我在普通的MongoDB实例上构建了一些消息系统，没有任何问题处理数百/数千个并发用户（使用聊天组）。
如果你非常担心可扩展性（因为它实际上是内置的），或者像MongoDB这样的新手一直在不断升级并且你可以相对容易地进行升级，我会说要使用Cassandra，因为它是经过实战考验的数据库然后包括通过ElasticSearch进行搜索。 MongoDB支持通过分片进行缩放，因此可以根据您的需要进行水平扩展。确保不要在后端服务上遇到瓶颈，尽可能多地执行异步操作。
现在，您甚至可以实现像Kafka这样的流媒体平台，它非常适合CDC（更改数据捕获），并将持久保存您的消息日志，直到实际将消息写入您选择的数据库的服务读取它为止你的弹性系数。