网易云音乐 DBA 谈 TiDB 选型：效率的选择

编者按

本文摘自由网易 DBA 团队撰写的《效率的选择——分布式数据库 TiDB 网易内部选型介绍》一文，对比了以 TiDB 为基础的创新架构和 MySQL + DDB 传统架构的差异，从业务适配、降本增效、技术创新等多个维度阐释了网易考虑引入 TiDB 的原因。

作者倪山三，网易数据库专家，杭研数据库运维团队负责人。

TiDB 是前开源数据库领域最热的技术热点之，无论是从发展势头、技术迭代速度还是社区活跃度等来说，在国内一直保持着领先水平。易 DBA 团队本着好奇和尝鲜的态始终关注着 TiDB 技术发展，也一直在进行着 “打闹” 的尝试。但是如果要从线上选型角度去严谨地调研款关系型数据库产品，其动机和预期成效的讨论应当是非常严谨的。

直点说，就是我们有什么理由要款新技术尝试挑战稳定使的现有技术案，特别是在易研分布式数据库 DDB 能满我们当前需求的前提下。TiDB 对我们来说并不是分布式数据库 0 到 1 的改变，是

系列痛点上 1 到 1.1 创新的集合，更需要细致地加以阐明，本即是对这问题较全的讨论。

DBA 团队希望将 TiDB 逐渐引入易数据库核选型，对相关技术感兴趣，或者有具体需求的同学请与 DBA 保持沟通，也希望本起到定的解答疑问和推作。

DDB 是网易内部自研的 MySQL 之上的水平分布式中间件，可以类比为 ShardingShpere 或者 Vitess。

分布式数据库技术发展背景

随着各成本有着显著优势的 PC Server 趋于绝对主流，现在提到数据库，很少有会想到型机和盘柜时代的 Oracle 或 DB2 这样个柜百 T 的型集中式数据库了。但是业务数据量和请求量仍然在不断增，因此近年来我们就要依赖分布式数据库技术，

利规格的 PC Server 资源，提供体量的集群式服务。

分布式数据库有着多种实现式，对比单体数据库时代我们能够提供的接入体验，业务通常

要求分布式数据库案满以下基本特性：

要尽可能完整地持包括 CRUD 和 DDL 在内的 SQL，同时要持事务特性，满这两点才能算的上是个数据库

通过统集群入提供服务，屏蔽内部分布式细节

要有伸缩能，论通过何种段，数据库要能满持续增的存量数据和吞吐能要求

作为最重要的中间件，服务应对软硬件故障的可特性也是重要考虑点

利零碎资源组装型服务的分布式技术可以说是前服务端软件设计的标配，理论与实践直在不断发展，但是其实关系型数据库分布式技术的发展可能没有家想象的那么成熟与完善。关系型数据库本虽然发展较早，但是却是在分布式技术是发展爆发较晚的那个。在义存储领域，2006 年概是分布式技术最重要的年，当时 Google BigTable、Amazon Dynamo、Hadoop 乎同时出现，奠定了前整个业界分布式存储从技术原理到基础设施实现的半壁江。关系型数据库直到 2012 年 Google Spanner 论发表前，期处于商业案垄断，分布式技术理论发展较慢的阶段。可能就是由于上述 4 点特性要求使得分布式数据库的技术槛显然比其他不需要持事务、持 SQL 的服务来的高。

在我看来，关系型数据库分布式技术发展可以分为三个主要流派线路，其各有多个阶段：

前整个业界现状基本如此，三个路线虽然发展有早有晚，但是前都处于被泛接受并且直活跃的情况，并不是般认为的换代取代的关系。同时可以看到选择其实并 不是很多，少比数据那庞杂的技术栈清晰多了。我们进步分析下我们可能的选型：

sharded storage案虽然技术含量很，从性能到吞吐能都可指摘，但终归是完全的商业化案。我们并不排斥，将在公有云场景中适时地充分利，但是依赖特殊供应商的商业案显然并不能作为孤注掷的唯选型，除非有相对开放的案出现。

DDB 是易研的，基于 MySQL 的分库分表型中间件，也是当前我们的主流选型。在这类型的分布式案中，各种开源中间件的功能，实现式都非常雷同，其他任何案与 DDB 相比都不存在同质竞争的明显优势，各缺点都很突出，不如 DDB 普适。因此在中间件这流派，DDB 就是最优解。但是分库分表中间件在如今的业务使场景中逐渐遇到些效率的问题，这也本接下来的主要论述重点，为啥我们有 DDB 分布式案的情况下还需要尝试新的分布式数据库技术。

这样剩下的就只有 NewSQL了，要看是否能解决我们在 DDB 中间件案中遇到的痛点了。 NewSQL 三代表中只有 TiDB 是主打 MySQL 兼容，特别是 YugabyteDB 脆 Postgres 为主，所以我们聚焦的重点然然变成了 DDB VS TiDB。

所以看着像是数据库技术间的世代竞争，其实也没这么复杂，对我们的现状来说，

传统数据库 = DDB + MySQL，眼下的新代 = TiDB。

