共计 2797 个字符，预计需要花费 7 分钟才能阅读完成。
小 T 导读：对于青岛协同翻新金融研究院来说，始终打交道的交易记录、价格等数据均为时序数据，在抉择数据库（Database）时，TDengine“一个设施一张表”的设计吸引了他们的眼光。目前 TDengine 曾经在其生产零碎中稳固运行了 38 周。本文总结了他们在选型、搭建等方面的所思所想，以及利用 TDengine 之后所获得的成果。
企业简介：
为切实服务国家经济、金融倒退，中国金融量化迷信与技术协同翻新核心在山东青岛设立了一个高端智库，即青岛协同翻新金融研究院。依靠于翻新核心的国内顶级专家资源、在量化金融与金融科技领域的国内当先实践钻研与实务技术成绩，研究院致力于促成我国金融畛域创新型尖端实践人才、适用性高端技术人才的教育与造就，晋升相干畛域在风险管理、资产定价、产品设计等各方面的定量分析与决策技术水平，踊跃保护金融稳固、促成金融倒退。
单刀直入地说，咱们抉择 TDengine 的理由很简略——“一个设施一张表”的模型很适宜咱们的量化剖析场景。实质上来讲，交易记录、价格等都是时序数据，其实就是“一只股票一张表”，所以非常符合。
在咱们的业务场景中，TDengine 次要负责三点：一是对回测的数据反对，因为它能够轻松抗住海量数据的写入。目前咱们的数据入库形式是应用 Python 连接器间接写入 TDengine（6030 端口）。具体形式为：会通过券商的直连贯口将他们提供的数据做一个 SQL 拼接，利用拼接 SQL 的形式，单个 SQL 写入几千行数据，将少量数据一次性写入到一个表中。目前，咱们每天新增数据量大略在 2000 万行左右。
（注：股票回测是指设定了某些股票指标组合后，基于历史曾经产生过的实在行情数据，在历史上某一个工夫点开始，严格依照设定的组合进行选股，并模仿实在金融市场交易的规定进行模型买入、模型卖出，得出一个时间段内的盈利率、最大回撤率等数据。）
二是基于以上数据进行的回测数据分析。
三是局部盘中策略的数据预加载。
但因为这块有每秒几万次的查问用在高频业务上，所以临时还没有尝试利用 TDengine，目前大部分盘中业务应用的还是 Redis。据社区工作人员示意，将来的 TDengine 3.0 版本将会反对自定义工夫范畴的缓存，届时或者能够帮到咱们。
除了上述次要的应用场景之外，TDengine 还帮忙咱们实现了局部深度学习模型的数据训练和测试。
具体落地与实际效果
在目前的业务中，咱们选用了三台 8 核 16G 服务器，以此搭建了三正本的集群。
这里大家须要留神，三节点并不代表三正本，也并不代表你的数据库曾经具备了高可用性。数据库的高可用是在 “create database xxxx replica 1/2/3” 的过程中指定的，然而如果你遗记了也没关系，前期能够通过 “alter database xxxx replica 1/2/3” 来动静地进行调整。TDengine 会主动复制出一批分片（Vnode），并平均地散布在各个节点之上，成果如下”show 库名.vgroups”所示。
（注：如果数据量很大，在数据同步的过程中因为网络稳定导致数据文件复制中断，也能够手动复制 Vnode 目录下的文件到指定节点再启动。）
依据不同类型的业务，咱们创立了 7 张不同的超级表，子表数量为 33076 张，目前咱们导入的数据总量曾经达到了 46 亿之多，其中最大的一张超级表白到了 26 亿行，理论磁盘占用大略在 130GB 左右。表的列数如下图”columns”所示，数据类型以 Float 为主。
上面我再列举一些典型的查问场景：
select first(open), max(high), min(low), last(close), sum(volume), sum(amount) from ‘bar_1m_SH600519’ where trade_time >= ‘2021-12-25 09:30:00’ and trade_time <= ‘2021-12-31 15:00:00’ interval(30m) fill(null)
下图为用 1 分钟的 bar 数据合成 30 分钟的 bar 数据，查问出的茅台股票在一段时间内的开盘价、最高价、最低价、收盘价。
select code,name,trade_time,trade_date,open,high,low,price,pre_price,volume,amount,ask_price1,ask_volume1,ask_price2,ask_volume2,ask_price3,ask_volume3,ask_price4,ask_volume4,ask_price5,ask_volume5,bid_price1,bid_volume1,bid_price2,bid_volume2,bid_price3,bid_volume3,bid_price4,bid_volume4,bid_price5,bid_volume5 from tick_stock where trade_time >=’2022-03-18 09:30:00′ and trade_time <=’2022-03-18 09:30:02′ and code in (‘002429.SZ’, ‘000006.SZ’)
下图为查问某两支股票在某个工夫范畴内的 tick 数据。
期待 TDengine 3.0 版本
除了数据库自身的性能之外，咱们也留神到 TDengine 的周边生态也在不断完善。在 2.4 版本公布之后，它实现了很多性能更新，其中包含一款应用了监控数据库（log 库）+ Grafana 对 TDengine 进行监控的解决方案——TDinsight。在此之前，咱们应用的始终是我本人编写的一款监控程序，但 TDinsight 使最终的展现成果更加清晰直观，数据库的运行状态也更加高深莫测。
于是，咱们立即着手更新了 TDengine 2.4 版本，并且部署了 TDinsight。
以下就是 Grafana 展现界面的一部分，能够看到， 在以后并发写入的规模下（每秒 1 万 -1.5 万行），CPU 资源占用率只有 1.88%，内存占用只有 2G。只管目前咱们应用的是三台 8 核 16G 的机器，但却能够在相当长的工夫内不必再放心硬件资源问题了。
人不知; 鬼不觉中，TDengine 在生产零碎中曾经跑了 38 周了，整体来说各方面性能都不错。偶然遇到的一些应用问题，也在 TDengine 社区失去了及时的帮忙和解答，运行至今咱们发现了两个小 Bug，官网都很快响应解决了。只管还有一些场景在以后的 2.0 版本还并不能齐全适配，但 3.0 版本出炉后就能够解决了。
最初祝 TDengine 越来越好吧，期待 3.0 版本的公布让它成为时序数据库里的 Oracle。
作者：
William (QQ: 392667) 16 年股票投资教训，15 年软件开发教训，负责青岛金融研究院量化零碎整体架构，以及相干高频交易模型的开发。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
