TiDB

「我们已经用起来了」 ，是我们最喜欢听到的话，简简单单几个字的背后代表着沉甸甸的信任和托付。从今天开始，我们将通过 「相信开放的力量」 系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。 本篇文章将介绍 TiDB 助力中国电信翼支付金融核心场景的故事。 >餐饮娱乐 、投资理财、商户服务… 让大家尽情享受安全、便捷的金融新生活。 中国电信翼支付（以下简称：翼支付）成立于 2011 年 3 月，是中国电信旗下的运营支付和互联网金融的业务品牌，是中国人民银行核准的第三方支付机构，是中国证监会核准的基金支付结算机构，支持各类线上线下民生支付应用，一直致力于为个人、企业提供“安全、便捷、时尚”的支付解决方案。 2019 年翼支付月活用户 5000 万，每月 2.3 亿笔交易，年交易金额超 1.75 万亿。目前累计接入华润、永辉、苏宁小店、物美、中百等超 800 万家线下商户门店及苏宁易购、京东、天猫、饿了么、中粮我买网、美团等 170 余家线上电商。 客户收益 面对业务快速增长及激烈的市场竞争压力，翼支付技术团队选择 TiDB，对业务系统尤其是支付系统数据库进行改造升级。 经过不懈努力，反洗钱系统效率提升 5 倍，对账平台性能提升 2 倍，而处理时间减少 ⅔ ！目前，翼支付业务层以及核心平台层都采用 TiDB 提供服务。 >我们对系统的改造升级

互联网浪潮将我们带进海量数据时代，数据的存储、更新、查询分析被放在了架构设计的更重要的位置，而数据库作为基础设施，它演变史仿佛成为时代痛点的缩影：从传统单机数据库到分布式数据库，数据库产品可谓百花齐放，大家绞尽脑汁、过关斩将只为摆脱数据处理上 层出不穷的「瓶颈」 。 于是我们不免好奇，未来的数据库应该是什么样的？ ● 让数据库自己智能进化，去预测未来的“瓶颈”（比如流量）？ ● 让数据库“一站式”解决事务处理与实时分析？ ● 还是……？ 接下来的四周，我司联合创始人兼 CTO 黄东旭将开启「The Future of Database 系列直播」，为大家描绘“我们眼中未来数据库的模样”，并分享我们在探索未来之路上的 里程碑式的成果—— TiDB 4.0 的设计哲学与实践 。 4 月 11 日 本周六 20:00 脑洞与探索 未来的数据库是什么样的？ 黄东旭，PingCAP 联合创始人兼 CTO 申砾， PingCAP Engineering VP 4 月 18 日 周六 20:00 会 MySQL 就会大数据？ HTAP 的现在和未来 黄东旭，PingCAP 联合创始人兼 CTO 马晓宇，PingCAP 实时分析产品负责人 4 月 25 日 周六 20:00 一个“聪明”的数据库 会怎样减少你的心智负担？ 黄东旭，PingCAP 联合创始人兼 CTO 唐刘，PingCAP

首先，先给咋们《数据生态--MySQL复制技术与生产实践》这本书来爆个照，它大概长这样！如需购买，可扫描文末的二维码快速直达！ 接下来，借助这本书的对话窗口，我想向大家分享一些我在MySQL的学习成长之路上的一些体会与感想，希望或多或少对大家的学习和工作有所帮助！ 1. 写这本书的出发点 2019年11月，我们出版了《千金良方——MySQL性能优化金字塔法则》一书。从那以后，身边不断有人问我一个问题：“写技术类的书不怎么赚钱，为什么还要写？”刚开始，我还认真回答，但提问者听到回答之后大多仍然表示不解，后来问的人多了，我索性回答：“为了赚名气！”这个答案简单、粗暴、有效！的确，通过《千金良方——MySQL性能优化金字塔法则》一书，我们小“赚”了些名气，不过对于为什么写书的问题，这不是我的全部答案。现在，借新书发售的机会，我将自己全部的想法写出来，希望能完整、全面地回答这个问题。 督促自己有计划地学习 2018年12月，我们有幸参加了电子工业出版社在北京举办的作译者聚会。聚会上有两位嘉宾的话令我印象深刻：一位来自阿里的安全专家说，他已经出版十余本书了；另一位来自美团的某团队负责人说，他规划要写十余本书。“听君一席话，胜读十年书”，这完全颠覆了我之前对于写书这件事的看法。在此之前，我一直以为，技术图书是写作者不断沉淀工作中所学的知识，量变产生质变的产物。能写出一本书