TiDB 选型优势与传统分布式案较分析

最本质的问题其实是我们是否需要，为什么需要引入 TiDB 技术。如上所言，我们希望通过新代数据库运，来解决或改善当前 MySQL 分布式中间件模式使中的些问题。都有哪些问题、TiDB 如何改善，我们将展开详细介绍。

优势概览

先先看选型调研下来关于

TiDB 优势的结论总结，接着按照相关分类逐进论述:

提供 DDB 同等的平扩容能

SQL持能较 DDB 好

资源扩缩容粒度更加灵活，不需要像 DDB，每次都翻倍扩容

扩容为效率和安全性

数据存储成本定程度降低

在线 DDL持更好，除了加索引基本都是秒回，表增加修改列成本显著降低

主从复制效率显著提，降低写负载下致性和可降级的险

数据致性下限提升

可动恢复可靠性与效率显著提升

HTAP 能能够减少数据传输环节的成本和险， 提供业务更效的实时分析能

SQL 持能较传统 hash 分表模式得到提升

TiDB 虽然也并不是完全兼容 MySQL 所有 SQL 功能和语法，依然有定限制，其中相对重要的限制包括:

不持存储过程/触发器， 不持 select into 变量不持 MySQL 较新的 WITH ROLLUP 开窗

不持外键约束

不持视图上的 DML 更新基表

不持显式 XA 流程控制

不持 savepoint 制

5.0 之前的版本不持 DECIMAL 精度修改

但是对于我们来说，这些限制乎没有影响，因为分布式中间件 DDB 也部分不持或者限制很多。我们

可以认为 TiDB SQL 能是 DDB 的超集，业务仅需要更换驱动，从 DDB 专有驱动 DBI 更换为开源 MySQL 驱动如 jdbc + 连接池即可完成业务迁移。

这个超集部分体现最直接的就是

查询和 join 的持能有显著提升。DDB 模式下由于所有表都做了指定字段的 hash 分布，join 语句如果 join 字段正好是两个表的均衡字段，则能够完成分布式数据库内连接查询，性能尚可；但如果 join 字段必须跨节点匹配，在 DDB 中只能通过客户端 DBI 集中缓存全部数据的式进中化计算，极易造成 DBI OOM 进崩溃。进步地，查询由于优化器直没有完成相关功能，直接是不持的。这TiDB 的持显然要优秀很多。

但是 TiDB 使过程中还是有些其他的

注意点:

增 ID， 由每个 TiDB server 独立分配， 能保证全局唯， 且单个 TiDB server 内递增， 但是法保证全局递增， 以及没有任何连续性保证。这个其 实和 DDB 的批量分配唯ID 造成结果类似的。

单单列度限制， 都是定死的 6MB， 也就是 KV 的单个 key entry 上限就是 6MB， MySQL 可以通过 longtext/longblob 等突破到 G 级的记录度， 在 TiDB 不适。

事务度限制，在使乐观事务并开启事务重试的情况下默认限制 5000，可调整，同时我们不太可能泛使乐观锁模式，因此影响不。其他以前很坑的事务数限制 30W，总 100MB 等在 4.0 后不存在了。

平扩容实际效率和能显著提升

DDB 和 TiDB 理论上都可以通过增加存储节点，并且重均衡存量数据，实现存储容量近乎限的扩展能，但是实现式上相径庭。客观来说，DDB 前在易的使规模已经使得平扩容在部分场景下困难重重。

传统分布式中间件的扩容形式同异， 你需要先为集群添加扩容前资源成倍的新资源， 但是这些资源暂时还不可对外提供服务， 然后通过各种段将存量数据以及实时增量数据同步并拆分到新资源，然后找某时刻完成新老资源的替换，老资源下线，完成扩容全部流程。

由于有量的经验和具开发，DDB 传统模式扩容我们有着非常完善的动化辅助能和可靠性保障，因此能是没有问题的。关键在于效率：

先是必须成倍的资源投入。我们内部较规模的 DDB 集群数据存储量有百 T 这个量级，这是 8 年存量的结果，这个存量情况下数据的增量很难再出现成倍爆发式增。但是传统拆模式下的扩容通常要求成倍的新资源投入，拆完后位从 100% 下回到 50%，年实际增可能还不到 15%，这个次扩容的投入成本效率可斑。当然我们可以同重新 hash 等式使比例扩容，技术上是做的到的，但是下就要讨论时间和稳定性成本了。

其次是扩容过程效率太低了，我们有多种式完成存量数据的迁移以及增量数据实时同步，技术上没有问题，但是效率实在太低了。在保障线上负载相对稳定的前提下，我们的经验数据是算上增量补偿时间，每 2T 数据迁移完成物理式约 10~20 时，逻辑式约 30~40 时。当然分布式集群这些传输都是并的，由于磁盘容量因素，我们数据库通常以 6T 为个并单位，即便如此，整个时间也得以周来计算了。

