图表数据库是邮件系统的一个很好的用例吗？

Question

我正在图表数据库的世界中潜水，我只是惊讶于它有多强大。我选择OrientDB开始我的第一个用例，但我不确定我的域名是否适用于我的应用程序的这个特定部分。

用户 跟随其他用户。

用户可以成为 对话的一部分。

消息可以发送（带时间戳）到会话。

消息可由用户 读取（带时间戳）。

我担心最终会有数百万（甚至数十亿）消息节点和发送或读取边缘，从而影响系统的整体性能。消息传递部分不是应用程序的主要概念，它只是 small 的一部分。

OrientDB处理会有问题吗？它是图形数据库的一个很好的应用程序吗？

感谢大家的耐心等待， 维尼

Answer 1

不要认为图形数据库是邮件系统的最佳候选者。消息系统本质上是关系型的，适合我的MySQL。

尽管Facebook使用面向文档的数据库作为其邮件系统，但您并不会感到惊讶。

Facebook目前是Cassandra的最大安装，它具有出色的可扩展性。我们已经从Facebook了解到这一点。此外，由于其分布式特性，它非常适合存储消息。

Answer 2

看一下使用OrientDB和类似用例的建议方法：

http://orientdb.com/docs/last/Chat-use-case.html

Answer 3

图形数据库的选择最终取决于您要对数据执行的操作。 在您的情况下，您是否计划使用任何图形处理算法或图形遍历？

图论中的边表示节点（对象）之间的关系。对于读取和发送的时间戳，它实际上并不合适，最终会产生数十亿个边缘，从而导致系统性能下降。

跟随者概念非常适合数据库。现在关于对话，它可以是节点的属性。您是否需要创建边缘来表示所有权仅查询对话ID？

如果消息只是应用程序的一小部分，我建议使用最适合您需求的工具，并组合一个面向列的数据库（Cassandra）并使用Orient-DB表示关系或使用Orient-DB，如Chat use case（Thanks @Lvca）

  

我们建议避免使用与之相关的边缘或顶点   消息的边缘。最好的方法是通过创建使用文档API   每个聊天室一个班级，没有索引，可以超级快速访问   最后X条消息。

Answer 4

还想知道这个话题，但我认为任何RDBMS都会更好地完成这项任务。

此外，聊天有点像日志。所以ElasticSearch（和类似的）可以完美匹配存储Terra字节的聊天数据。

Answer 5

这里有很多不合理的答案。从经验上来讲，我已经在 MongoDB 实例上构建了一些消息传递系统，没有任何问题可以处理成百上千的并发用户（带有聊天组） 。

如果您非常担心可伸缩性（因为它实际上是内置的），或者说MongoDB一直在不断升级，那么您可以选择Cassandra，因为它是经过考验的数据库然后可以相对容易地通过 ElasticSearch 进行搜索。 MongoDB支持通过 sharding 进行扩展，因此可以根据您的需求进行水平扩展。 只需确保不限制后端服务的速度，并实施尽可能多的异步操作即可。

现在，您甚至可以进一步实现像Kafka这样的流媒体平台，该平台非常适合CDC（更改数据捕获），并将持久保存消息日志，直到服务读取该消息为止。实际上会将消息写入您选择的数据库，从而增加了弹性系数。