Architecture 在kdb工厂中使用tickerplant有什么用？

我有一个pub-sub缓存形式的数据源，其中包含一组具有增量更新的大型数据。数据需要被馈送到kdb数据库（由于数据的大小而有多个实例），该数据库将数据规范化并解析为表，供前端进程使用。所有单个kdb实例还将数据发布到聚合器kdb进程，以包含聚合数据。客户需要深度和聚合级别的数据。我正在设计kdb工厂，以满足这些要求，这些要求将高效工作，向GUI发送快速更新，并便于维护

我看到的大多数设计都有一个tickerplant订阅所有更新？我正在考虑让每个kdb实例从缓存订阅其数据分区并对其进行处理。然后，所有实例规范化数据并发送到聚合器kdb进程。GUI从所有实例获取更新。拥有tickerplant的真正效用是什么？你觉得这个设计有什么问题吗

---

欢迎您提出任何建议和意见

这是一种久经考验的方法。一般来说，除了超级精简之外，TickerPlant也很有用，因为实时数据库（完全在内存中）可能会锁定或关闭。但是由于tickerplant还创建了一个日志文件，您可以愉快地重新启动实时程序，它将一直读取到最后一次插入，并继续侦听新的插入

你的想法是正确的，而且确实是许多人为了平衡负载所做的事情。确切的体系结构实际上取决于很多因素——您拥有多少台机器，需要多少冗余，以及客户机的需求。如果我是你，我会有单独的TickerPlant，将数据分解为数据集的表/符号分区，使其更易于管理，然后有专门的TickerPlant，在每个刻度上保持深度/订单状态

也要小心缓慢的消费者，因为他们可能会支持tickerplant。GUI通常会在网络上其他地方的较慢PC上运行，可能会有100个GUI订阅相同的tickerplant。。。在这种情况下，创建大量以链订阅的tickerplant可能是一个好主意，这样可以有效地减少“主”tickerplant上的tcp负载

当您处理具有大量（可能较慢）客户端的大型数据集时，像这样链接tickerplant非常有用