从分钟级到秒级响应：如何让10亿级行情数据在OceanBase上飞起来

来源：市场资讯

（来源：科技投行国联民生发布）

想象一个不断扩建的档案馆。

每天都有大量新档案归档入库，从最初的几间库房，慢慢扩展到几十间、上百间。查最近几个月的档案很方便，但如果要找几年前的某份资料，就得在一排排密集的档案架间来回穿行，耗时很久。

这和我们面对的行情数据存储问题很像。

在证券行业，行情数据就是交易链路的"生命线"。这条线要是堵了，投研做不了回测，交易看不了历史。

尤其是固收市场，情况更复杂——数据来源五花八门，交易所、银行间、经纪商……

而且每个渠道的格式都不一样，上游还三天两头改字段。

系统既要扛得住盘中每秒几千笔的写入洪峰，又得灵活得能随时加新字段，还得在查询的时候快如闪电。

随着业务越做越大，这套基于MySQL的老架构，终于还是扛不住了。

深分页查询要等数分钟，给亿级大表加个字段要锁表6小时，历史数据最多存两年就得清……

这些问题像一座座大山，压得我们喘不过气。

于是我们做了一个决定：把行情数据从MySQL迁到OceanBase。

结果怎么样？

历史数据在线存储从2年直接拉升到三十年，单表能扛十亿级数据量，深分页从数分钟降到秒级，存储空间只有原来的十分之一，给大表加字段从数小时变成秒级完成还不锁表。

今天这篇文章，就来聊聊我们这大半年踩过的坑、摸出来的路

不吹不黑，全是实战。

01

MySQL是怎么"扛不住"的？

先说结论：MySQL不是不好，它是真的"长大了就装不下了"。

业务刚起步的时候，MySQL确实好用——

生态成熟，索引机制完善，查个最近半年的数据，毫秒级响应，美滋滋。

但数据量从千万级涨到亿级、再往十亿级冲的时候，问题就一个接一个冒出来了，每一个都能让人头大：

第一个坑：存储的"膨胀焦虑"

我们做过POC测算，光是某一类数据，30年期模拟下来就有数十亿条。

用MySQL存，纯数据占数百GB，加上索引单机磁盘直接爆，压缩比还低，存得越多越心疼。

第二个坑：深分页的"百秒噩梦"

这是最致命的。

当你要查某只证券的深度历史数据，比如执行大偏移量分页查询，MySQL直接给你跑数百秒。

对实时性要求极高的交易业务来说，这跟断网没区别。

第三个坑：开盘收盘的"写入堵车"

行情流量有明显的洪峰——早上9点开盘、下午4点半收盘前后，TPM（每分钟事务数）峰值能达到数千。

这时候MySQL磁盘I/O直接堵死，接收端丢包风险蹭蹭往上涨，看着监控曲线让人手心冒汗。

第四个坑：简单查询也有"延迟毛刺"

就算不是深分页，普通的时间范围查询，随着数据量增长，也会从毫秒级慢慢恶化到秒级。

比如查某只债券过去一年的逐笔报价，MySQL要扫一堆无效索引页，平均8秒才出结果，投研同事用一次吐槽一次。

第五个坑：大表加字段，加一次"疼"一次

给一张亿级数据的MySQL表加个字段，要多久？

答案是6个小时。

而且MySQL对单表字段总大小有硬限制（65535字节），业务字段稍微多一点，直接给你弹出"字段加不上"的报错。

第六个坑：扩容？只能手动分库分表

MySQL单机架构就那么大磁盘、那么大内存，数据超了怎么办？

只能上分库分表中间件。

但这玩意儿对业务侵入大，事务处理复杂，每次扩容都得折腾数据迁移，想想都头大。

这六个问题像六座大山，压得我们意识到：是时候换个活法了。

02

为什么最终选了OceanBase？

选型那段时间，我们把市面上主流的分布式数据库都拉出来遛了一遍。

比来比去，OceanBase的几个特点正好戳中了我们的痛点：

1

金融级底座+LSM-Tree引擎

天生适合行情写入

行情数据最大的特点是什么？

盘中高并发顺序写入。

OceanBase用的LSM-Tree架构，天然把随机写转成顺序写，跟我们的业务场景简直是天作之合。

再加上海量数据压缩算法能做到10:1甚至更高的压缩比，真正实现"存得下、存得省"。

2

MySQL生态高度兼容

迁移成本低

这一点太重要了。

我们整个交易系统有几十个服务，如果换个数据库要把业务代码全部重写，那工程量想想就绝望。

OceanBase高度兼容MySQL语法和协议，业务层代码几乎不用改，开发团队无缝切换。

这也是我们最终下定决心的关键因素之一。

3

HTAP一体化

TP和AP一套搞定

行情中心是什么场景？

盘中要处理实时分页查询（这是TP负载），盘后要跑统计分析、生成报表（这是AP负载）。

过去我们要在关系数据库和数据仓库之间折腾复杂的ETL同步。

现在OceanBase行存列存混合，一套架构全搞定，省心。

4

原生分布式

扩容只需加机器

OceanBase支持按需水平扩展，存储空间和计算能力都能线性提升。

未来数据量再涨，加几个节点就行，业务代码零改造。

再也不用像MySQL时代那样手动分库分表、迁数据，想想都爽。

5

多副本高可用

金融级可靠性

金融场景是什么要求？

RPO=0（数据不丢），RTO<30秒（故障快速切换）。

OceanBase用Paxos协议做多副本同步，任意节点挂了数据不丢、服务快速切换。

这比MySQL主从方案在故障切换时可能丢数据、延迟高靠谱多了。

6

在线DDL

加字段再也不用等周末

