传统库分表麻烦查询慢?TDengine 如何解决“搜狐基金”的应用难题

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 搜狐基金团队使用的 MySQL 数据库在面对海量数据时存在能力瓶颈,在此背景下,其决定基于 TDengine 尝试一下全新的方案。

该项目需要实时展示国内基金的净值和收益(货币基金),在保证满足折线图展示的功能基础上,还需要加入统计排行、分页展示等功能,为用户提供最全面实时的查询服务。此前搜狐基金团队使用的 MySQL 数据库在面对海量数据时存在能力瓶颈,在此背景下,其决定基于 TDengine 尝试一下全新的方案。

选型背景

在使用 TDengine 之前,我们使用的是 MySQL 数据库。

由于所购买的数据源的基金数据都是混在一起的,包含来自国内的2万只基金,跨越几十年(从九几年至今)的数千万行较宽的数据,如果通过 MySQL 来存储这些数据,我们首先要把每个基金的数据分表,有一定程度的工作量,所以我们决定先全量保存这些数据在一张表中。

但这种大表会导致查询的性能非常低下,为了应对这一问题,我们通过离线查询生成每天的基金数据图片返回给用户,暂未对外提供自定义查询服务。

与此同时,经历了以上种种,我们也在怀疑传统关系型数据库面对海量数据的能力瓶颈。这时候,我们了解到了 TDengine ,它的核心是一款时序数据库Time Series Database),它“一个设备一张表”的特殊设计,与我们正在做的“一个基金一张表”的分表工作不谋而合。因此我们决定基于 TDengine 尝试一下全新的方案。

使用经历

通过充分调研和测试后,我们发现:

由于“超级表”的存在,数据建模变得非常清晰,几乎所有查询都可以以“超级表”为核心用简单的 SQL 完成。

此外,由于“自动建表”这个特色功能,我们可以无需校验就能够直接建表,这让我们得以非常轻松地完成各只基金数据的拆分建表以及写入工作。

可以说,接入 TDengine 的前期准备工作十分顺利。

我们使用三台 4C 16GB 的服务器组建了 TDengine 的集群。

数据库创建语句如下:

值得一提的是,基金数据是一日一条,属于低频次数据。对于这种数据,默认的配置是不够的。一开始我们的查询性能并不快,基本都是在秒级别甚至还有更高。

通过文档和博客以及官方团队的支持,我们放大了 duration 和 stt_trigger 参数,这样确保了不会产生过多的文件碎片影响读写性能,后续的查询全部被优化至毫秒级别。

因此我们总结出来一点经验就是:不同的写入频率属于不同的业务场景,最好不要使用同一个库,而是要分库处理比较好。

超级表建模如下:

当前在日常使用时,业务查询在 100 qps 的情况下,均可以实现毫秒级实时返回数据。

从超级表的设计特点出发,我们在超级表维度上做统计分析就方便多了,比如:筛选类型和日期的全量基金查询——

select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time =#{date} and (type = '003009' or type = '003010')

又比如,查询目前基金净值排行和收益排行,通过简单的 SQL 即可实现——

select time, code, name, manager_id, manager_name, unit_net_value, pre_unit_net_value, accumulate_net_value, pre_day_rate, pre_week_rate, pre_month_rate, pre_three_month_rate, pre_half_year_rate, pre_year_rate, pre_cur_year_rate, pre_start_rate, last_time, last_unit_net_value, last_accumulate_net_value, asset_size from fund_net_value where time =#{date} and order by ${column} ${sort} limit #{offset}, #{size}

与此同时我们搭建了 Grafana 可视化监控体系,利用各种监控工具和软件来收集、存储和分析监控数据,并通过可视化界面提供实时的监控图表和警报,帮助项目相关负责人即时识别修改问题,进一步提高了服务的可靠性和稳定性。

写在最后

总而言之,在保证稳定高效运行的前提下,我们已经通过 TDengine 逐步平滑替代原有功能。考虑到国内基金项目只是一个开始,围绕着股票等其他项目,我们仍需要对这款国产时序库做更多的研究与学习。

企业简介

搜狐公司是中国著名的的综合性互联网企业,主要业务领域包括新媒体、通信以及移动增值服务,集成了娱乐中心、体育中心、时尚文化中心等多重角色。

