我们如何使用扩展MySQL替代方案更高效地处理数据
工业:移动支付
作者:刘宇(中国电信百汇高级建筑师)
Transcreator:Coco Yi.;编辑器:汤姆德湾
中国电信最好是移动支付和互联网金融子公司中国电信公司.百思汇支持中国超过800万家线下商户和170个电商平台,致力于提供“安全、便捷、时尚”的支付解决方案。2019年,Bestpay拥有5000万月度活跃用户,每月2.3亿笔交易,每年1.75万亿笔交易。
我是Bestpay的高级建筑师。我的同事和我必须不断提高我们软件的效率,以跟上我们公司的快速增长和反应激烈的市场竞争。我们迈出了一个伟大的进步的一个领域是我们的数据库。仔细调查后,我们迁移到TiDB, 一种MySQL-compatible那开源那分布式SQL数据库,这使得BESTPAY申请系统的整体性能提升了3-5次。
在这个博客文章中,我将介绍我们通过TIDB实现的结果,我们克服的困难,我们如何逐步地迁移到TIDB,以及为什么我们将我们的信仰放在TIDB中。
结果
“采用TiDB改变了我们的系统。它不仅帮助我们满足监管规范,而且大大提高了我们财务部门的处理能力和效率。它还降低了技术团队工作的复杂性。”BESTPAY技术基础设施团队
目前,BestPay的应用层和核心平台层都使用TIDB提供服务。以下是我们迁移到TIDB后实现的一些主要结果:
风险控制管理
- 批处理性能提高了3倍以上。
- 反洗钱系统的处理效率提高了5倍。
付款和解
和解平台的性能增加了2次.例如:
- 为了协调银联无力付款,原始MySQL解决方案需要3-5分钟。现在,TIDB只需要1-2分钟。
- 为了协调微信Pay支付,原来的MySQL解决方案花了3分钟。现在,TiDB只需要大约1分钟。
个人账单
用户体验和活动都得到了改善。TiDB解决了之前MySQL分片解决方案带来的问题,主要包括:
- 数据库容量:现在,TiDB中的一张表就有近100亿行。在以前的MyCAT中,单个表最多可以有1亿行,一个大表必须每个月拆分。
- 数据存储持续时间:通过TIDB的水平可扩展性,可以存储3-5年或更长时间的数据。当我们使用MySQL时,数据只能存储半年。
- 查询效率:每秒查询(QP)增加50%,延迟下降20%-30%。
现在你有一个基本的想法我们的立场。然而,实现卓越从未如此顺畅的帆船。我们希望了解我们的困难以及我们如何克服他们会在您自己的工作中激励您。
困难
根据政府的规定,可疑模式和风险等级的计算必须在付款后的第二天完成。这一要求对系统的处理时间提出了挑战。
以前,批处理任务将需要7-8小时,而整体任务将每天持续15小时或更长时间。作为数据卷浪涌,我们的应用系统具有更大的缺少性能目标的风险。
我们必须快速优化数据库以满足2003年SQL标准,并实现以下性能要求:
任务 | 所需的完成时间 |
---|---|
连接多个表,并在结果集中查询少于1000万行的数据。 | < = 5秒 |
批量加载数据文件。 | < = 30分钟 (例:总计20 GB) |
从数百万行中删除500,000行。 | <= 10秒 |
从3亿行中删除2000万行。 | <= 10秒 |
在3亿行中更新100万行。 | <= 5分钟 |
除了出色的性能之外,我们希望我们的数据库规模缩放通过功能,可扩展性,稳定性和可用性支持未来的业务增长.
迁移策略
经过与TiDB团队的深入讨论,我们制定了以下三步迁移策略:
- 评估我们的应用场景,提出具体的数据库迁移方法。
- 在小范围内试用这种方法。
- 进一步到核心平台。
建模
经过全面的测试和评估,我们决定使用关系数据库的新项目选择三个解决方案 - 内部关系数据库服务(RDS),分片 - 球(S-S)和TIDB。我们构建了一个评估模型,用于何时使用每个解决方案的准则:
解决方案 | 容量 | QPS. | 大桌子 | 分片 | HTAP支持 | 拓扑结构 |
---|---|---|---|---|---|---|
rds. | < 3结核病 | < 20000 | < 10 | N/A | 没有 | 一个来源,一个副本 |
S-S. | 3 - 10结核病 | > 20000 | < 20 | 按日期/散列 | 没有 | 多个来源,多副本 |
TiDB | > 3结核病 | > 20000 | > = 20 | N/A | 是的 | 弹性缩放 |
该模型基于几维容量阈值,性能阈值(QPS),大表数,分片规则,HTAP功能和拓扑。
TIDB是首选当:
- 数据量大于3 TB。
- QPS预计将超过20000人。
- 有20多张大桌子。
- 分片规则很难定义。
- 处理事务和分析查询都是处理的。
试点
BestPay应用程序客户端包括个人计费系统。它允许用户管理,查询,分类和显示其事务的统计信息。
根据评估模型,个人结算系统落入TIDB类别,因此我们将其用作试点项目。
然后我们制定了应用程序数据库迁移原则:
- 同时将应用程序数据写入旧数据库和并行运行的新数据库,并逐渐将流量切换到新的。
- 数据不得丢失或错误。
- 验证完成后,需要将敏感服务快速切换到新数据库。
- 在迁移期间,可以随时切换到旧数据库。
- 需要合并一些分片表和分区表。
以下原则,我们使用了TIDB的数据迁移工具在短时间内执行迁移任务。
授权
在试点成功后,我们继续探索,选择TiDB为我们的两个核心系统——和解平台系统和反洗钱系统提供支持。
协调平台系统涉及多个大表,每个表都超过10亿行。数据总量超过8tb。应用程序逻辑相对复杂,数据并发性适中。
迁移后,核心支付系统接收用户事务并将其作为文件发送到文件分析程序。该程序将分析结果保存到TIDB数据库。调和平台从TIDB读取数据以完成对帐进程,并为Web界面提供查询服务。
对于反洗钱系统来说,监测数据的数量和类型都迅速增加。迁移完成后,通过Oracle GoldenGate (OGG) for MySQL客户端将数据从原始Oracle数据库复制到TiDB;大数据平台上的其他数据通过大数据发布功能直接从Hive复制到TiDB。
我们为什么选择TiDB
“TIDB团队了解我们的核心业务,我们对他们设计和改进分布式数据库架构的能力印象深刻。”BESTPAY技术基础设施团队
对于支付服务提供商来说,风险控制是重中之重。在此之上,我们必须适应业务开发和不断发展的应用程序场景,并为未来制定计划。这种心态促使我们采用可伸缩、灵活的架构设计,追求更高的数据处理效率。
我们和TiDB团队一起克服了许多困难,毫无疑问,他们值得我们的信任!
接下来是什么
Bestpay将把更大规模和快速增长的核心系统迁移到TiDB。这些核心系统数据库有数亿行,单个数据库存储的数据超过10tb。核心业务必须有最少或零停机时间,这对数据库提出了更高的要求。
但我们相信TIDB的能力,我们有信心和动力做得很好。