KDB + - 架构( Architecture)
Kdb +是一个高性能,高容量的数据库,从一开始就设计用于处理大量数据。 它完全是64位,并具有内置的多核处理和多线程。 相同的架构用于实时和历史数据。 数据库包含自己强大的查询语言q,因此可以直接在数据上运行分析。
kdb+tick是一种允许捕获,处理和查询实时和历史数据的体系结构。
Kdb +/tick体系结构
下图提供了典型Kdb +/tick体系结构的概括,随后是各种组件的简要说明和数据的直通流程。
数据馈送是一个时间序列数据,主要由路透社,彭博社或直接来自交易所的数据馈送提供商提供。
为了获得相关数据,来自数据馈送的数据由feed handler解析。
一旦数据由Feed处理程序解析,它就会转到ticker-plant 。
要从任何故障中恢复数据,股票代码工厂首先将新数据更新/存储到日志文件,然后更新其自己的表。
在更新内部表和日志文件之后,将持续时间循环数据连续发送/发布到实时数据库和请求数据的所有链式订户。
在工作日结束时,将删除日志文件,创建新日志文件并将实时数据库保存到历史数据库中。 将所有数据保存到历史数据库后,实时数据库将清除其表。
Kdb + Tick体系结构的组件
数据Feed
数据馈送可以是任何市场或其他时间序列数据。 将数据馈送视为馈送处理程序的原始输入。 可以直接来自交换(实时流数据),来自新闻/数据提供商,如汤森路透,彭博社或任何其他外部机构。
Feed Handler
馈送处理程序将数据流转换为适合写入kdb +的格式。 它连接到数据源,它检索数据并将数据从特定于Feed的格式转换为Kdb +消息,该消息将发布到自动收录机工厂流程。 通常,饲料处理程序用于执行以下操作 -
- 根据一组规则捕获数据。
- 将数据从一种格式转换(/充实)到另一种格式。
- 抓住最新的价值观。
自动收报机
Ticker Plant是KDB +架构中最重要的组件。 它是实时数据库或直接订户(客户)连接的股票代码工厂,用于访问财务数据。 它在publish and subscribe机制中运行。 获得订阅(许可证)后,将定义发布者(代码工厂)的勾选(常规)发布。 它执行以下操作 -
从Feed Handler接收数据。
在股票代码工厂收到数据后,它立即将副本存储为日志文件,并在代码工厂获得任何更新后对其进行更新,以便在出现任何故障时,我们不应该有任何数据丢失。
客户(实时订户)可以直接订阅自动收报机。
在每个工作日结束时,即,一旦实时数据库收到最后一条消息,它就将所有今天的数据存储到历史数据库中,并将其推送给已订阅当前数据的所有订户。 然后它重置所有表。 一旦将数据存储在历史数据库或其他直接链接的订户中,就会删除日志文件到实时数据库(rtdb)。
因此,自动收报机,实时数据库和历史数据库全天候运行。
由于股票代码工厂是Kdb +应用程序,因此可以像使用任何其他Kdb +数据库一样使用q查询其表。 所有自动收报机工厂客户端只能作为订户访问数据库。
Real-Time Database
实时数据库(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中的大表要么以sppeded的形式存储(每列存储在自己的文件中),要么存储由时态数据分区。 还可以使用par.txt (文件)进一步分区一些非常大的数据库。
这些存储策略(展开,分区等)在从大型表中搜索或访问数据时非常有效。
历史数据库还可用于内部和外部报告目的,即用于分析。 例如,假设我们想要从交易(或任何)表名称获取IBM特定日期的公司交易,我们需要编写如下查询 -
thisday: 2014.10.12
select from trade where date = thisday, sym =`ibm
Note - 一旦我们得到q语言的概述,我们将编写所有这些查询。