作者介绍：李文杰，网易互娱高级数据库工程师，TUG 2019 年度和 2020 年度 MVA。主要负责大数据研发和数据分析工作，为产品提供精细化运营指导；同时在部门内推广使用 TiDB，为业务上云及数据库分布式化积累经验和探索最优方案，目前是 TiDB 管理小组负责人。
本文整理自 TUG 网易线上企业行活动，由网易游戏高级数据库工程师李文杰老师分享，主要介绍分布式数据库 TiDB 在网易游戏的应用实践经验。
网易游戏最开始引入 TiDB 是从 AP 的角度来进行使用的。在第一次使用 TiDB 时，我们把跑批业务这种计算量比较大的任务迁移到 TiDB 上面。在迁移过程中，如果跑的任务量比较大，相信很多人会遇到 “transaction too large” 报错这个问题。
TiDB 事务限制
经过一番排查发现，由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，TiDB 对事务的大小做了限制，具体限制的内容有单事务的 SQL 语句数、KV 键值对数目和大小、单 KV 键值对大小等。
知道这个限制后，我们就可以找到了解决办法，即
把大的事务按业务的需求切分为多个小事务分批执行，这样之前跑失败的 SQL 就能成功运行了，而且在 MySQL/Oracle 中的跑批程序，也都成功迁移到了 TiDB。
同时，我们不得不思考，在没有问题的时候，程序可以跑得非常顺畅，但是当机房中出现网络问题，或是出现其他的故障时，就会出现一部分数据写入到了 TiDB 中，而另外一部分数据是没有写入的。在场景中的表现是一个事务的执行没有能够保证其原子性，只执行了其中一部分，有一部分成功，有一部分失败了。
经排查发现，这是因为我们手动开启了事务切分，这种情况下大事务的原子性就无法保证，只能保证每个批次的小事务原子性，从整个任务的全局角度来看，
数据出现了不一致。
那么该如何解决这个问题呢？
TiDB 大事务优化
通过向官方反馈问题之后，TiDB 4.0 对大事务进行了深度优化，不仅取消了一些限制，而且将单事务大小从 100MB 直接放宽限制到 10GB，直接优化了100 倍。但与此同时也带来了另一个问题，在进行 t+1 的跑批业务时，前一天可能会有几百甚至上千万的数据量，如果用程序 JDBC+TiDB 方式处理，效率其实不高，处理时长往往需要持续数小时，甚至几十小时以上。
那么该如何提高计算任务的整体吞吐量？答案是 TiSpark。
TiSpark：高效处理复杂 OLAP 计算
TiSpark 是在 Spark 基础上开发的一个插件，它可以高效地从 TiKV 读取数据。同时支持索引查找和计算下推策略，有很高的查询性能。我们在实践过程发现，使用 TiSpark 读取 TiKV 的方式，5 分钟可以完成 2 亿行数据读取。同时它也有很高的写入性能。有了 TiSpark，我们可以直接通过 Spark 工具访问 TiKV 数据。经过时间证明，
TiSpark 读、写 TiKV 都有着非常好的性能表现，通过 TiSpark 我们可以处理比较复杂、数据量比较大的运算。
TiSpark 实践
在实践中，使用 TiSpark 主要有两种方式：
-
方式一：TiSpark + JDBC 写入
TiSpark + JDBC 写入方式能够自动切分大事务，但不一定能保证事务的原子性和隔离性，且故障恢复时需要人工介入。这种方式写入速度可以达到 180 万行/min，通过 TiDB 处理 SQL 再写入 TiKV，速度一般。
-
方式二：TiSpark 批量写入 TiKV
TiSpark 批量写入 TiKV 不会自动切分大事务。通过 TiSpark 直接读写 TiKV，相当于直接通过大事务读写 TiKV 的数据，可以保证事务的原子性和隔离性，同时拥有良好的写入性能，写入速度可以达到 300 万行/min。经过 TiSpark 的应用，解决了我们大数据量批处理任务的问题，但是也存在一定的隐患。TiSpark 在进行读、写 TiKV 的时候，由于 TiKV 是作为整个 TiDB 架构的存储引擎，如果存储引擎层的数据读写压力大，对于线上的其他业务将会产生明显的影响。此外，在 TiSpark 读写 TiKV 时，如果没有对 IO 进行限制，很容引发性能抖动，导致访问延迟上升，也会对其他线上业务产生影响。
怎么样才可以做到有效隔离?或许 TiFlash 列式存储引擎能提供答案。
TiFlash：列式存储引擎
TiFlash 作为 TiKV 行式存储引擎的补充，它是 TiKV 数据的 raft 副本，TiFlash 作为在 TiKV 基础上的列式副本，经过 raft 协议保证数据同步的一致性和完整性。这样同样的一份数据就可以存储在两个存储引擎里面。TiKV 保存的是行存数据，TiFlash 保存的是列式数据。
在做 Spark 的计算分析时，我们可以直接从 TiFlash 集群进行读取，计算效率会非常高。用列式数据做 AP 分析，对于行式数据来说，简直就是降维打击。
TiFlash：TPC-H 性能分析
TiSpark + TiFlash 的结合应用使计算效率取得了量与质的提升。TPC-H 性能分析显示，在与 TiKV 的横向对比中，几乎全部 query 场景下 TiFlash 执行效率都高于 TiKV，且部分场景的效率远高于 TiKV 。用了 TiFlash 以后，
既不影响 TiKV 的集群性能，也不影响线下的集群业务，而且在做离线大数据分析时，依然能够保持很好的性能与吞吐量。
经过实践证明，TiFlash 可以解决我们的诸多问题，是非常棒的一个工具。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70014851/viewspace-2867432/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
