在金融量化交易场景中，每天都会产生大量的交易记录和交易信息须要存储，同时对数据也有较高要求的查问需要，整体需要概括起来就是历史数据的存储、实时数据的接管以及数据的监控和剖析。对于这类有典型时序特色的数据，很多企业在业务初期抉择了团队相熟的 HBase、MySQL、MongoDB 等数据库。然而随着业务的疾速倒退，这些数据库曾经无奈满足大体量数据的写入、存储、剖析监控等业务需要。
为了帮忙一众金融企业寻找到适合的数据库解决方案，咱们汇总了几个比拟有代表性的企业客户案例，心愿他们的相干实践经验应该可能给到行业从业者一些解决思路。
TDengine x 同花顺
“目前从大数据监控这个场景看，TDengine 在老本、性能和应用便利性方面都显示出十分大的劣势，尤其是在节省成本方面给咱们带来了很大惊喜。在预研和我的项目落地过程中，涛思数据的工程师也提供了业余、及时的帮忙，后续咱们也将在同花顺的更多场景中尝试利用 TDengine。”
业务背景
同花顺每天须要接管海量交易所行情数据，确保行情数据的数据精确。但因为该局部数据过于宏大，而且应用场景颇多，每天会产生很多的加工数据，整个零碎除了对实时数据的读写性能及延时有较高要求外，还须要聚焦历史日级别数据做投资组合的各种剖析，在整个剖析过程中，波及巨量的数据集，这对历史数据库的读写性能也提出了很高的要求。之前采纳的 Postgres+LevelDB 数据存储计划，除了依赖多、稳定性较差外，性能方面也无奈满足需要（点击下方案例链接获取具体业务痛点问题）。通过对 ClickHouse、InfluxDB、TDengine 等时序数据存储计划的调研，最终其抉择了 TDengine。
架构图
革新后性能比照
点击案例查看更多技术细节
TDengine x 弘源泰平
“在写入上，单节点 TDengine 能够轻松实现每秒大略 3 万行数据的写入量，同时耗费服务器资源又比 InfluxDB 与 MySQL 要小很多。目前咱们通过 TDengine 录入的两个信号表曾经写入了 82 亿条数据，原数据大略为 92GB，理论占用存储空间为 20G 左右，压缩率高达 23%。除了写入与存储，TDengine 进行日常查问的速度也非常优良，面对几十亿级别的大表，也能实现毫秒级响应。”
业务背景
弘源泰平的量化交易系统每天要接管大量的行情数据，也要基于行情产生大量的决策信号。这些数据都须要及时存下来，供盘中和盘后应用。传统寄存行情数据的形式有文件系统、关系型数据库或者文档数据库。此前他们别离尝试了 MySQL 和出名的时序数据库（Time Series Database）InfluxDB，然而性能都没有达到预期，呈现了响应工夫长、资源节约等诸多问题（点击下方案例链接获取具体业务痛点问题）。最终，其改用 TDengine 彻底解决了实时写入大量数据点和疾速查问的问题。
资源耗费
服务器配置如下：64G 内存 +40 核 1.8GHz CPU+ 机械硬盘。在业务运行期间，taosd 的 CPU 在 4% 高低浮动，过程应用的物理内存百分比为 11.2%。因为其 vnode 配置较多，而每个 vnode 都有本人固定的内存缓冲区，因而内存占用稍多，但后续即使是持续大量减少新表或者加大写入量，内存占用也不会再有显著的浮动了。
点击案例查看更多技术细节
TDengine x 同心源（三亚）基金
“对入库的总数据量进行下估算，粗略计算为 408*320 亿行，大略 12TB 左右，前面通过统计最终理论占用磁盘空间却只有 2T 左右，这令咱们非常震惊——压缩率高达 16.7%。在查问方面，从 TDengine 客户端服务器应用 Python 从服务端拉取间断两个月的期货行情数据，耗时仅需 0.16 秒。”
业务背景
从同心源的业务模式登程，业务人员次要通过数据挖掘和主动模式识别这两种形式来发现市场的交易法则，其工作场景基于大量的金融数据之上。通过多年倒退，股票市场数据量越发宏大，随着每日新数据的荡涤写入，总量变得更加水涨船高。对于十几 TB 的数据量，单是进行存储曾经不易，如果还要对数据进行查问下载等操作，更是难上加难。种种问题叠加，同心源对市面上的支流数据库逐步丢失信念，尝试应用更有针对性的时序数据库，TDengine 便是他们的抉择之一。
点击案例查看更多技术细节
TDengine x 青岛金融研究院
“依据不同类型的业务，咱们创立了 7 张不同的超级表，子表数量为 33076 张，目前咱们导入的数据总量曾经达到了 46 亿之多，其中最大的一张超级表白到了 26 亿行，理论磁盘占用大略在 130GB 左右。”
业务背景
在其业务场景中，TDengine 次要负责三点：一是对回测的数据反对，二是基于以上数据进行的回测数据分析，三是局部盘中策略的数据预加载。目前其数据入库形式是应用 Python 连接器间接写入 TDengine（6030 端口）。具体形式为：会通过券商的直连贯口将他们提供的数据做一个 SQL 拼接，利用拼接 SQL 的形式，单个 SQL 写入几千行数据，将少量数据一次性写入到一个表中。
点击案例查看更多技术细节
写在最初
从上述案例中咱们也能看到，看似简略的数据处理需要，但因为数据记录条数微小，导致数据的实时写入成为瓶颈，查问剖析极为迟缓，数据存储老本显著，技术挑战层出不穷。而传统的关系型数据库、NoSQL Database 没有针对性去对应时序数据特点，在性能晋升上极为无限，只能依附集群技术，投入更多的计算资源和存储资源来解决，零碎的经营保护老本也因而急剧回升。从他们的革新实际登程，抉择时序数据库也是真正的实现了“隔靴搔痒”。
欢送增加小 T（TDengine），退出物联网技术探讨群，第一工夫理解 TDengine 官网信息，与关注前沿技术的同学们独特探讨新技术、新玩法。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。