然后就是扩容成功率的问题，部分情况下够的资源投入和够时间的准备周期让我们扩容相对来说还是靠谱的， 但是近年来我们确实遇到了扩容案法实施的问题。例如有次扩容需求来于业务逻辑调整，数据写入吞吐量剧增，负载和容量都不够需要扩容，但是 MySQL 孱弱的主从复制效率造成了扩容后增量数据补偿永远跟不上数据写入量，甚换了更效的内部逻辑并 CDC 案也跟不上，导致数据源切换法完成的情况。也就是我们即使紧急准备了够的资源打算扩容现有集群，依然可能出现不上的情况。

综上，我们可以看到 DDB 式的扩容在些实际场景在投入成本，效率，可性都有些难题， TiDB 的引入则能够为我们解决这些问题。TiKV 的扩容从运维角度上来 看是机器简单的个操作:

TiDB server 由于状态，其

扩容相对容

易， PD 作为管理服务本概率不需要扩容，因此通常来说的扩容主要是存储服务 TiKV 的扩容。

TiKV 扩容操作仅需要在新增服务器上合理配置并启动服务即可， 新启动的 TiKV 服务会动注册到现有集群的 PD 中， PD 会动做在线的逐步负载均衡， 对业务感知地， 逐步地把部分数据迁移到新的 TiKV 服务中。新投入的 TiKV 资源可以认为在启动的瞬间就已经将资源添加到了现有集群，

不需要再等待漫的， 外部控制的数据重分布过程。

顺便提下， 传统分布式形式中数据库的缩容和扩容基本同样烦， 都需要临数据重分布效率低下的问题。在 TiDB 中缩容 TiKV 节点， 只要不违反相关约束， 安全关闭前 TiKV 会先通知 PD， 这样 PD 可以先把这个 TiKV 上的数据迁移到其他 TiKV 实例，

保证数据有够的副本数后完成感知缩容， 效率和动化程度也较传统模式有巨提升。

因此我们看到，论是从扩容操作效率，过程的动化程度，还是过程的可靠性来看，TiDB 都是比传统模式有着很的提升，能够将以天乃周计算的扩容流程效率提升到分钟这个级别。

schema 变更持能提升

类似上条平扩展，在采MySQL 底层的基础上的传统分布式中间件还存在着显著的 schema 变更瓶颈，且问题也是出现在存储资源和性能上。

schema 变更有些是相对容易便捷的操作，例如新建个表这样，在任何情况下都不是太的问题。有些在 MySQL，或者说传统块存储数据库中直是相对烦的为，例如加字段，修改字段类型属性，加索引，改键等。在 Oracle 中通过正常 DDL 或者在线重定义两种比较正规的形式就能统所有操作需求，在 MySQL 中这类变更功能直是技术难点，段多，坑也多，家可以通过下的图感受下:

主要

痛点包括:

MySQL 的 online DDL 始终让难以完全信任，即使在 online DDL 随着版本完善的过程中，我们也不得不为了规避某些情况坚持使外部变更具。

由于稳定性险， 虽然 online DDL 并不会如传所说锁表时间同增量更新有线性关系， 但是依然有其他的险， 例如我们不太远的过去遇到过 online ddl 中 inplace 算 法 要 求 刷 脏 导 致 写 负 载 型 数 据 库 卡 顿 影 响 稳 定 性 的 险 。我们已经在哪种情况使哪种式做了非常多的策略判断了， 多年尝试， 实在难以根据每个特定业务场景做出完全可靠的智能策略，有时候为了避免不必要的险，不得不依然依靠业界泛使，受考验的外部具继续做为统变更段。

由于不确定性险，我们研运维平台动化处理的数据库变更年接近万量级， 如果说种每天都在频繁使的核功能其成功率要依照个默认 128MB，实际不知道多合适的参数的限制，在部分业务场景会经常遇到 RROR 1799 : Creating index 'idx_xxx' required more than'innodb_online_alter_log_max_size' bytes of modification log…… 类问题，不但失败还要浪费量资源进回滚的。这个功能是个可靠的功能吗

实际上在业界对 online DDL 的年不敢泛使是 DBA 这边的常态，比如阿云等公有云商和我们是基本相同的做法: 如果你要商提供变更持，则律采外部具，即使在 PolarDB 时代依然如此。

MySQL 内部机制不太靠谱， 外部具也问题多多， 特别是效率问题， 外部具变更需要比变更表更的磁盘剩余空间来完成操作， 因为外部具和原始 DDL 的 copy 模式是样的， 只是不锁 DML已。我们需要完全拷份原表数据应变更， 并且期间还会造成量 binlog。比说， 你想变更个 500G 的表， 我们的经验是数据库本地需要少还有 1T~1。5T 以上空余空间， 我们通常认为才是完全安全的。同时拷数据同上扩容是类似的情况， 需要量时间。实际情况是核业务存量表往往较， 导致你还得先扩容再变更， 这就造成了变更的时间成本和资源成本经常让业务难以接受——翻倍的资源， 以周计算的时间， 变更期间读写分离致性失效， 可失效……我们的业务通常望畏，让本该随所欲的数据库变更变成种仅在理论上可能，实际难以实现的需求。

