⬆️点击片，与专业的解决方案架构师聊一聊
在金融量化交易场景中，每天都会产生大量的交易记录和交易信息需要存储，同时对数据也有较高要求的查询需求，整体需求概括起来就是历史数据的存储、实时数据的接收以及数据的监控和分析。对于这类有典型时序特征的数据，很多企业在业务初期选择了团队熟悉的HBase、MySQL、MongoDB等数据库。但是随着业务的快速发展，这些数据库已经无法满足大体量数据的写入、存储、分析监控等业务需求。
TDenginex同花顺
“目前从大数据监控这个场景看，TDengine在成本、性能和使用便利性方面都显示出非常大的优势，尤其是在节省成本方面给我们带来了很大惊喜。在预研和项目落地过程中，涛思数据的工程师也提供了专业、及时的帮助，后续我们也将在同花顺的更多场景中尝试应用TDengine。”
同花顺每天需要接收海量交易所行情数据，确保行情数据的数据准确。但由于该部分数据过于庞大，而且使用场景颇多，每天会产生很多的加工数据，整个系统除了对实时数据的读写性能及延时有较高要求外，还需要聚焦历史日级别数据做投资组合的各种分析，在整个分析过程中，涉及巨量的数据集，这对历史数据库的读写性能也提出了很高的要求。之前采用的Postgres+LevelDB数据存储方案，除了依赖多、稳定性较差外，性能方面也无法满足需求。通过对ClickHouse、InfluxDB、TDengine等时序数据存储方案的调研，最终其选择了TDengine。
架构
改造后性能对比
????点击案例查看更多技术细节
TDenginex弘源泰平
“在写入上，单节点TDengine可以轻松实现每秒大概3万行数据的写入量，同时消耗服务器资源又比InfluxDB与MySQL要小很多。目前我们通过TDengine录入的两个信号表已经写入了82亿条数据，原数据大概为92GB，实际占用存储空间为20G左右，压缩率高达23%。除了写入与存储，TDengine进行日常查询的速度也十分优秀，面对几十亿级别的大表，也能实现毫秒级响应。”
弘源泰平的量化交易系统每天要接收大量的行情数据，也要基于行情产生大量的决策信号。这些数据都需要及时存下来，供盘中和盘后使用。传统存放行情数据的方式有文件系统、关系型数据库或者文档数据库。此前他们分别尝试了MySQL和知名的时序数据库InfluxDB，但是性能都没有达到预期，出现了响应时间长、资源浪费等诸多问题。最终，其改用TDengine彻底解决了实时写入大量数据点和快速查询的问题。
资源消耗
服务器配置如下：64G内存+40核8GHzCPU+机械硬盘。在业务运行期间，taosd的CPU在4%上下浮动，进程使用的物理内存百分比为12%。由于其vnode配置较多，而每个vnode都有自己固定的内存缓冲区，因此内存占用稍多，但后续即便是继续大量增加新表或者加大写入量，内存占用也不会再有明显的浮动了。
????点击案例查看更多技术细节
TDenginex同心源基金
“对入库的总数据量进行下估算，粗略计算为408*320亿行，大概12TB左右，后面经过统计最终实际占用磁盘空间却只有2T左右，这令我们十分震惊——压缩率高达17%。在查询方面，从TDengine客户端服务器使用Python从服务端拉取连续两个月的期货行情数据，耗时仅需0.16秒。”
从同心源的业务模式出发，业务人员主要通过数据挖掘和自动模式识别这两种方式来发现市场的交易规律，其工作场景基于大量的金融数据之上。经过多年发展，股票市场数据量越发庞大，随着每日新数据的清洗写入，总量变得更加水涨船高。对于十几TB的数据量，单是进行存储已经不易，如果还要对数据进行查询下载等操作，更是难上加难。种种问题叠加，同心源对市面上的主流数据库逐渐丧失信心，尝试使用更有针对性的时序数据库，TDengine便是他们的选择之
????点击案例查看更多技术细节
TDenginex青岛金融研究院
“根据不同类型的业务，我们创建了7张不同的超级表，子表数量为33076张，目前我们导入的数据总量已经达到了46亿之多，其中最大的一张超级表达到了26亿行，实际磁盘占用大概在130GB左右。”
在其业务场景中，TDengine主要负责三点：一是对回测的数据支持，二是基于以上数据进行的回测数据分析，三是部分盘中策略的数据预加载。目前其数据入库方式是使用Python连接器直接写入TDengine。具体方式为：会通过券商的直连接口将他们提供的数据做一个SQL拼接，利用拼接SQL的方式，单个SQL写入几千行数据，将大批数据一次性写入到一个表中。
????点击案例查看更多技术细节
写在最后
从上述案例中我们也能看到，看似简单的数据处理需求，但由于数据记录条数巨大，导致数据的实时写入成为瓶颈，查询分析极为缓慢，数据存储成本显著，技术挑战层出不穷。而传统的关系型数据库、NoSQLDatabase没有针对性去对应时序数据特点，在性能提升上极为有限，只能依靠集群技术，投入更多的计算资源和存储资源来处理，系统的运营维护成本也因此急剧上升。从他们的改造实践出发，选择时序数据库也是真正的实现了“对症下药”。
文章为作者独立观点，不代表观点
相关文章
股民评论