我将使用neo4j实现聊天应用程序。我将每个消息存储为图表中的节点，但这可能会导致数十亿个节点。是okey吗？
图形数据库是在数据之间存储连接。它适合其设计的情况。您提到的聊天应用程序对于图形数据库不是适当的用例。也许您可以使用Graph Database来存储用户的友谊，这对于图形数据库确实很有益。但是消息是某种日志样式数据。这不是数据之间的关系。对于聊天消息，日期信息比关系重要。因此，我认为您可以使用另一个DBM来存储聊天消息而不是图数据库。
另一个选项是使用支持多个数据模型的混合数据库。这些DBMSES之一是AgensGraph（https://github.com/bitnine-oss/agens-graph）。它提供图形数据库功能，包括基于Cypher支持的关系数据库PostgreSQL。因此，您可以将用户的关系存储在图对象和用户的聊天消息中。因此，使用AgensGraph，您可以根据数据的属性来优化存储空间。
假设您要将每个消息建模为自己的节点，鉴于您的朦胧要求，我可以想到两种可能的可能性的可能性。
一个是，对于一个聊天室节点，将所有消息附加到聊天室节点，并在发布日期中获取所有消息的疑问，请在聊天室中订购所有消息。
。请记住，即使您在发布的日期上添加索引：消息节点，当前通过操作执行订单时目前未使用索引，因此，随着消息的数量的增长，查询速度的降低也会下降每个聊天室。
另一个选项是链接的列表结构，将消息订购到列表中。在附加到消息列表之前哪个可以分配列表。
而不是将文本消息保存为图中的节点，最好使用RDBMS系统。它们针对这种事情进行了优化，如果数据集并非不切实际（查看Hadoop，Couch或类似的东西），请做得很好。
如果您坚持使用图形，请尝试使用AgensGraph等混合数据库，该数据库集成了RDBMS数据库。您可以在图形数据库上使用Cypher，在关系数据库上使用SQL。