参赛信息 队伍: v587 目标: 优化 ycsb workloade 本周汇报 本周主要工作 ycsb 压力测试，调整参数并比对不同场景下的性能区别 学习高性能课程相关的内容 （planner 和 coprocessor 为主），阅读 TiDB 源码博客，熟悉 query 处理流程 压力测试 本周通过脚本压力测试了 TiDB，跑 60 遍指定的 workloade，并用 gpof 分析 CPU 消耗。使用的脚本命令为： i=60; while [ "$i" -ne "0" ]; do ./go-ycsb run mysql -P ./workloads/workloade -p recordcount=5000000 -p mysql.host=127.0.0.1 -p mysql.port=4000 -p mysql.user=root -p mysql.db=test done && i=$(($i -1 )); done; 火焰图如下： 通过观察火焰图，我们发现， copIteratorWorker 占用了很大一部分时间，反推可以得到： 计算下推给 TiKV 后，等待结果返回时间较长 TiDB 在对查询优化过程中，采取了不是最优的计划，导致 worker 消耗时间长 从开发的反馈来看，我们现在的解释和可能的优化方向是比较正确的。在大家的讨论中提到了 workloade

今天主要是想把我们 TiDB 做 SQL 性能优化的一些经验和一些思考，就此跟大家探讨一下。题目写的比较大，但是内容还是比较简单。我们做 TiDB 的 SQL 层时，一开始做的很简单，就是通过最简单的 KV 接口(Get/Set/Seek)去存数据、取数据，做一些非常直白、简单的计算。然而后来我们发现，这个方案在性能上不可接受，可能行不通，我们就重新思考了这个事情。 TiDB 的目标是做一个 NewSQL 的 database ，什么是 NewSQL？从 Wikipedia 上我们看到 NewSQL 的定义『NewSQL is a class of modern relational database management systems that seek to provide the same scalable performance of NoSQL systems for online transaction processing (OLTP) read-write workloads while still maintaining the ACID guarantees of a traditional database system.』。首先NewSQL Database 需要能存储海量数据，这点就像一些 NoSQL 数据库一样。然后，能够提供事务的功能。所以

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用： 参考资料【4】 这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。 设计数据存储系统可能需要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。 ACID ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？ 事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就一定成功，失败就一定失败。 读写性能可简单理解为：一次读 或 一次写 需要的IO次数，因为访问速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简单的方式当然是：写一条就持久化一条，读一条就遍历一遍所有数据，然后返回。当然没人这么干，在内存中我们都还知道用个HashMap呢。 拿Mysql InnoDB举例子： 读性能体现在数据的索引在磁盘上主要用B+树来保证。 写性能体现在运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，然后在一定条件下触发脏页的刷盘。

点击上方“朱小厮的博客”，选择“设为星标” 后台回复"书"，获取 导语：本文的缘起是回答知乎圆桌会议「分布式系统之美」的问题「如何系统性地学习分布式系统?」，后面稍微整理了一下，形成了这一篇文章（知乎 ID：kylin）。 前 言 学习一个知识之前，我觉得比较好的方式是先理解它的来龙去脉：即这个知识产生的过程，它解决了什么问题，它是怎么样解决的，还有它引入了哪些新的问题（没有银弹），这样我们才能比较好的抓到它的脉络和关键点，不会一开始就迷失在细节中。 所以，在学习分布式系统之前，我们需要解决的第一个问题是：分布式系统解决了什么问题？ 分布式系统解决了什么问题？ 第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太大高，一般的公司很难承受； 第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案； 第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

