architecture - 在 kdb 植物中有一个 tickerplant 有什么用？

Question

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

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

欢迎大家提出建议和意见

Answer 1

这是一种久经考验的方法。一般来说，除了 super 精简之外，tickerplants 很有用，因为实时数据库(完全在内存中)可以锁定或死亡。但由于 tickerplant 还会创建一个日志文件，您可以愉快地重新启动一个实时系统，它会读取到上次插入的点并继续监听新的插入。

你的想法很合理，确实很多人都是这样做的来平衡负载的。确切的架构实际上取决于很多事情——你有多少台机器，你想要多少冗余等等，以及客户的要求。如果我是你，我会使用单独的 tickerplants 将数据分解为数据集的表/sym 分区，以使其更易于管理，然后使用专门的 tickerplants 在每次报价时保持深度/订单簿状态。

也要小心缓慢的消费者，这可以支持 tickerplant。 GUI 通常会在网络上其他地方的速度较慢的 PC 上运行，并且可能有 100 个 GUI 订阅了同一个 tickerplant ...加载“主”tickerplant(s)。

当您处理具有大量(可能很慢)客户端的庞大数据集时，像这样链接 tickerplants 非常有用。