兄弟们，最近是不是都被信创这事儿折腾得不轻？上面一句话，下面跑断腿，尤其是数据库选型这一关，真特么愁人。前两天有个老同事找我，说他们单位要上信创云平台，业务系统里OLAP（就是那种复杂查询、出报表、做分析）的活儿不少，现在卡在TiDB和OceanBase这俩国产大牛身上，不知道选谁。
这问题问到我心坎里了，正好前几天帮一个做零售的客户搞过压测，有点实战心得，今天就着这杯枸杞茶，跟大伙儿掏心窝子聊聊。
先说个感悟，别被“性能参数”忽悠瘸了
很多哥们儿一上来就看什么TPCC、TPCH跑分，兄弟，那玩意儿就像看相亲对象PS过的照片，参考价值有，但容易见光死。真到咱们生产环境，一个烂SQL就能把数据库干趴下。 所以咱得看“实战表现”，特别是架构设计上，这俩路子真不一样。
打个比方吧，TiDB更像一个“分库分表侠”，把数据切得碎碎地平铺在好多台机器上，然后有个“调度中心”（PD）在那儿管着，谁闲谁干，扩展性那叫一个丝滑，加机器就跟加方便面一样简单。OceanBase更像一个“一条龙服务团队”，数据有主有备，内部搞了个Paxos选举，自己跟自己玩得可嗨了，强调的是一份数据多副本，强一致，主打一个稳如老狗。
真实OLAP场景，差距就出来了
回到老同事那个零售客户，典型OLAP场景一般就这三种，咱一个一个唠：
场景一：大宽表JOIN（跑批） 这活儿就像是让一个厨师处理一筐子土豆，得削皮、切丝、过水。TiDB在处理这种大表关联（JOIN）特别猛的查询时，如果内存不够，会像咱用老旧笔记本跑PS，硬盘唰唰响，落到磁盘上“溢出”了，速度一下就拉了。而OceanBase在这方面明显老道一些，它那个并行执行（Parallel Execution）优化得挺猛，像一个大厨带一堆帮厨，切菜的切菜，焯水的焯水，分分钟搞定。
结果： 我那客户原来上Oracle跑一个多小时的一个批量经营分析报表，OceanBase压测大概15分钟就出结果了。TiDB不是不行，是同样资源下，它跑这种复杂JOIN，稳定性稍微差点意思。这块OceanBase赢了，赢得还挺明显。
场景二：多维度实时汇总（即席查询） 比方说运营想看“昨天华东区卖得最好的前十款SKU”，这种查询得实时算，还不能慢。TiDB的强项这时候就出来了，它那个架构天生适合这种，因为数据是打散的，并行查起来飞快，响应时间像开了挂。
OceanBase呢，为了保证数据一致性和高可用，写操作过Paxos协议会有那么点网络开销，在这种“点一下看个报告”的高并发查询场景，感觉有点端着架子，反应没TiDB那么“愣头青”式的快。
结果： 我们模拟了50个运营同时乱点查询，TiDB的响应时间曲线更平顺，OceanBase偶尔会有个尖峰。这局算TiDB小胜。
场景三：数据量特别大，但要查的只是其中一小撮（过滤性强） 比如从十亿行订单流水里，按订单号查一条出来。这种“大海捞针”的活儿，考验的是索引和存储引擎的功底。这俩都能干，但OceanBase因为是LSM-Tree的存储结构，有时候在精确点查上，那种“一杆子捅到底”的爽快感，不如TiDB来得直接。
到底咋选？给你个土办法
老铁，看到这儿，你要是还问我买哪个，那我得敲你脑壳了。别想着一个库打天下。
- 如果你的OLAP报表是那种固定套路的，比如管理层看的月度经营分析、财务对账，复杂SQL多，每天就那么几个时间点跑，OceanBase会更让你省心。
- 如果你的分析是面向业务人员自助式的，大家随便拖拽拽，SQL千奇百怪，而且还得兼顾着在线交易（OLTP），老想用一套库解决所有事，那TiDB的生态和兼容性（特别是MySQL协议这块）会让你少掉几根头发。
说句掏心窝子的话，咱们干IT的，最怕的不是技术难，是选了技术后天天背锅。当年没日没夜翻文档、追源码的劲儿，现在全用来研究这俩数据库的“脾气”了。
这俩库现在都在飞速迭代，可能隔了俩月，别人修补了短板就又不一样了。具体到你那套业务系统到底吃哪套，还得靠真实的压测数据说话，别听厂商销售在那瞎忽悠。
好了不早了，我还得去盯着数据迁移的活儿。如果兄弟你也在为信创选型挠头，想看看别人是怎么趟过这些坑的，更多方案可以去 itfangan.com 遛遛，里面有不少真实落地方案，指不定就能救你一把。散会！