作者介绍：陈振东，北京银行软件开发部 北京银行是一家城市商业银行，公司价值位列中国区域性发展银行的首位，依托于中国经济的大环境，北京银行的资产总量在全球千家大银行中名列第 61 位，连续六年跻身全球银行业百强。北京银行积极开辟多元化的业务经营，例如北京地区的社保缴纳和医保代发，都是由北京银行在提供服务，在你入职一家公司的时候，收到的医保折子就是来自北京银行。 业务转型驱动分布式架构建设 由于快速的业务发展需求，北京银行在业务转型中对系统架构进行了升级，逐渐向分布式架构进行转移。早在 2016 年，北京银行就开始了对分布式数据库的探索，并于 2018 年正式投产上线了 TiDB 分布式数据库，当时在业内还没有一个比较完善与成熟的体系，我们也是根据银行的安全合规需求建设了两地三中心的部署方案。 如上图所示，在两地三中心部署了 TiDB 分布式数据库集群，采用主从的多活架构，主集群作为生产集群承担日常的生产服务，从集群是建设在西安的异地灾备中心，主从之间是用 Kafka 同步 Binlog 形式进行数据的同步。 在这两年的建设过程中，北京银行与 PingCAP 进行专项的深度合作，这里简单介绍三个方面： 两地三中心 ：在两地三中心的部署方案中，异地中心的网络延时会对整个集群的性能产生较大影响，我们在这层面上对 gRPC 的消息格式进行了压缩，同时利用 Multi-Raft

参考文章： TiDB 和 MySQL的差异 站在业务开发的视角，TiDB 最吸引人的几大特性是： 支持 MySQL 协议（开发接入成本低）； 100% 支持事务（数据一致性实现简单、可靠）； 无限水平拓展（不必考虑分库分表）。 基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。 TiDB 事务和 MySQL 事务的差异 MySQL 事务和 TiDB 事务对比 在 TiDB 中执行的事务 b，返回影响条数是 1（认为已经修改成功），但是提交后查询，status 却不是事务 b 修改的值，而是事务 a 修改的值。 可见， MySQL 事务和 TiDB 事务存在这样的差异： MySQL 事务中，可以通过影响条数，作为写入（或修改）是否成功的依据；而在 TiDB 中，这却是不可行的！ 作为开发者我们需要考虑下面的问题： 同步 RPC 调用中，如果需要严格依赖影响条数以确认返回值，那将如何是好？ 多表操作中，如果需要严格依赖某个主表数据更新结果，作为是否更新（或写入）其他表的判断依据，那又将如何是好？ 原因分析及解决方案 对于 MySQL，当更新某条记录时，会先获取该记录对应的行级锁（排他锁），获取成功则进行后续的事务操作

参考文章： 日均数据量千万级，MySQL、TiDB 两种存储方案的落地对比 盖 娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。 初期的 MySQL 存储方案 在系统设计之初，基于对数据量的预估以及简化实现方案考虑，我们选用了高可用的 MySQL RDS 存储方案，当时的匹配逻辑主要通过 SQL 语句来实现，包含了很多联表查询和聚合操作。当数据量在千万级别左右，系统运行良好，基本响应还在一分钟内。 遭遇瓶颈，寻找解决方案 然而随着业务的发展，越来越多游戏的接入，盖娅广告系统系统接收数据很快突破千万/日，高峰期每次参与匹配的数据量更是需要翻几个番，数据库成为了业务的瓶颈。由于此时，整个技术架构出现了一些问题： 1. 单次匹配耗时已从原本的 10 秒左右增加到 2 分钟以上，最慢的聚合查询甚至达到 20 分钟，时效性受到严重挑战。而且 MySQL 的问题是查询的时间随着数据量的增长而增长，以至于数据量越大的情况下查询越慢。 2. 随着历史数据的积累，单表数据很快达到亿级别，此时单表的读写压力已经接近极限。 3. 由于第一点提到的查询性能问题以及单机的容量限制，需要定时删除数据