其他的性能冲击，约束键导致的致性险，变更期间可险，DDB 环境下分布式变更的调度和原性控制，极端情况下家都会遇到的 MDL 阻塞，对备份机制的影响 ……各种各样问题不。

以上痛点是致命的，严重影响业务迭代，稳定性，效率的。我们迫切希望种新的模式来改变现状，顺便提，变更的部分痛点即便在 PolarDB 和 Aurora案下依然还是难 点，因为他们的上层使的还是 MySQL。我们 DBA 团队随着多年采坑，为了能够提供线上可靠的动化变更能，不算具，流程，前端代码，仅后端调度和管控代码就投入了两万多，前除了资源吃不消难以变更的情况外，能够基本保证常变更效安全。虽说这是我们吃饭的本事，但是我还是要说这个模式复杂的没有价值，效率也随着业务存量增加，逐渐显得不可接受，希望技术上能够得到突破。

TiDB 在这块以我们调研和前应结论来看，就有较的优势了。

简略来说，TiDB 主要有如下优势:

由于 kv 模拟表的数据结构，以及 LSM 存储法更新的特点，量数据类型，加减字段，默认值类的操作都可以通过仅元数据变更实现完全 instant，相较 MySQL 8.0 的 instant

范围显然要，效率非常，都是 1s 级别完成变更，且业务感知。

加索引这类必须产新持久化数据，法 instant 的操作，采后台任务，异步线程的机制实现对业务影响相对。且 ADD INDEX 时 tidb 有明确参数记录前索引 创建的进度和速度，能够较好安排调度。

上述两者都比 MySQL copy 或外部具模式显然节省空间。且 TiDB 本扩容就要比 MySQL 中间件式容易的多，变更的效率和可性都将巨提升。

更不会有主从问题带来的系列延伸问题。

当然虽然效率提升了，但是也不能说 TiDB 的变更对业务完全没有影响，具体来说是有些新的情况:

由于 schema version 的变化，执的 DML 语句中涉及的表和集群中正在执的 DDL 的表有相同的，那么这个 DML 语句就报错Information schema is changed,次性，但是需要业务使连接池连接数据库，并且业务端有重试机制避免事务完全失败。

ADD INDEX 操作，根据压测，标列被频繁读写，特别是写多时对性能影响较，QPS/TPS 极端情况下下降 23% 左右，这个其实和 pt-osc 近似了。

总体来看，我们是非常希望通过引入 TiDB 来解决前业务表结构变更中的痛点，提升相关效率，进帮助业务更快更安全地实现迭代。

可可靠性与效率显著提升

MySQL 虽然是业界最泛使的数据库种类， 但是在 MGR 技术完全普及前其服务可实现直是有问题的。具体设计上的问题各位可以 KM 搜索我之前的数据库可章，我们就不展开了，直接介绍业务痛点。

主从致性虽然可以做到相对安全，但是下限非常低，需要许多相关参数和机制配合，例如多种 log 持久化，半同步，复制信息表记录，半同步 ack 模式，non-loss 等……项问题都可能导致主从不致，进影响可靠性。

不 MGR 则集群没有内部协调机制，切换需要外界参与，不能向 ZK，redis cluster 样集群内部完成，这就导致了切换成功率，资源漂移可性，以及如何防极端 情况脑裂双写量的坑。并不是不能做，但是要做到完全靠谱并不容易，这块我之前的章有非常详细机制原理的介绍，如感兴趣请参考。

了 MGR，虽然集群内部角和治切换问题得到了解决，但访问模式官直没有给出非常好的解决思路，论是堪比 sidecar 的 proxy 模式还是改客户端，或者像过去样外部控制资源漂移，都没有很好地解决客户端切换的问题。这块MySQL一直没有和 Redis 或 MongoDB 学习，让人比较郁闷。

外部切换还存在效率问题，也就是切换对客户端恢复服务的时间间隔。有可能是域名切换，客户端缓存导致的问题，也可能是 DDB 这元数据更新串化导致的。特别是易内部 DDB 泛使的 DDB 模式下，由于通过更新路由配置中实现，存在通知客户端络超时和配置中更新只能串两的痛点，导致硬件故障造成的最基本切换场景所需的时间只能保证在 1 分钟级别，5 分钟以内，这就是切换效率的问题了。

最的痛点，即便是 MGR，MySQL binlog 复制是可功能上法回避的梦魇。这块接下来要单独讲。

单独来说

MySQL 最核的问题之，基于 binlog 主从复制的性能问题，这问题并不能通过升级 MGR 技术改进:

相对 Oracle 的数据逻辑复制，MySQL 的 binlog 逻辑复制性能简直让法忍受。即便是并复制情况下，根据业务特征，部分情况下，论哪种并模式都法让复制效率实现质变，为了提高效率我们不得不折腾日志持久化，组提交等周边性能要素，甚至造成一些持久化风险。通常我们认为在 CPU，IO 和络都没有瓶颈的情况下，单组 MySQL 实例多也就只能保证简单更新 3000~5000 tps 的复制效率，随着逻辑复杂，部分业务可能超过 2000 tps 就可能产延迟，如果在所有安全措施特别是从库志持久化相关全部严格要求下，性能可能更糟……复制延迟意味着可动切换失效——虽然志到了从库，但是数据尚未被更新，不能让业务切换后读写延迟的数据。

