如何以低延迟处理不断更新的图表？

Question

我正在从事一个项目，该项目涉及许多客户端连接到包含一堆图形信息（节点属性和边）的服务器（如果需要，服务器）。他们可以随时选择引入新节点或边，然后从整个图形中请求一些信息（两个节点之间的最短距离、图形着色等）。

这显然很容易开发幼稚算法，但是我正在尝试学习扩展它，以便它可以处理同时更新图形的许多用户，许多用户从图形请求信息，以及处理非常大（500k +）节点的可能性，也可能处理大量边。

我可以预见的挑战：

• 使用不断更新的图表，每次有人请求信息时我都需要处理整个图表...这会大大增加计算时间和延迟
• 对于一个非常大的图表，计算时间和延迟显然会高很多（我读到一些公司通过批处理大量结果并将它们与索引一起存储以供以后使用...但是那么由于我的图表在不断更新并且用户想要最新的信息，这不是一个可行的解决方案）
• 大量用户请求信息，这将对服务器造成相当大的负载，因为它必须多次处理图表

我该如何开始面对这些挑战？我查看了 hadoop 和 spark，但它们似乎具有高延迟解决方案（使用批处理）或解决图形不经常变化的问题的解决方案。

我的想法可能是处理图表的不同部分并为其编制索引，然后跟踪图表的更新位置并重新处理图表的该部分（一种分布式动态编程方法），但我没有确定这是多么可行。

谢谢！

Answer 1

我该如何开始面对这些挑战？

我将回答 这个 问题，因为它很重要。您列举了许多有效的问题，所有这些问题您都需要处理，而我不会直接解决。

为了开始，您需要完成对语义的定义。你可能认为你已经完成了，但你还没有。当您说“用户想要最新的信息”时，“最新”是否意味着

1. “过去的一切”，这会导致每笔交易完全序列化到图表中，以便答案反映每条可能的信息？
2. 或者“所有事务都超过 X 秒前”，这会导致部分序列化，即当前哪些多个数据库状态逐渐序列化到过去？

如果需要 1.，您的代码中可能会出现不可避免的热点，具体取决于应用程序。由于不一致，您可以立即获得关于何时回滚事务的信息。

如果 2. 可以接受，您就有可能获得更好的性能。不过，也有取舍。您可能会遇到必须在初始接受后回滚事务的情况。

一旦你回答了这个问题，你就已经开始面对你的挑战，我想你还会有更多的问题。

Answer 2

我对图表了解不多，但对网络有点了解。

我要牢记的一条规则是……如果您可以让客户端执行此操作，请不要在服务器端执行此操作。

您的服务器需要做的就是维护原始数据，将原始数据提供给客户端，并在数据更改时通知连接的客户端。

客户可以拥有自己的原始数据副本，然后根据他们所知道的和收到的更新生成计算/可视化。

客户只需要知道是否有新记录或旧记录是否已更改。

如果出于某种原因，您绝对必须在服务器端处理数据并将其发送到客户端（例如，客户端是第 3 方软件，不是您可以控制的东西，它需要处理过的数据，而不是原始数据），那么，你确实有一点问题，所以找一个糟糕的服务器......或者 3 或 30。在这种情况下，我必须确切地知道数据是什么以及如何处理它才能制作任何类型关于扩展配置的建议。