来源：市场资讯
（来源：科技投行国联民生发布）
想象一个不断扩建的档案馆。
每天都有大量新档案归档入库，从最初的几间库房，慢慢扩展到几十间、上百间。查最近几个月的档案很方便，但如果要找几年前的某份资料，就得在一排排密集的档案架间来回穿行，耗时很久。
这和我们面对的行情数据存储问题很像。
在证券行业，行情数据就是交易链路的"生命线"。这条线要是堵了，投研做不了回测，交易看不了历史。
尤其是固收市场，情况更复杂——数据来源五花八门，交易所、银行间、经纪商……
而且每个渠道的格式都不一样，上游还三天两头改字段。
系统既要扛得住盘中每秒几千笔的写入洪峰，又得灵活得能随时加新字段，还得在查询的时候快如闪电。
随着业务越做越大，这套基于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压测，到表结构设计、性能调优，再到最后几十个服务平滑上线、稳定运行，整个团队最大的感受就是：
选对了工具，真的能少走很多弯路。
这次数据库转型，不仅解决了眼前的性能瓶颈和存储焦虑，更重要的是为我们未来数十年的业务扩展筑牢了数据基座。
十亿级数据量、数十年在线存储、秒级查询响应——这些曾经想都不敢想的目标，现在成了我们系统的日常。
技术演进永远在路上。但至少在行情数据存储这件事上，我们终于可以睡个安稳觉了。
*免责声明：以上内容是基于本公司认为较为可靠的已公开信息整理而成。国联民生证券在整理过程中力求确保内容的准确性与完整性，但无法完全保证其毫无差错并涵盖所有最新变更情况。本内容仅供参考，并非国联民生证券提供的投资建议，也不构成任何收益承诺，亦不代表对任何观点的认可。投资者不应以该内容取代自身独立判断能力，应根据自身风险承受能力审慎自主决策，市场有风险，投资需谨慎。本内容版权归国联民生证券所有。
热门跟贴