KDB+ 架构
Kdb+ 是一种高性能、大容量数据库，从一开始就设计用于处理大量数据。 它是完全 64 位的，并且具有内置的多核处理和多线程。 实时数据和历史数据使用相同的架构。 该数据库采用了自己强大的查询语言q，因此可以直接对数据运行分析。
kdb+tick是一种允许捕获、处理和查询实时和历史数据的架构。
Kdb+/tick 架构
下图提供了典型 Kdb+/tick 架构的概括轮廓，随后简要说明了各个组件和数据的流通流程。
数据源是时间序列数据，主要由证券数据源提供商或直接从交易所提供。
为了获取相关数据，数据馈送中的数据由馈送处理程序进行解析。
数据被 feed 处理程序解析后，就会进入 ticker-plant。
为了从任何故障中恢复数据，股票代码工厂首先将新数据更新/存储到日志文件中，然后更新其自己的表。
更新内表和日志文件后，实时循环数据将持续发送/发布到实时数据库和所有请求数据的链式订阅者。
在一个工作日结束时，日志文件将被删除，创建一个新文件，并将实时数据库保存到历史数据库中。 一旦所有数据都保存到历史数据库中，实时数据库就会清除其表。
Kdb+ Tick 架构的组件
Data Feeds
Data Feeds 数据源可以是任何市场或其他时间序列数据。 将数据馈送视为馈送处理程序的原始输入。 提要可以直接来自交易所（实时流数据）提供商或任何其他外部机构。
Feed Handler
Feed Handler 数据源处理程序将数据流转换为适合写入 kdb+ 的格式。 它连接到数据源，检索数据并将其从特定于源的格式转换为 Kdb+ 消息，该消息发布到代码工厂进程。 通常，进给处理程序用于执行以下操作 −
- 根据一组规则捕获数据。
- 将数据从一种格式转换（/丰富）为另一种格式。
- 获取最新值。
Ticker Plant
Ticker Plant 是 KDB+ 架构中最重要的组成部分。 它是实时数据库或直接订阅者（客户端）连接以访问财务数据的股票代码工厂。 它以发布和订阅机制运行。它执行以下操作 −
从 feed 处理程序接收数据。
自动收报机收到数据后，它将副本存储为日志文件，并在代码工厂获得任何更新后更新它，以便在发生任何故障时，我们不应该丢失任何数据。
客户端（实时订阅者）可以直接订阅股票行情。
在每个工作日结束时，即实时数据库收到最后一条消息后，它将今天的所有数据存储到历史数据库中，并将其推送给所有订阅了今天数据的订阅者。然后它重置所有表。 一旦数据存储在历史数据库或其他直接链接到实时数据库（rtdb）的订阅者中，日志文件也会被删除。
因此，股票代码工厂、实时数据库和历史数据库可以 24/7 全天候运行。
由于ticker-plant 是一个Kdb+ 应用程序，因此可以像任何其他Kdb+ 数据库一样使用q 查询其表。 所有代码工厂客户端只能作为订户访问数据库。
实时数据库
实时数据库（rdb）存储今天的数据。 它直接连接到股票代码工厂。 通常，它会在市场交易时段（一天）存储在内存中，并在一天结束时写入历史数据库 (hdb)。 由于数据（rdb数据）存储在内存中，处理速度非常快。
由于 kdb+ 建议 RAM 大小为每天预期数据大小的四倍或更多，因此在 RDB 上运行的查询速度非常快，并提供卓越的性能。 由于实时数据库只包含今天的数据，因此不需要日期列（参数）。
例如，我们可以进行 RDB 查询，例如:
select from trade where sym = `ibm OR select from trade where sym = `ibm, price > 100
历史数据库
如果我们必须计算一家公司的估值，我们需要提供其历史数据。 历史数据库 (hdb) 保存过去完成的交易数据。 每一天的记录都会在一天结束时添加到 HDB。 hdb 中的大型表要么以展开方式存储（每列存储在其自己的文件中），要么按时态数据分区存储。 此外，一些非常大的数据库可能会使用 par.txt（文件）进一步分区。
这些存储策略（展开、分区等）在从大型表中搜索或访问数据时非常高效。
历史数据库还可用于内部和外部报告目的，即用于分析。 例如，假设我们想从交易（或任何）表名中获取 IBM 公司在特定日期的交易，我们需要编写如下查询 −
thisday: 2014.10.12 select from trade where date = thisday, sym =`ibm
注意 − 一旦我们了解了 q 语言的一些概述，我们将编写所有此类查询。
