我正在进行一个项目，该项目涉及许多客户端连接到一个服务器（如果需要，则为服务器），该服务器包含一组图形信息（节点属性和边）。他们可以随时选择引入新的节点或边，然后从整个图中请求一些信息（两个节点之间的最短距离、图着色等）。
这显然很容易开发天真的算法，但我正在努力学习缩放它，以便它可以处理许多用户同时更新图，许多用户从图中请求信息，以及处理非常大（500k+）节点和可能大量边的可能性。
我可以预见的挑战：
- 有了一个不断更新的图形，每次有人请求信息时，我都需要处理整个图形。。。这将大大增加计算时间和延迟
- 对于一个非常大的图，计算时间和延迟显然会高得多（我读到一些公司通过批量处理大量结果并将其存储在索引中以备日后使用来弥补这一问题……但由于我的图不断更新，用户想要最新的信息，这不是一个可行的解决方案）
- 大量用户请求信息，这将给服务器带来相当大的负担，因为它必须多次处理图形
我该如何开始面对这些挑战？我研究了hadoop和spark，但它们似乎有高延迟的解决方案（具有批处理）或解决图不不断变化的问题的解决方案。
我有一个想法，也许可以处理图的不同部分并对其进行索引，然后跟踪图的更新位置，并重新处理图的该部分（一种分布式动态编程方法），但我不确定这有多可行
谢谢！
我该如何开始面对这些挑战？
我将回答这个问题，因为这是一个重要的问题。你列举了一些合理的担忧，所有这些都是你需要处理的，我不会直接解决。
为了开始，您需要完成语义的定义。你可能认为你已经完了，但事实并非如此。当你说"用户想要最新的信息"时，"最新"是指吗
- "过去的一切"，这导致每个事务到图的完全序列化，从而使答案反映出每一条可能的信息
- 或者"所有事务都在X秒之前处理"，这会导致部分序列化，即当前的多个数据库状态中哪些状态会逐渐序列化为过去
如果1。是必需的，根据应用程序的不同，您的代码中可能会有不可避免的热点。由于事务不一致，您可以立即获得何时回滚事务的信息。
如果2。是可以接受的，您有可能获得更好的性能。不过，也有一些权衡。您会遇到这样的情况，即您必须在首次接受后回滚交易。
一旦你回答了这个问题，你就开始面对你的挑战，我想，你还会有更多的问题。
我对图不太了解，但我确实了解一些网络。
我试着记住的一条规则是……如果你能让客户端做，就不要在服务器端做工作。
服务器所需要做的就是维护原始数据，向客户端提供原始数据，并在数据更改时通知连接的客户端。
客户可以拥有自己的原始数据副本，然后根据他们所知道的内容和收到的更新生成计算/可视化。
客户端只需要知道是否有新记录或旧记录是否已更改。
如果出于某种原因，你绝对必须处理数据服务器端并将其发送到客户端（例如，客户端是第三方软件，不是你可以控制的东西，它需要处理的数据，而不是原始数据），那么，你确实有点问题，所以找一个糟糕的服务器。。。或3或30。在这种情况下，我必须确切地知道数据是什么以及如何处理数据，以便对缩放配置提出任何建议。