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