我有一个pub-sub缓存形式的数据源，其中包含一组包含增量更新的大量数据。需要将数据馈送到kdb数据库（由于数据大小而导致的多个实例），这些数据库将规范化并将数据解析为表以供前端进程使用。所有单个kdb实例还将数据发布到聚合器kdb进程以包含聚合数据。客户端需要深度和聚合级别的数据。我正在为kdb工厂设计，以满足这些有效工作的需求，向GUI发送快速更新，以及易于维护。
我见过的大多数设计总是有订阅所有更新的tickerplant？我想让每个kdb实例从缓存订阅其数据分区并处理它。然后所有实例规范化数据并发送到聚合器kdb进程。 GUI从所有实例获取更新。有一个tickerplant的实用性是什么？你觉得这个设计有什么问题吗？
欢迎提出任何建议和意见
答案 0 :(得分：1)
这是一种久经考验的方法。一般来说，除了超级精益之外，tickerplants是有用的，因为实时数据库（完全在内存中）可以锁定或死亡。但由于tickerplant还会创建一个日志文件，您可以愉快地重新启动实时，它会读到最后一次插入并继续收听新插入。
你的想法很健全，而且确实是很多人为平衡负荷所做的事情。精确的架构实际上取决于很多东西 - 你有多少台机器，你想要多少冗余，等等以及客户要求。如果我是你，我会有单独的tickerplants，将数据分解为数据集的表/ sym分区，使其更易于管理，然后有专门的tickerplants，在每个tick上保持深度/订单簿状态。
小心缓慢的消费者，这可以支持一个自动售货机。 GUI通常会在网络上其他地方的较慢的PC上运行，并且可能有100个GUI订阅同一个tickerplant ...在这种情况下，创建许多链接的tickerplants可能是一个好主意，可以有效地减少tcp加载“主要”tickerplant。
当您处理包含大量（可能很慢）客户端的大型数据集时，像这样链接的tickerplants 非常。