MySQL 的分库分表维护成本较高,对业务的限制也比较多。而 TiDB 的分布式架构无需分库分表,大大简化技术栈,降低了运维难度,通过在线水平扩展有效解决底层数据存储扩容难题;TiDB 的金融级高可用特性,可靠的灾备、数据恢复方案保障业务稳定运行;TiDB 高度兼容 MySQL,有着成熟的 MySQL 迁移方案,研发侧大部分代码无需改动,即可顺利完成整个迁移工作。
本文分享了 TiDB 在老虎国际、中国 SaaS 行业头部服务商、京东云的实践案例,充分展现了 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度的绝对优势。
老虎国际 x TiDB丨降低架构复杂性,保障全球用户安全可靠投资
导读
券商是一个古老的行业,发展至今已经历了三个时代:第一代券商为传统券商,在线下交易大厅进行买卖;第二代券商开始了电子化进程,从线下到线上进行了浅层服务的转移,改善了用户体验,提高了金融服务的效率;第三代券商更多强调“科技赋能”,在功能业务上更创新、更多样,且存在完整的互联网基因,业务依靠线上平台,拥有底层自研能力,如交易、风控等系统。
老虎国际作为第三代券商的代表,是一家全球知名的国际化券商,在新加坡、美国、中国香港、澳大利亚等地持有 59 张牌照或资质,在全球多地开展业务。投资者在老虎国际可通过一个账户交易美股、港股、A 股(沪港通/深港通)、星股(新加坡股)、澳股(澳大利亚股)、期货、基金等全球主要市场的金融产品,享受一流的投资体验。
01
业务挑战
作为一家全球化的券商,每个国家证券行业发展情况不同,数据合规要求也存在差异,比如新加坡有 PDPA,欧盟有 GDPR,美国有 CCPA 等,甚至不同国家业务特点也大为迥异。在每个国家/地区都本地部署业务系统显然并不现实,老虎国际采用跨地区的混合云架构为全球用户提供支撑,解决在数据架构、数据安全、数据合规等方面所面临的的全球挑战。
同时,老虎国际的数据架构复杂度非常高,底层系统包含 Java、Python、Go 等不同的语言,中间件、数据库、大数据等都是异构场景,导致维护成本和研发效能都大打折扣。
此外,在老虎国际证券业务发展过程中,业务波动性是常态,这也使得其核心业务--后台账本系统,经常面临数据库的性能挑战。后台账本是用户在老虎国际参与证券交易时,如产品购买、出入金、IPO 打新、公司行动、被收费等各个业务版块,针对用户行为明细数据记录的系统。账本每天需要记录大量的用户流水,并根据用户行为生成用户每日账单。如果账本出现问题,直接关系到用户体验和投资收入。
2020 年 3 月,美股遭遇了前所未有的震荡,开盘即暴跌,触发一级熔断机制,暂停交易 15 分钟。老虎国际的数据库也经历了前所未有的数据查询量,查询数量曲线呈指数级增长,原有的 MySQL 遇到了极大瓶颈。证券交易还要求数据库具有金融级数据强一致性,并具备灾备能力,一旦某个机房宕机,另一个机房可以立刻启用。
数据安全性、数据可用性和数据架构复杂度成为老虎国际国际化业务的三大挑战。出于对开源技术的信任和认同,老虎国际很早就在数据中台业务中应用了 TiDB 3.0 版本,此后一路升级到 TiDB 5.0,解决了业务挑战与数据安全挑战。
02
后台账本数据库迁移
老虎国际的后台账本底层数据架构由多套集群组成,单集群数据量接近 2TB,MySQL 数据库虽然具有较好的稳定性和负载能力,但为了应对不断增长的数据量只能采取分库分表方案,难以保证跨分片的事务一致性,跨库的 Join 关联查询性能较差,数据库多次扩展难度和维护量极大。2021 年,老虎国际的运维与研发团队对主流的冷热数据分离、分库分表、分布式数据库等方案进行选型与性能压测。在压测中,TiDB 在 P95 延迟、TPS 事务指标、QPS 等方面整体性能都强于 MySQL,并且 TiDB 的性能可以随着节点水平扩展线性提升,解决性能和单机资源瓶颈问题。压测增强了老虎国际技术团队的信心,最终决定将后台账本的 MySQL 集群也迁移到分布式数据库 TiDB 上。
MySQL or TiDB?HTAP 数据库在中国 SaaS 行业头部服务商的应用实践
导读
CRM 并不是简单的销售和客户服务的效率工具。
本质上,CRM 是以平台化思维实现业务管理和数据的打通,为 360 度客户旅程提供数字化支撑。
虽然受到疫情影响,但随着企业数字化转型的不断深化,更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看,平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用,提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。
01
CRM 的数据架构面临重重挑战
某中国企业级 CRM 头部服务商,其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景,帮助企业转型为真正“以客户为中心”的数字化运营组织,实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长,该服务商实现了从中小企业到大中型企业的覆盖,为了应对不同行业用户的个性化需求推出了 PaaS 平台,基于平台的定制能力服务垂直行业的特定需求;同时,该服务商发力 C 端市场,陆续推出 SCRM 等产品连接海量 C 端用户,打造客户旅程的一体化闭环。
同时服务几万家不同规模的企业,打通每家企业各个业务系统的数据,为 360 度客户旅程提供数字化支撑,这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库,考虑到大表性能、租户数据量,采用了元数据、租户分库、租户分表的整体方案,共享库按照租户和实体做水平扩展的分库分表设计。