线上负载可能导致复制延迟，例如我们些电商类的活动峰期间，订单等数据的写入峰造成延迟，再最关键的时候数据库可实际上是没有保护的。

变更可能造成延迟，论是 online DDL 还是外部具变更，都会随着变更对象规模变化，造成不可控的延迟，严重的可能以天计算，在变更期间于读写分离分流负载的从库法读，同时主库缺乏可保护，挂了就挂了……家知道真相是不是会出冷汗

MySQL 解决延迟我们认为唯可的办法就是实例级别的平拆分，每个实例来撑尽可能的 tps 负载，种非常另类的并化。但是这并不是种非常可的模式，例如 DDB 为代表的分布式中间件场景下，个数据库从 64 分片拆到了 640 分片，每个客户端连接对象，分布式事务损耗，集群变更和管控难度都会不断正在，且也法保证真的能彻底解决延迟——比如问题是热点造成，如果业务热点写集中在个分片呢

TiDB 在可和数据复制同样有着巨的优势：

致性下限就非常，raft 机制保证数据副本可靠，想要造成不致的可能反困难。

TiKV raft group 治选举，状态的 TiDB server 层动更新路由，治切换和业务连接漂移都不再是难事。

切换效率也非常好，虽然每个 group 都要选举，但是度并化，稳定的 10s 数量级内完成。

raft group 级别度并的复制效率，我们做过相关压测，写压在 MySQL 等量集群延迟位 10~20 倍以上的情况下依然没有相关险。

TiDB 的数据多副本致性，可在机制上对于传统 MySQL，特别是非 MGR 模式来说堪称

跨时代的进步——终于进入了合格的分布式集群时代。

未来，特别是业务可能量使公有云设施的情况下，可能 TiDB 这类效和可靠机制是强需求，因为公有云虽然整体资源池有优势，但是单点资源的可靠性根据我们的经验和 SLA 标准来说，是不如我们现在的有机房的。如果在成本考虑，不完全依赖 RDS 的前提下，资源问题概率的提升会放以前可机制上的多种问题，TiDB 可说根治性地解决了这些问题，这也是我们希望换代的关键理由之。

存储成本有优势

TiDB 和传统数据库在存储硬件选型上没有太区别，基本我们般都是使 SSD。那么存储成本可以这样来对比估算。

以块单独的 SSD 磁盘为最单位，MySQL 模式即便是最冗余份的前提下，我们也会有 4 块磁盘， TiDB 这边由于度的致性保障，我们可以磁盘就不做 raid1 了，这样最单位虽然是三副本，但实际投入是 3 块磁盘。也就是少节省 25% 的空间。

进步地，TiDB 相较 MySQL 还有另外个优化点，MySQL 的 innodb 由于历史原因，我们并没有泛采压缩格式， TiDB 的 RocksDB 存储引擎默认是压缩的。虽然 kv 逻辑上有着较区别没有办法直接比较，不过总归来说，压缩总是可以定程度上节省空间的。

根据我们具体测试量化来看，TiDB 压缩相较 MySQL 非压缩情况下根据业务数据不同，差距很。比如 sysbench 类随机字符串意义数据，压缩比例不，

5 亿68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441这种类似的随机字符数据 innodb 114G， TiDB 102G。

但是如果是有量数字，浮点，时间戳，有意义短单词的实际业务数据对比，如果数字特别多，压缩比例非常惊,

非压缩的 innodb 要 398G，而 TiDB 不到 30G。所以还是要看数据类型，虽然并不是压缩比定非常，但是肯定比 innodb 非压缩情况要好。根据我们实践经验保守来看，压缩节省比 例来看综合在 30%~50% 左右。

这样 25% 的 raid 节约，结合 30% 以上的压缩节约，综合起来我们可以认为 MySQL 换 TiDB 存储上可以有 35~50% 左右的存储硬件成本节约。这对存量预增的业务显然也有定的意义。

另外顺便提下， 在新型硬件， 例如 NVMe 存储设备， 由于 PCIE 法再接 raid 了， 因此天然适合 TiDB 这样软件层强直冗余， 完全放弃 raid 硬件层冗余的模式。

HTAP 创新模式

以上可能都是 1 到 1.1 的改进，HTAP 应该算是 0 到 1 的型场景创新了。

我们强烈地希望 TiDB 相关特性能在易发挥业务价值。

传统数据库我们通常认为有 MySQL 这样的纯 OLTP 数据库，由于存，优化器功能局限，没有 MPP 引擎，中间件功能有限，资源利率般……等多种技术原因，是完全跑了不 了 OLAP 分析请求的。也有 Clickhouse 这样专注 MPP 和资源利率，但写多个并发或 SQL 没有批量就有稳定性险，完全跑不了 OLTP 请求的。可谓泾渭分明。

