KDB+架构

Kdb+ 是一种高性能、大容量数据库，从一开始就设计用于处理大量数据。它是完全 64 位的，并且具有内置的多核处理和多线程。实时数据和历史数据使用相同的架构。该数据库采用了自己强大的查询语言q，因此可以直接对数据运行分析。

kdb+tick是一种允许捕获、处理和查询实时和历史数据的架构。

Kdb+/tick架构

下图提供了典型 Kdb+/tick 架构的概括轮廓，随后简要说明了各个组件和数据的流通流。

数据源是时间序列数据，主要由路透社、彭博社等数据源提供商或直接从交易所提供。
为了获取相关数据，来自数据馈送的数据由馈送处理程序进行解析。
一旦数据被 feed handler 解析，它就会被发送到ticker-plant。
为了从任何故障中恢复数据，股票代码工厂首先将新数据更新/存储到日志文件中，然后更新其自己的表。
更新内表和日志文件后，实时循环数据将持续发送/发布到实时数据库和所有请求数据的链式订阅者。
在一个工作日结束时，日志文件将被删除，创建一个新的日志文件，并将实时数据库保存到历史数据库中。一旦所有数据都保存到历史数据库中，实时数据库就会清除其表。

Kdb+ Tick 架构的组件

数据源

数据源可以是任何市场或其他时间序列数据。将数据馈送视为馈送处理程序的原始输入。提要可以直接来自交易所（实时流数据）、来自汤森路透、彭博社等新闻/数据提供商或任何其他外部机构。

饲料处理机

提要处理程序将数据流转换为适合写入 kdb+ 的格式。它连接到数据源，检索数据并将其从特定于源的格式转换为 Kdb+ 消息，该消息发布到代码工厂进程。通常，进给处理程序用于执行以下操作 -

根据一组规则捕获数据。
将数据从一种格式转换（/丰富）为另一种格式。
捕获最新值。

股票行情工厂

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语言的一些概述，我们将编写所有此类查询。