多租户共享数据库的分库分表设
02
CRM 真实场景下 MySQL 和 TiDB 的比拼
通过与 CRM 服务商技术部门的探讨,由于 SaaS 业务的稳定性、性能都对最终客户至关重要,组织了一次全面的 PoC 验证工作,覆盖了产品的性能,兼顾数据迁移、稳定性、安全性、运维监控等能力。
从业务场景的实测结果可以看到:TiDB 并发处理和查询性能提升明显,千万级以上性能提升 70% 左右,单条、跑批都得到了大幅的性能提升(80% 在毫秒级),原先过长时间查询无返回结果的任务,在 TiDB 中得到好转;各类痛点查询,如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等;TiDB 在添加字段,修改字段,增加索引等 DDL 上优势明显。此外,TiDB 提供高效的同步工具 DM,从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。
TiDB 在京东云丨TiDB SQL 优化最佳实践
导读
京东云与 PingCAP 深度合作,联合推出了一款云上分布式数据库产品,向京东云用户提供云上的 TiDB 服务。它可以同时支持 OLTP 和 OLAP 混合负载场景,实现了自动水平伸缩,强一致性的分布式事务,部署简单,在线异步变更表结构不影响业务。
由于 TiDB 兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态,应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB,使迁移使用成本降到极低。下表从总体上概括了 TiDB 和 MySQL 的兼容策略:

SQL 是 DBA 和广大开发人员操作数据库的主要手段,几乎每天都在使用。那么它是如何工作的?我们又如何让它更高效地工作?本篇文章将详细介绍 TiDB SQL 的架构、优化流程以及最佳实践。
01
TiDB SQL 层架构
用户的 SQL 请求会直接或者通过 Load Balancer 发送到 京东云TiDB Server,TiDB Server 会解析 MySQL Protocol Packet,获取请求内容,对 SQL 进行语法解析和语义分析,制定和优化查询计划,执行查询计划并获取和处理数据。数据全部存储在 TiKV 集群中,所以在这个过程中 TiDB Server 需要和 TiKV 交互,获取数据。最后 TiDB Server 需要将查询结果返回给用户。

02
SQL 优化案例最佳实践
案例一:索引的错误选择导致 SQL 变慢的优化实践
场景:数据库迁移到 TiDB,SQL 在 MySQL 运行不到 1s,在 TiDB 运行超过 30s
SQL 执行计划如下:

execution info 列,有该执行计划的时间,这个 SQL 的表的连接顺序,要从最里面的循环开始看,如下图,m,d 是最先开始进行连接的:

⬇️ 点击下方图片立即试用 TiDB 7.0 ⬇️

更多精彩敬请期待