在我们当前绝部分当前业务场景下，都是类似上图，都需要从 OLTP 系统将数据录入专负责处理 ad-hoc 类分析的在线 OLAP，以及专处理任务式计算的离线数仓。虽然图看的很简单，但是其中利到的技术栈相当庞杂，在易内部数科团队，DBA 团队，业务算法团队，中间件研发团队等多个团队全拴在这个链路上，可以说是技术含量最的业务链路之。在业界相信很多公司也是类似的情况。

OLTP 部分主要就是 MySQL 及其分布式中间件。

pipline 环节通常也可能是有逻辑过程的 ETL 环节，技术栈可能有定期批量的 sqoop 或 datax 式，实时的 CDC方式，处理过程中为了进清洗和逻辑过滤等需求，还得上 kafka 等队列和业务代码。

OLAP 光处理 ad-hoc 前我们就有 Oracle，greenplum，clickhouse，kudu+impala，presto 这堆技术栈；其他 SQL 引擎如 doris，keylin，druid，hive 都有应; 如果流式需要还有补上消息队列，flink，spark 等; 离线任务侧 yarn，spark……

上图来自小米的技术分享 ， 你会发现这业就是以罗列技术栈和链路架构为乐， 这个现状是业界主流。在我的角度来看其实挺有意思的，数据嘛，多上，且技术上确实也有必要性，数据确实需要适才适。但是其实也是有些显易的痛点的:

ETL 过程时效性与数据致性。

逻辑上的变更往往也是难点，论是服务架构，存储式，或是最上游表结构变更，都需要链路上量改动持。

服务技术栈特征是典型的多、专、深，依赖量富有经验的研发和运维投入。

投入资源较，中间过程和存储都是如此，如果需求需要多种技术栈才能满要求，则投入成倍增。

架构和团队复杂化带来的些效率问题。

业界也有数据库不断在兼容 OLTP 和 OLAP 两种模式间探索，前有 Oracle 内置 MPP，后有 kudu 尝试兼容 OLTP。

TiDB 依靠其特有的列双存储技术特点，似乎走在了更加合理的道路上。

TiDB 提出的标是 100% 的 OLTP 和 80% 的 OLAP 场景，我不敢说这个标是否切实，但是现状来看替代上述庞杂的 ad-hoc 分析需求中的部分技术栈应当是合理的标。TiDB 的技术案也在短短的年内也是经过次重迭代的，19 年以前的单纯的 TiSpark 案实际上适性般，但是当前

结合了 TiFlash 列存存储的案则真的是走出了的特。

简单来说我们之前谈到过 TiDB 底层是有 TiKV 中的 kv 数据模拟表 OLTP 数据库， TiKV 的写入则是通过 raft 协议和志同步保证了多副本致性， 那这个思路下同样可以通过致性写入的式完成存 TiKV 和列存 TiFlash 存储的数据同时写入， 这样 TiSpark OLAP 引擎和 TiDB OLTP 引擎可以在完全致， 但存储异构的两种数据源间由选择访问的，我们知道列存对于 OLAP 本就是极的提升，加之研发团队在相关领域的其他专业优化，个真正在存储和计算层同时做到既保证数据致，又能适才适的 HTAP 数据库案就出现了。

这架构有些显著的优势:

架构简单紧凑，管理和实施案非常完善，且 TiFlash 功能的启很灵活，业务任何阶段都可以调整，任何线上表可以不开启节约成本，可以随时开启持新增分析需求。

集群实施成本也从 HDFS 级别缩减到了正常数据库级别，你不非得下找台来搞最线上部署，按需投入资源即可。

分析数据从表结构到内容基本同在线表完全致，如果分析需求就是需要基于在线结构，那么直接写 SQL 即可，可以完全省下同步环节相关的资源和维护开销。当然客观来讲，ETL 当然还有 T 的需求。

优化器持，查询到底走哪种形式可以通过定义，也可以交给优化器判断，定程度上把纯粹 SQL 暴露做的更彻底，业务可以更简单地实现需求。

OLAP 部分非常专业的深度优化，例如 TiSpark 可借助类似 clickhouse 的向量化引擎，按照和 TiKV 相同的 coprocessor 协议下推任务到 TiFlash，提升资源利和性能。

扩展与 TiKV 样容易。当然除了部分 外的部分分布式数据集群案在这还是可以的。

我们在公司内部有些实践，随后会做简单介绍。同时我们也并不指望 TiDB 的 HTAP 下能起到多作，只是

希望在些特定场景下提升服务能，并简化架构，提升效率:

替代现有相对老旧的 Oracle 和 GreenPlum 技术，主要是 roll up 类可能有些麻烦，但是绝大部分联表类肯定是可以的。GreenPlum 还好，Oracle 以我们现在的硬件条件，扩容都很困难

解决一些不合适的 SQL 直接在 MySQL 或者 DDB 集群里跑的问题，让 OLAP 处理效率合理化，促进更多数据分析能力和需求

如下图，部分替代 Impala on Kudu 和 Presto on HDFS。数据都来自线上导入，就可以尝试所见链路，提供更标准的 SQL 入口应该有的吸引力。

TiDB 内部实践

适场景推荐

