交易所,交易所排名,交易所排行,加密货币是什么,加密货币交易平台,加密货币平台,币安交易所,火币交易所,欧意交易所,Bybit,Coinbase,Bitget,Kraken,全球交易所排名,交易所排行如果我们要做行情 tick 数据的存储，怎样的数据结构查找起来才会比较快？在加入 TDengine 之前，本文作者丁博在弘源泰平量化投资做量化工程师，曾经遇到过这一类存储行情 tick 数据的问题，本文会就此问题进行详细的技术解读。

　　如果你的需求仅仅是盘中实时分析，且监控的 Instrument（CTP 接口对现货、期货、期权等合约的统称， 以下简称【合约】） 总数不多，则可以直接使用内存存储。通常只有超高频交易系统才必须这么做。内存存储也有很多可选方案，其中有两大方案较为通用。

　　第一级 map 的类型为 std::unordered_map，键为 InstrumentID， 值为第二级 map 的指针。第二级 map 的类型为 std::map，键为行情时间戳，值为行情结构体。（注：行情时间戳需要根据 UpdateTime 和 UpdateMillisec 两个字段构造一个类型为 long 的毫秒值）。std::unordered_map 底层依赖的数据结构是哈希表，按 key 索引速度是最快的。std::map 底层的数据结构是二叉树搜索树，可以严格按照 key 的大小顺序迭代全部或某一段数据。总体而言这个数据结构的优势是：快速查找某个合约某个时间点或某个时间段返回的行情。这是后续做交易信号计算的基础。

　　由于每种合约每天的标准行情 tick 总数都是固定的（个别交易所除外），因此我们可以提前初始化好一个数组来存行情。按每秒 2 个 tick 算（500 毫秒一个点），标准行情的长度可能是 28800。当收到行情通知时，行情时间距离哪个标准 tick 点最近就归为哪个 tick。比如行情时间是 9 点 50 分 20 秒 133 毫秒，那么可以当作 9 点 50 分 20 秒 0 毫秒的行情。如果出现前后两个 tick 时间大于 500 毫秒的情况，那就

　　还需要补全中间空缺的行情，相当于边收行情边做标准化操作。这样做的优势是：

　　交易策略通常会依赖标准化的行情计算交易信号，收行情和标准化并作一步会更节省时间。

　　无论是否做超高频交易，持久化存储行情都是有必要的。通常持久化存储为的是进行盘后复盘分析, 因为在大数据量下，传统的存储方案（MongoDB、MySQL、直接存文件等等）很快就会遇到性能瓶颈（无论是读还是写），不适合做盘中的计算。近年来，时序数据库（Time-Series Database）异军突起，使得盘中盘后使用一种存储方案成为可能。特别是像 TDengine 这样带有缓存功能、消息队列功能和集群功能的时序数据库，用来存行情是非常合适。下面我将以 TDengine Database 为例为大家介绍持久化存储方案。

　　安装成功后，如何启动 TDengine Database 的提示信息就会自动弹出，照着操作就可以。

　　TDengine 对每个表的最新数据都有缓存功能，无需再读磁盘，使用 last 函数就能快速获取。

　　以上两个示例程序，展示了写入和查询的方法。结合 TDengine 内置的查询函数和按窗口聚合功能，可实1. 使用 MAX、 FIRST、 MIN、 LAST 四个 SQL 函数计算 K 线上高、开、低、收四个价位。2. 使用 INTERVAL 和 SLIDING 查询子句和 AVG 函数计算移动均价。此处不再给出具体示例，可参考官方文档。

　　除了上述内容外，TDengine Database 还有非常丰富的分析函数，如果你感兴趣的话建议参考官方文档。此外，在 TDengine 的实际应用中，也有很多客户的实践是关于量化投资场景中的数据处理。

　　以同花顺为例，其每天都需要接收海量交易所行情数据，以确保行情数据的数据准确，但由于该部分数据过于庞大，而且使用场景颇多，因此每天会产生很多的加工数据，在组合管理(PMS)上还会使用到历史行情数据。之前他们采用的是 Postgres+LevelDB 作为数据的存储方案，但仍旧痛点频发，随后通过对数据流、行情获取模块的分析，发现目前主要存在以下两个亟需解决的问题：

　　依赖多，稳定性较差：PMS作为多品种的投后分析服务, 需要使用到各种日线数据、当天实时行情数据、当天分钟数据等，在数据获取方面需要依赖Http以及Postgres、LevelDB等数据库。过于多的数据获取链路会导致平台可靠性降低，同时依赖于其他各个服务，导致查询问题过于复杂。

　　从业务发展的角度来讲，存储方案的改造迫在眉睫，之后同花顺开始对 ClickHouse、InfluxDB、TDengine 等数据存储方案进行调研。由于行情数据是绑定时间戳的形式，所以显然时序数据库更适用于这个业务场景，在 InfluxDB 和 TDengine 之间，由于 TDengine 的写入速度远高于 InfluxDB，且集群版开源，同时还支持包含 C/C++、Java、Python、Go 和 RESTful 在内的多种数据接口，因此成为同花顺的最终选用方案。

　　改造之后的性能效果提升还是非常明显的，下图是同花顺做的一张改造前后性能对比图，可以更为直观地感受到效果提升：

　　同时改造后，稳定性也显著增强，改造前调用数据情况共 40W 次，共出现异常 0.01% 的异常，改造后出现异常降低至 0.001%。

　　在 TDengine Database 官网的 Case 合集中，还有弘源泰平量化、同心源基金等几篇聚焦投资量化场景下数据处理难题的客户案例，由于篇幅所限，便不在此一一列举了，有需要的朋友可以去官网查找文章进行参考。如果还有投资量化场景下其他的数据处理难题，也欢迎在文章下方进行留言，我们后续可以加微信进行详细讨论和沟通。

　　文章转载自TDengine，如果涉嫌侵权，请发送邮件至：进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。