这也是个让我们热泪盈眶的特性。

OceanBase执行DDL不需要物理重写整张表，只更新元数据，几乎都是秒级完成，还不阻塞DML操作。

以前在MySQL上给亿级大宽表加字段，得锁表数小时甚至怕业务停摆，只能挑周末凌晨偷偷改。

现在呢？

服务上线前几分钟就能加完新字段，实时变更，再也不用熬夜做变更了。

03

数据说话：长期数据量下的性能对决

光说不练假把式。

为了确保对比真实公正，我们拿某市场行情表做基准：

这张表每天增量约数十万条，列数约数百列，模拟了长期的数据规模（大概数十亿条记录），在同等硬件条件下给MySQL和OceanBase做了压测。

结果怎么样？直接看数据：

分页查询场景下，OceanBase优势可以说是碾压级的。

这主要归功于OB的时间分区设计——把单个分区的数据规模降下来，查询时不用扫全表，检索范围小了，速度自然就上去了。

再看存储效能：

实测下来，OceanBase的空间占用只有MySQL的约十分之一。

如果再结合列存特性，尤其是处理那些有大量枚举值的字段时，压缩率还能更高——这对OLAP场景不要太友好。

这个特性从根本上解决了我们的历史痛点。

过去我们最多只能存1年左右的历史行情，还得频繁清理、迁移数据来保系统稳定。

迁到OB之后，这些运维负担直接烟消云散。

在现在存储硬件这么贵的大背景下，这一笔省下来的IT基础设施费用，相当可观。

04

六条实战经验：让性能真正落地

选型选得好，只是成功了一半。

数据库决定了性能上限，但表结构设计决定了你能不能摸到这个上限。

这大半年我们踩了不少坑，也沉淀了六条核心建议，全是干货：

1

分区策略：

按时间分区是"必选项"

行情数据强依赖时间维度——做策略回测的用户，一查就是连续时间段。

所以我们建议用 RANGE按时间分区。

这样做的好处是分区裁剪，查询I/O大幅减少。

哪怕历史数据涨到天上去，单次查询也只扫千万级的小分区，性能一直稳。

如果数据量特别大，单日写入集中可能导致分片瓶颈和抖动，那就升级成"时间+哈希"的二级分区，把写入流量均匀分散到多个节点，稳上加稳。

2

主键设计：

在"代码"和"时间"之间找平衡

行情查询最常用的模式是什么？

查某几只证券的历史序列。

所以我们建议用(证券, 时间戳) 再加上其他能确保唯一性的字段做复合主键——

既满足唯一性约束，又能加速"按券按时间"的检索，一举两得。

3

索引设计：

少而精，别贪多

很多人觉得索引越多越快，其实不然。

行情明细表的索引，多一个，盘中写入时就要多维护一个，对实时吞吐量反而不友好。

我们的做法是：

保留一个单独的时间索引，用来做全市场行情回放和数据问题排查；其他业务字段，如果查询效率确实低而且经常被用来筛选，再经过评审沟通后加索引。

克制，是索引设计的美德。

4

善用表组：

让JOIN查询飞起来

行情数据表经常要跟基础信息表做JOIN关联查询。

这时候可以把这些相关表放到同一个TableGroup里——

保证关联表的分区在物理上落在同一个节点，跨机器网络传输的开销直接省了，复杂查询性能大幅提升。

这个小技巧，用过的都说好。

5

写入优化：

批量插入代替单条写

面对海量行情写入，千万不要一条条插。

务必在应用侧把单条写改成批量处理，这样能大幅减少应用和数据库之间的网络交互次数。

网络和I/O开销降下来了，写入响应时间的毛刺也就消失了。

这个优化看似简单，效果立竿见影。

6

查询优化：

重查询用Parallel并行

对于全表扫描、大表聚合统计这类OLAP重查询，可以在SQL里用并行Hint指定合适的并行度。

充分利用集群的多核计算资源，原来要跑几分钟的复杂报表查询，直接缩短到秒级。

工欲善其事，必先利其器。

深耕行情数据治理这么多年，我们没少被各种技术痛点折磨。数据膨胀拖垮查询效率，存储受限逼得我们频繁归档，想给宽表加个字段更是如履薄冰。

OceanBase的引入，让这些痛点绝大多数都烟消云散了。

这里必须再夸一句MySQL协议高度兼容这个特性。它极大降低了迁移门槛，让我们几十个交易服务在半年内就完成了平滑过渡。要是换个其他数据库，要在这么短时间内完成同等规模的改造，几乎是不可能完成的任务。

回想这大半年的迁移历程，从最开始的选型评估、POC压测，到表结构设计、性能调优，再到最后几十个服务平滑上线、稳定运行，整个团队最大的感受就是：

选对了工具，真的能少走很多弯路。

这次数据库转型，不仅解决了眼前的性能瓶颈和存储焦虑，更重要的是为我们未来数十年的业务扩展筑牢了数据基座。

十亿级数据量、数十年在线存储、秒级查询响应——这些曾经想都不敢想的目标，现在成了我们系统的日常。

技术演进永远在路上。但至少在行情数据存储这件事上，我们终于可以睡个安稳觉了。

*免责声明：以上内容是基于本公司认为较为可靠的已公开信息整理而成。国联民生证券在整理过程中力求确保内容的准确性与完整性，但无法完全保证其毫无差错并涵盖所有最新变更情况。本内容仅供参考，并非国联民生证券提供的投资建议，也不构成任何收益承诺，亦不代表对任何观点的认可。投资者不应以该内容取代自身独立判断能力，应根据自身风险承受能力审慎自主决策，市场有风险，投资需谨慎。本内容版权归国联民生证券所有。