在kdb工厂中使用挠痒痒有什么用？

Question

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

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

欢迎任何建议和意见

Answer 1

这是一种经过试验和测试的方法。一般来说，除了超级精益之外，挠痒痒也很有用，因为实时数据库(完全在内存中)可以锁定或死掉。但是，由于tickerplant还创建了一个日志文件，所以您可以愉快地重新启动一个实时文件，它将一直读取到最后一个插入点，并继续侦听新插入。

你的想法是合理的，而且确实是许多人为平衡负荷所做的事情。确切的体系结构实际上取决于很多事情--您有多少台机器，需要多少冗余，等等，以及客户机的需求。如果我是你，我就会有单独的代码库，将数据分解成数据集的表/sym分区，以使其更加易于管理，然后专门化了保持深度/订单簿状态的滴答。

小心慢吞吞的消费者，这可能会让人提心吊胆。GUI通常会运行在网络上其他某个较慢的PC上，并且可能有1000多个GUI订阅了相同的代码.在这种情况下，创建大量订阅在链中的tickerplant可能是个好主意，这样可以有效地减少“主”tickerplant上的tcp负载。

当您处理大量(可能是慢的)客户端的大型数据集时，这样的链接代码非常有用。