共计 2995 个字符，预计需要花费 8 分钟才能阅读完成。
一、TiDB4PG 的诞生
在去年的时候，咱们开启了一个小我的项目，基于国内比拟火的开源分布式数据库 TiDB 进行革新。TiDB 自身是高度兼容 MySQL 协定，你能够在应用 TiDB 的时候将其视作 MySQL，根本的语法，性能，包含一些 MySQL 的生态工具都能够间接应用。所以咱们想将一些企业应用搬迁到 TiDB 上享受分布式数据库带来的劣势，然而企业级的利用上层数据库不仅仅只有 MySQL，还有 PgSQL 和 Oracle 等其余数据库，这使得迁徙工作量非常宏大。为此咱们更心愿 TiDB 也可能兼容其余的罕用数据库协定，例如 PgSQL，于是咱们创立了 TiDB4PG 的开源我的项目。
TiDB for PostgreSQL 是咱们基于 TiDB 源码批改的一款满足 PostgreSQL 协定的数据库。为了让基于 PostgreSQL 的零碎可能在不批改自身业务代码的前提下，疾速的迁徙到分布式数据库上。
对于 TiDB4PG 的具体背景文章可翻阅 https://zhuanlan.zhihu.com/p/…
二、降级过程
TiDB4PG 最后开始做的时候，抉择的是过后比拟新的版本 4.0.11，也是咱们用的比较稳定的一版。然而万万没想到，TiDB 版本迭代速度，远超乎咱们的设想，一年不到，TiDB 版本就给推到 5.3 了。在 5.3 的版本，TiDB 自身的性能和性能都有肯定的晋升，所以多方面考略后，所以多方面的思考下，咱们决定将 TiDB4PG 中的 TiDB 版本升级到 5.3（刚降级完一天不到，TiDB 推出了 5.4 版本）。
最早在改代码的时候就思考过降级的问题，基于 TiDB 对于 PgSQL 的协定兼容的开发，对于 TiDB 自身代码的入侵是十分大的，整个协定层都得替换掉，Session 这一块做的改变较多，同时也会影响到打算的结构和执行。次要还是数据库系统自身的耦合非常的高，整个改变下来，并不是写几个包去替换一下就能解决的，所以被咱们批改后的分支，再想要去把 TiDB 主分支合过去，是十分困难的。
当然，我也是尝试了一下，强行将 5.3 的代码 Merge 到 TiDB4PG，从上面图中能够看到，有 2959 个文件的更改，其中存在抵触的文件有上百个，这要一个一个修复起来，工作量能够说是十分的大。
在衡量一段时间后，咱们最终决定用一个更为简略的办法来实现这一次的降级，那就是在 TiDB 5.3.0 版本代码上将咱们 TiDB4PG 实现的代码再从新实现一次。
这种办法的工作量就大大减小了，一是因为 TiDB4PG 中改变的代码都是一块一块的，能够间接复制搬运过来应用。二是 TiDB 代码尽管迭代快，常常重构，但就协定和较下层的代码改变要少很多，所以搬运时，简略看一下搬运地位的代码改变，解决抵触就能够胜利跑通。
并且这一次降级，咱们把和 PgSQL 相干的代码都抽出来做了独自的文件进行寄存，不便前期代码的学习和保护。
三、性能测试
对于降级之后的 TiDB4PG 5.3.0 版本，咱们做了相干的性能比照测试，将 TiDB 4.0.11，TiDB4PG 4.0.11，TiDB 5.3.0 和 TiDB4PG 5.3.0 四个版本再对立的集群配置与硬件环境进行 Sysbench 压测，次要目标依然是确保，降级之后的 TiDB4PG 在性能上与 TiDB 5.3.0 保持一致，同时也顺带测试了 TiDB 5.3.0 版本比照 4.0.11 版本性能有多少的晋升。
咱们拿了 read, insert 和 update 蕴含读写的三种脚本简略的跑了四个版本的性能压测比照，色彩对应 TiDB 4.0.11(蓝色)，TiDB 5.3.0(绿色)，TiDB4PG 4.0.11(黄色)，TiDB4PG 5.3.0(红色)。当然这个比照不是为了测试几个版本的性能极限等，重点是测试性能的比照和绝对的晋升，所以具体的 QPS 和 TPS 数据不具备任何意义。通过比照图，可能很清晰的看进去，5.3.0 版本整体较 4.0.11 的性能晋升有 20%-40%，并且 TiDB 和 TiDB4PG 在雷同版本下性能都是差不多的，所以兼容的代码改变对于性能上简直没有影响。
四、数据迁徙
实现了 TiDB4PG 4.0.11 到 5.3.0 版本的降级，就存在一个问题，之前集群的数据，如何齐全迁徙到 5.3.0 版本的集群中？
首先须要明确一点的是 TiDB 的整体架构，一共是有三个次要组件：TiDB-Server, PD-Server 和 TiKV-Server, 而 TiDB4PG 的革新仅仅只批改了 TiDB-Server 的代码逻辑，也就是 SQL 解决层逻辑。那么最重要的点在于，大家都理解 TiDB-Server 是无状态的，同理，TiDB4PG-Server 自身也是无状态的。
依据这一点，在 TiDB4PG 的集群中，TiDB-Server 和 TiDB4PG-Server 是能够共存的，你既能够应用 TiDB4PG 的 PG 协定和解决层反对，同样也能够应用 TiDB 的 MySQL 协定层。
所以在数据迁徙和备份的策略中，你能够应用 TiDB 本来就反对的逻辑备份工具和物理备份工具。例如 Dumpling&Lightning 和 Backuo&Restore。这两个工具是通过测试验证的，然而倡议应用逻辑备份，因为在测试 BR 的过程中，咱们遇到了版本问题，须要先用 BR v4.0 备份 4.0.11 的集群，再用 BR v5.0 复原到 5.3 的集群中，操作比较复杂。通过咱们的迁徙教训，也如下面的剖析所言，TiDB4PG 集群从某种意义上同样是一个 TiDB 集群，如果在 TiDB4PG 集群中启动一个 TiDB-Server 节点，就能够兼容很多 TiDB 生态工具。甚至如果某些生态工具是间接跳过 TiDB-Server，拜访 PD-Server 或者 TiKV-Server，那么实践上都是能够间接应用的。所以像 DM，Binlog 和 TiCDC 这一类工具都是能够在 TiDB4PG 集群中应用的，当然这些目前还没有进行理论测试。
五、总结 通过下面剖析，整体在 TiDB4PG 从 v4.0.11 降级到 v5.3.0 一共有两个方面晋升，性能和性能，简略列举一下 TiDB4PG v5.3.0 较 4.0.11 晋升的几点：
读写性能有 20% – 40% 的进步。
对公共表达式的反对（CTE）。
对于其余排序规定的反对，5.x 后的版本对于排序规定的反对更多了。
对于长期表的反对，之前解决办法就是单纯的创立一个实体表存放数据，最初删掉。
表达式索引，尽管目前反对的比较简单，但有总比没有好！
除此之外还有一些其余的细节晋升，这里不做一一列举，能够查阅 TiDB 官网文档来理解 TiDB 5.3.0 的版本细节。
最初 TiDB4PG 对于 TiDB 的反对总算是降级到 5.3，然而 TiDB 版本又降级到了 5.4，很难说再过个多少天 6.0 的版本忽然就公布了，所以咱们也是常常探讨，这次降级完了，下一次怎么办？随着 TiDB4PG 分支和 TiDB 主支的差别越来越大，每一次合并降级都是一件非常苦楚的事件。所以咱们还是心愿可能再找一个更好的办法来实现降级。当然降级也并不都是苦楚的事件，降级实现之后，看到新的性能和性能，还是非常开心的，毕竟 TiDB 本人的性能越丰盛，咱们兼容路上的坑就会少很多。所以还是很期待 TiDB 可能一路高歌猛进，有着更加弱小的性能和性能。
TiDB4PG：DigitalChinaOpenSource/TiDB-for-PostgreSQL: PgSQL compatible on distributed database TiDB (github.com)