由于并不是分布式案唯选择，所以 TiDB 严格来说对我们有比较确定的适场景，我们总结如下:

有明显淡旺季，周期性，需要峰保障类型的业务

如电商有促销活动的场景，如些业务专持临时活动的模块，如有显著周期性的教育类业务等，可以充分享受灵活扩缩容的优势。

对可和数据致性需求特别强烈的业务

记账对账，消费凭证，外部付回调等，可和致性较平的保障能够帮助业务尽可能提可靠性。

公有云上由于资源可靠性不如内部机房，如果未使 RDS，可以尝试 TiDB。

核模块两地三中案

TiDB 提供种非常有针对性的两地三中实施案， 参考: https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment。意味着同城机房做跨机房的实时可冗余切换，异地机房提供份非常可靠的最终数据冗余兜底。这场景可以活于重要性的系统元数据，比如私有云服务元数据，像内部对象存储元数据这块再合适不过了，极规模的关键数据，还能充分利快速平扩展的能。

对 HTAP 有需求的业务

前提过，如果对任何线上数据有分析查询需求，完全可以尝试不再使传统导数据流程，使 TiDB 单系统内搞定。

但是，由于我们的标还是把 TiDB 尽可能地引入核数据库选型，因此我建议前对 TiDB 感兴趣的业务不太拘泥于必须是完全匹配的场景。能上匹配场景当然是最好，如果并不确定适性质，那只要:

计划使 MySQL/DDB， 但也对 TiDB 非常感兴趣

确实遇到存量变更扩容难痛点

单纯想尝鲜下

想要降低存储和运维成本的

想要学习分享新技术的

都可以积极尝试下。保险考虑，无论是何种新技术的尝试，那种途相对单或边缘，但是业务和存量数据相对的场景作为起步肯定是最好的。

技术迁移和配套持案

使 TiDB 与其他原有数据库的区别：

业务使 TiDB 主要考虑 SQL 兼容和客户端连接案。

如果是研系统，业务在易内部习惯于使 MySQL 或公私有云的 RDS，非使 DDB，那么 TiDB 使上和过去项没有任何差异，使普通驱动和连接池，更新数据库地址即可。以我的经验中，TiDB 不持的 SQL 功能我们正常研发也基本不会到。

如果要作为其他开源系统的底层元数据存储，可能要考虑下 SQL 兼容性，因为业界使 SQL 的复杂程度有较区别，我们过些国外开源项 SQL 使深度比较复杂的情况。

如果过去习惯使 DDB，是 DBI 也就是特有驱动模式的，需要更换为 jdbc 驱动，并增加连接池，因为 DBI 客户端是内置连接池，jdbc 没有。

替换 DDB 的 SQL 致没有问题，TiDB 持是 DDB 的集。需要注意的主要是 DDB 些老式的唯 ID 分配模式，要替换为 MySQL 兼容类型，例如隐式分配等。

如果过去习惯使 QS 代理模式连接 DDB， 使了 LBD 的要去掉 LBD， 改成正常 jdbc 连接式即可。过去使 QS 但未使 LBD 模式 的不需要做任何修改。

TiDB server 分布式集群访问

由于我们知道 TiDB server 是组状态的计算节点，过去的 MySQL 类数据库我们都会提供个唯的入，例如是虚拟 IP，域名或 DDB master 地址等形式，业务不需要关 系后端服务的漂移切换等细节。TiDB 这边的 TiDB server 对外暴露服务。我们可以选择如下案：

案，传统 HAProxy，LVS 等负载均衡软件，配合 VIP，域名等切换资源，这是最常的案。

该案的主要问题是负载均衡代理程序可如何保障，逐级堆叠很可能最后堆到 OSPF 去了。不过前依然是最简单最可靠的接入式，推荐使。

案，采原 MySQL jdbc 驱动的 multi-host 配置法，该案在连接数据库的时候采如下的写法:

static final Srting DB_URL = "jdbc:mysql:loadbalance://10.170.161.65:4121,10.200.166.102:4121/zane useSSL=false&failOverReadonlly=false";
也就是次性连接提供的多个 TiDB server 服务。经过测试，可以实现多个 TiDB server 间的负载均衡和动排除故障节点与连接恢复，详情请参考上述链接。主要问题是 TiDB server 列表如果发改动，例如扩缩容或迁移，业务就需要修改链接并重启，会很烦。
案三，由于 TiDB server状态的良好特性，我们将 TiDB server 集群移植到了 K8s 内，作为个 service 对 K8s 内外进服务。

状态 TiDB server 的 K8s 化非常顺利与合适，通过 Ingress 的式也可以提供 K8s 外业务访问的能，相关准备和验证作都已经完成。我们最终的标肯定是 TiDB 的完全云原化，前部分云内部分云外的案只是稳定性考虑的过渡模式。

综合来说，三个案都可，我们会根据实际情况和业务讨论确定具体使哪种模式。

监控与其他运维持

从 DBA 的角度来看，TiDB 前有着较完善的监控机制与配套具，并且完全基于业界同的开源技术，因此我们前也不打算再像传统数据库那样为它再重新做套采集脚本与展界，是直接复原的案。