作者介绍

武朋,搜狐智能平台高级开发工程师。

目录
相关文章
|
3月前
|
存储 NoSQL 数据处理
【MongoDB大神级操作】揭秘聚合框架,让你的数据处理能力瞬间飙升,秒变数据界的超级英雄!
【8月更文挑战第24天】MongoDB是一款备受欢迎的非关系型数据库,以其灵活的文档模型和出色的可扩展性著称。其聚合框架尤其亮眼,能高效地对数据库中的数据执行复杂的转换与聚合操作,无需将数据导出到应用端处理,极大提升了数据处理的效率与灵活性。例如,在一个大型电商数据库中,聚合框架能轻松分析出最热卖的商品或特定时段内某类别商品的销售总额。通过一系列管道操作,如$unwind、$group等,可以对数据进行逐步处理并得到最终结果,同时还支持过滤、排序、分页等多种操作,极大地丰富了数据处理的能力,成为进行数据分析、报表生成及复杂业务逻辑实现的强大工具。
75 2
|
6月前
|
OLAP 数据处理 Apache
众安保险 CDP 平台:借助阿里云数据库 SelectDB 版内核 Apache Doris 打破数据孤岛,人群圈选提速4倍
众安保险在CDP(Customer Data Platform,客户数据平台)建设中,通过引入阿里云数据库SelectDB版内核Apache Doris,成功打破了数据孤岛,并显著提升了人群圈选的速度
280 1
|
存储 弹性计算 运维
互娱NoSQL架构优化 —— 暨MongoDB“在线换引擎”技术服务指南”
XX工作室是某大客户核心游戏工作室,其核心业务是国内二次元RPG手游,采用实时开放世界对战模式,整体采用阿里云方案,本次专项攻坚主要对于玩家在游戏期间各类游戏属性交互(包含过图、物品、面板、剧情等)的核心业务模块进行优化,其中涉及NoSQL部分由于在专项优化期间存在诸多细节,特此提炼出来给各位有类似互娱业务场景进行参考。
|
SQL 关系型数据库 MySQL
线上千万级大表排序:优化攻略揭秘,轻松应对海量数据!
前段时间应急群有客服反馈,会员管理功能无法按到店时间、到店次数、消费金额 进行排序。经过排查发现是Sql执行效率低,并且索引效率低下。遇到这样的情况我们该如何处理呢?今天我们聊一聊Mysql大表查询优化。
线上千万级大表排序:优化攻略揭秘,轻松应对海量数据!
|
canal 中间件 Java
阿里终面:业务主表读写缓慢如何优化?
阿里终面:业务主表读写缓慢如何优化?
|
SQL 人工智能 NoSQL
持续九年,国际排名第一的宽表数据库概述|学习笔记
快速学习持续九年,国际排名第一的宽表数据库概述
176 0
持续九年,国际排名第一的宽表数据库概述|学习笔记
|
存储 SQL 缓存
我是如何一步步让公司的MySQL支撑亿级流量的(上)
我是如何一步步让公司的MySQL支撑亿级流量的
225 0
我是如何一步步让公司的MySQL支撑亿级流量的(上)
|
SQL 存储 Oracle
杨传辉:深挖 OceanBase 背后的技术逻辑,助力数据库核心系统升级
数据库是信息社会的基础设施,通过开放开源助力数据库技术的快速发展,构建新一代数据基础设施是大势所趋!在“2021云栖大会 . OceanBase 原生分布式数据库论坛” 上,OceanBase CTO 杨传辉为大家带来了一场主题为《OceanBase 一体化架构助力核心系统升级》的演讲。
242 0
杨传辉:深挖 OceanBase 背后的技术逻辑,助力数据库核心系统升级
|
SQL 运维 分布式计算
阿里云数据库助力完美日记深度优化数据库架构应对半年内50倍的流量增长
业务/技术亮点:高峰业务流量比半年前提高了50倍;比半年前的系统吞吐提升了50倍
3249 0
阿里云数据库助力完美日记深度优化数据库架构应对半年内50倍的流量增长
|
SQL 存储 运维
我是如何一步步让公司的MySQL支撑亿级流量的(下)
我是如何一步步让公司的MySQL支撑亿级流量的
141 0