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