TiDB 各组件均提供标准的 Prometheus 数据接， 监控服务采原 Prometheus 拉取模式即可；另外 Grafana 有针对 TiDB 的完整模板， 并且区分度， 同时数据逻辑联系强， 属于经过实践的度有效模板。因此后续我们对 TiDB 监控展和告警将直接使原案， 不 会迁移到哨兵或其他建系统。并且报警系统对接当前 popo 或内部电话告警等接也调试可。

除了监控外，TiDB 作为数据库其他基本监控需求，包括不限于: 备份恢复，扩缩容持，动化集群操作具，志处理具，数据导入导出，集群配置修改管理，版本滚动升级……等等，均有针对性具，最可贵的是 TiDB 社区非常重视 SOP 档作，让社区经验能够转化为实践指导，这在开源数据库是非常难得的，同时我们内部也经过充分演练。我们团队与 PingCAP 的撑和具研发团队接触也较多， 深刻体会到 PingCAP 相关研发和社区持同学都是资深 DBA， 对数据库使过程中的需求和难点有着非常深刻地认识与量实践经验，因此相关产品具也相当实，且相对其他开源项目可靠。

进步地，内部常使中些常点，例如 OWL 的屏数据访问能，以及常变更的动化单持能均已准备就绪，经过线上验证。业务常使过程中应当不会感受到 TiDB 与其他 MySQL 数据库的差异。

结论上看，

我们认为从运维撑能上，TiDB 也完全具备在内部推的各项条件。

现有业务迁移 TiDB 案

新上业务比较容易，但是针对已有数据和应的业务将现有服务前移到 TiDB 上就是相对有难度的事情。除了上述些接入式和 SQL 适应性可能需要做些改造，应代码需要修改发布外，主要就是存量数据如何从 DDB 或 MySQL 录入 TiDB 了。个考虑点:

我们肯定不希望采期停服的迁移案， 最好数据能实时同步

并且肯定要考虑可随时回滚应以起到回滚数据库的的，因此要保证切换到 TiDB 后的增量数据还得实时回流原数据库集群，实现随时回滚切换回数据源的标。

要有定的灰度发布空间，以验证业务对 TiDB 的连接和使是否可。

经过些内部实践，我们充分利了内部现有具和 TiDB 配套具，相关需求前都是可并且得到定经验验证的:

我们通过持 DDB 分布式集群和 MySQL 单体集群的内部 CDC 具 NDC 同步全量数据标 TiDB 集群，并保持增量数据的持续实时同步。再通过 TiDB 提供的 TiCDC 订阅 TiDB 志，同步到 MySQL再通过标准 NDC 同步回 DDB。这样就实现了个双向实时复制的案。

NDC 是易内部研的多数据源迁移和 CDC 平台，可以类比 xdata+canal 的平台化产品

业务迁移的时候可能的步骤是:

前两个数据源双向同步核问题是没有冲突解决和循环复制解决机制，因此法实现全的双写，应当保持单数据源单写，这样案就是安全的。也是业务迁移步 骤最关键考虑点。

先准备好 DDB->TiDB 的实时同步，直到数据直追上。此并不开启 TiDB->DDB 的反向链路。

如果可能，业务灰度发布只读业务 TiDB，验证服务可性。

正式发布切换在低峰期，业务 DDB 集群禁写，同时暂停 DDB->TiDB 链路，开启 TiDB->DDB 反向链路，业务发布 TiDB 数据源版本。服务不可写时间仅发布期间。

如果上步顺利，则线上回归应后迁移基本成功。

如果切换数据源后发现任何问题，确定要回滚应和数据源解决，由于反向链路保证 DDB 同 TiDB 数据致，因此 TiDB 禁写，DDB 开写，应回滚即可。

另外，同些业务沟通过程中我们发现，前线上有量数据 ETL 或消息总线是依赖 DDB/MySQL 的 binlog 订阅的，因此 NDC 兼容 TiDB 也是必须的，我们采与切换相同案:

我们会先将 TiDB 志通过专具回放个中转 MySQL，再 NDC 订阅，保证原有数据链路基本不变。

近期 TiDB 相关业务应情况简介

这次我们的技术推实践并不是划划，是真的期望 TiDB 能为数据库技术和使效率带来些质变。

TiDB 近期已经或者即将上线在网易支付、网易云音乐的多个业务模块中，TiDB 的 HTAP、秒级 DDL、扩速扩缩容等能力也将不断提升用户体验。

总体来说，TiDB 在易内部的运还处于起步阶段。期以来我们直苦于在两个问题上纠结，先是 "有了 DDB 为什么还需要新的分布式系统" 以及 "HTAP 在哪些业务有价值"。经过些探索和努推，这两个问题的认识上我们有了些进展，也因此有了本。希望我们近期的作能够起到抛砖引的作，把数据库技术发展带来的能 提升真正落实到业务实际需求中去，提升易数据库服务和能平。也欢迎对 TiDB 相关技术感兴趣的团队与同学能够与我们 DBA 组保持积极沟通，家起来推动相关技术验证与应。