作者： TiDBer_小黑羊
最近，看到一个国有大银行的数据库案例，狠狠刷新了我的认知↓
三个“国外顶流数据库”没搞定的系统，竟然被一家国产数据库厂商拿下了。
可以说，这一次，国产数据库不仅打了翻身仗，还攀上了一个前所未有的高峰。
这事儿有多“离谱”？听我给你捋捋↓
一、500TB数据，让三大顶流数据库集体躺平~
这是一个国有大行的真实案例，该银行总行核心领域多个系统有跨度长达10余年的联机交易数据。
先来看看这个让人头疼的架构图吧，涉及了大量数据应用和数据服务系统，三大国际顶流数据库、数仓工具共同撑着这摊子事儿。
这些联机交易数据有多少呢？
总容量超过500TB！存储在Oracle、MongoDB、Hive等多个数据库/数仓里。
这里面包括了个人/企业在该银行过去10年的存取款信息、交易流水，作为总行，你想象一下所有储户10多年的历史交易记录，有多大。
这些数据支撑着多个关键渠道类系统多维度交易信息查询、实时收支分析等重要系统，属于该银行核心交易领域服务属性最强、服务类型最综合的业务。
举个大家都懂的例子：比如你要查自己过去5年的银行存款流水↓
听起来很简单是吧，结果你会发现，大部分银行都不支持这个超长流水的实时查询。我刚试了另一家国有大银行，只能查询最近两年的流水，而且一次查询的跨度不超过3个月。
为啥，因为历史数据量太大了，后台数据库没法支持如此长周期、大跨度的数据访问。
即便是这家用了三大顶流产品的大行，反复折腾，也没法达到让人满意的结果：最大数据访问周期只能小于5年，数据跨度不能超过1年，有的业务甚至半年。
“三大数据库”都躺平了？是的！
我们拿这里面最能打的“O记”为例，作为业界顶流的集中式数据库，单机实力爆棚，可以轻松驾驭数十TB甚至百TB级别结构化数据（比如绝大数核心交易场景）。
可是，数据量像现在这样达到500多TB，这就有点超过了O记数据库的舒适区（当然人家也不是不能干，比如你砸个离谱的大价钱扛个顶配的Exadata X10M回来，没准儿也能搞定）。
这种极端场景，海量“联机+离线”数据，希望做到实时分析、检索，又不想付出贵到离谱的成本代价，基本上就是无解。
比如在这个项目里，O记数据库不可谓不努力：为了避免特大表对性能的影响，搞了大量“分表”动作。
把每半年的数据分一张表，搞出几十张表，不仅增加了系统复杂度，也直接限制了查询跨度（最大6个月）。
一顿操作猛如虎，但这些数据却始终没能盘活。
久而久之，这摊数据和相关应用，就变成了医不好的「死马」……
二、国际顶流都扛不住，国产数据库凭啥顶这个雷？
一直这样“摆烂”？不可能！因为这些数据和上层的业务都太重要了。
于是，今年年初，这家大银行抱着“死马当成活马医”的心态，再次进行攻坚。
他们评估了市面上各类热门的数据库解决方案：MySQL系的、PG系的、全自研的、集中式的、分布式的、号称O记平替的…
最终，经过反复对比验证，这家国有大行选择了TiDB数据库。
我们先说结果吧，TiDB成功把“死马”医成了“活马”，搞定了这件事。
那么，TiDB具体是如何搞定的呢？
我们先来草绘一下改造后的架构，是不是比之前简洁了很多？
- **数据汇聚：**TiDB具备弹性扩展与高并发写入能力，支持基于消息中间件的实时汇聚和文件交换的离线加载，覆盖各种数据源。
- **数据加工：**流批一体，流式计算基于TiDB的动态数据路由、原生分布式能力，与上层应用解耦；离线就计算基于TiDB的行列混合、MPP能力，日均百GB增量数据快速导入，数十亿级数据聚合分析。
- **数据服务：**利用TiDB的多维度数据访问能力，提供不同维度、灵活条件的高并发T+0数据查询、分析、推送和数据下发服务。
- **数据存储：**基于TiDB/TiKV实现数据统一存储、冷热分离，加固性能与SLA，优化成本。
这个新架构最大的改变，就是用TiDB实现了“一换三”，原来的“三大国际顶流”统统不见了。
整个数据服务层化繁为简，推倒了“数据烟囱”，提供一栈式综合服务，支撑各类数据应用。
就这么简单？不，只能说TiDB的填坑能力太强，从一开始就切中了这类极端场景的两大关键点。
关键点一：HTAP ，混合事务/分析处理
因为银行里这些数据不只是陈年老记录，每天还要摄入海量的新交易数据。
要支撑海量的新数据摄入，同时还要实时分析处理，从而做出即时且正确的决策…，传统数仓干不了，传统数据库也扛不住。
比如，大型银行需要在处理高并发交易事务的同时，检测出异常的欺诈交易。
这样的场景，就必须要靠HTAP，也就是一站式架构混合支持实时交易和实时分析，让鱼和熊掌兼得。
而TiDB恰恰是HTAP架构数据库领域的标杆产品，所以应对这样的场景更加得心应手。
关键点二：原生分布式数据库
这家大行现有的500TB数据量已经很夸张了，但未来日复一日年复一年数据会越来越多。
如果按照传统集中式数据库的思路，即便当下能扛住，未来也得趴窝。
因此，必须考虑分布式架构数据库↓
但是呢，分布式也有技术路线之分。
有些“分布式数据库”需要依赖分库分表中间件或者数据访问代理，事务处理、高可用能力都受限。
而且，分库分表的操作基于算法提供，无法真正自动扩容，需要人工干预。更要命的是，上层应用还要进行大量改造。
而TiDB则是真正的原生分布式数据库，存算分离，数据自动分片，自动弹性扩容，对上层应用零侵入。
这上下游还涉及几十个业务系统呢，如果要改造应用，那工作量可就太大了。
“HTAP+原生分布式”，新架构中的四个层，每一层都是靠这两大绝技摆平的。
也正是凭借这两大绝技，TiDB成功实现“一换三”，彻底将数据盘活！
三、“一换三”之后，效果到底怎么样？
以前经常看到一些江湖上“平替”的案例，谈起体验“酸爽”，大甲方们只能笑而不语。。
但TiDB这个“一换三”替代，没有酸，只有爽，效果简直炸裂↓
1、对接业务规模▼
TiDB撑起的这套「一栈式综合数据服务平台」，总共对接了上下游近百个业务系统，数据覆盖全行近 230 个业务产品，超过3000个交易场景。
2、系统资源规模▼
系统集群资源约 2,700+应用虚拟节点（承载上下游业务应用），300+数据库物理节点（承载数据）。
集群规模可以按需扩展。
3、数据容量规模▼
原来500TB的单副本存量数据全部迁移到新系统，新系统采用可靠性更高的多副本设计，总数据规模达到PB级。
其中，最大数据表记录条目超过千亿行。
4、查询与分析体验▼
新系统能够支撑超10年的永久查询和单次跨度5年的大范围查询及实时分析，交易数据完整性、准确性更高，数据统计口径更为统一，更炸裂的数据看下面。
- 日均接收和加工亿级增量数据，联机写入TPS约10000，日均通知推送约3.5亿笔，核心加工链路耗时控制在5秒内；
- 日均联机查询交易量超千万笔，峰值QPS超50000，应用侧平均响应耗时在100ms内；
- 日均加载上千个批量文本，最大离线分析规模为基于40亿行原始明细产生约4亿行指标结果数据，并为多个下游系统提供数据下传和推送服务，包括反洗钱、有权机关等监管类场景。
5、金融级高可用▼
改造后的系统，采用两地三中心高可用架构，应用同城双活，双机房同时具备读写能力，确保了金融级生产系统的业务连续性。
在吞吐能力、弹性伸缩能力、部署密度、资源使用率方面都获得较大提升，实现了灵活高效的资源调配和精细化的降本增效。
当然，还有绝对不能忽略一条↓
该大行通过采用TiDB方案，成功完成了这组核心系统的「国产化替代」。
至此，我们终于可以说：
这座数据库应用的“珠穆朗玛峰”，TiDB成功登顶了！
四、这些年，TiDB爬过的那些山…
然而，你知道吗？TiDB可是个超级登山选手。
人家不光会爬“珠穆朗玛峰”，这些年，国内的、国外的，各种“山头险峰”，TiDB都爬完了。
我们就拿对数据库要求最苛刻的“国内金融山头”来举例吧↓
国内各大银行、保险、券商，到处都可以看到TiDB的足迹。
比如，今年4月，PingCAP(平凯星辰)中标建设银行国产数据库小机下移项目。
这些年来，TiDB成功应用于建设银行、浦发银行、北京银行、浙商银行、杭州银行、广发银行、中国人寿财险、平安科技、微众银行等多家金融企业的核心业务场景。
而平安集团旗下的平安科技，更是基于TiDB打造了平安自己的信创发行版数据库UbiSQL，为生态内的企业赋能。
接下来，再看看国外那些“顶流山头”↓
从Databricks到Pinterest，从Bolt到Shopee，从CAPCOM到Line…，TiDB经受住了全球3000多家行业客户海量数据严苛场景的考验。
正是这些实战攀登经验，让TiDB如今在国内金融行业的极限挑战面前，可以举重若轻，最终成功登顶！
放眼业界，TiDB可能是唯一个既服务国有大行也服务全球顶级互联网大厂的数据库产品，TiDB 8年多坚持的自主开源路线，也是它的产品得到信任保持持续领先的法宝。
TiDB与PingCAP的攀登之路，还在继续…
在其身后，是一系列闪光的足印：TiDB项目在GitHub上获得超过35000颗星；TiDB被超过3000家企业用于生产环境；服务客户超过20个国家…
TiDB的“爬山”路上，还有很多标志性的事件。
比如，我刚刚看到了TiDB助力杭州银行全国产核心系统上线的消息，这可能是国内第一家城商行在核心系统采用「全国产微服务+原生分布式架构」的案例，绝对具有里程碑的意义。
雄关漫道，没有比脚更长的路，没有比人更高的山…
标签：一换,数据库,系统,查询,TiDB,数据,分布式 From： https://blog.51cto.com/tidb/9063254