TiDB4PG之兼容Gitlab

谁践踏了优雅 2023-10-01 10:26 113阅读 0赞

### **前言** ###

在数据库流行度排名上，PostgreSQL 和 MySQL 都是名列前茅的存在，他们如此受欢迎，说明他们的优势非常强悍。虽然 PostgreSQL 和 MySQL 各有千秋，但是不免经常被用户拿来比较，想知道两者中谁更厉害，或者谁的缺点更不能被用户接受。就在最近，有一个人就爆出了对 MySQL 的不满。Oracle 前 MySQL 优化器团队成员 Steinar Gunderson，从 MySQL 团队离职时，强烈推荐用户考虑使用 PostgreSQL。这一举动在行业中炸开了锅， 用户对自己拥戴的产品各种维护，讨论尤为激烈。 Steinar Gunderson 在博客中的原句：

`MySQL is a pretty poor database, and you should strongly consider using Postgres instead.` `MySQL 是一款非常糟糕的数据库，强烈建议大家认真考虑使用 PostgreSQL。`

[Steinar H. Gunderson 博客blog.sesse.net/blog/tech/2021-12-05-16-41\_leaving\_mysql.html][Steinar H. Gunderson _blog.sesse.net_blog_tech_2021-12-05-16-41_leaving_mysql.html]

![d12cced540fdf4e5fcf0ce8f5fd93ded.png][]

![552c495159be6ecd451722a83761b86c.png][]

而且 Steinar Gunderson 指出：

`那些坚持认为一切都很好的人（似乎大多数MySQL用户和开发人员并没有真正使用其他数据库）`

没错，始终使用某一款数据库，不去尝试使用其他的数据库，就不会有对比，也就不会知道，可能有一款更适合自己的数据库产品，正在等着自己。所以在自己的认知中，对某一个数据库的崇拜，可能只是自己的无知或者是偏见。所以，不能先见为主，要保持开放的心态，更多的接纳新鲜事务，了解更多的数据库，才能更合理的挑选数据库产品。

而且，对数据库的选择，一定是要结合自身业务、结合实际场景来做选择的，能够最大程度发挥数据库的能力，扬长避短。没有完美的数据库，只有最适合自己的数据库。

最新数据库流行程度排行榜（如下图），我们可以看到，在开源数据库领域，虽然 MySQL 名列前茅， PostgreSQL 却是紧跟其后，稳稳的坐在了第四名的位置上。

![197999b1feec5b15af99d7bbf4ce953f.png][]

![1a4033e6bd0ed0f6059ffa44270eee82.png][]

毫无疑问，MySQL 还是当下最流行的开源数据库。但是，PostgreSQL 却是以极快的速度追向 MySQL，其增长之势迅猛无比。

![428f330c88387611da4a9c7229d759af.png][]

![2c846bd2f00747551064dad23a972585.png][]

### **Gitlab的抉择** ###

其实早在2019年，PostgreSQL 与 MySQL 就已经发生过剧烈碰撞了。

在2019年6月27日，Gitlab官方发布公告：要在 Gitlab 12.1以后的版本中，终止对MySQL 数据库的支持，并且解释了这么做的原因。

![9855dfb9abca581bae3d176e7ae29338.png][]

![a8f75ea3152df62eafcede1d9c9303d1.png][]

在这里说明一下，在 Gitlab 12.1之前的版本，是能够同时支持两款数据库的，分别是 MySQL 和 PostgreSQL 。Gitlab 12.1以后的版本只支持 PostgreSQL ，放弃了 MySQL，这一做法就像是个炸弹，在当时的数据库行业中爆炸。

那么，Gitlab为什么要这么做呢，我们一起来看一下。Gitlab 官方列举了几个 MySQL 不能满足 Gitlab 要求的地方：

![1912f8ba4537bbd8513450e7aed5cfd8.png][]

![16be2e2821ef6c89ec12c14dce15aa96.png][]

*  无法支持嵌套分组查询（[详情][Link 1]）
 *  必须使用黑科技来提升 MySQL 对列的限制，这将导致 [MySQL 拒绝存储数据][MySQL]
 *  MySQL [无法添加][Link 2] `TEXT` 类型字段的长度限制
 *  MySQL [不支持分区索引][Link 3]
 *  这些限制已经造成了许多MySQL不受支持的地方，还有类似 [Geo][]

当然，终止支持 MySQL 的举动，不仅仅是因为这几项 MySQL 的缺点，还因为Gitlab 创建了许多专门针对 MySQL 的代码，同时支持 MySQL 和 PostgreSQL 两个数据库，让开发团队工作量倍增，苦不堪言。虽然理由很充分，但是单纯从这个举动来看，可以发现，在数据库领域中，MySQL在某些特定的场景恐怕已经被 PostgreSQL 超越了。

而且更为重要的是，公告中说到：

`最近只有不到1200个GitLab实例报告其使用MySQL的情况。当时有110，000个实例使用PostgreSQL`

![24d90657efbcfa74bc4745f97b761928.png][]

![6159d7f61086dc67de138e6906c79c16.png][]

这是一个惊人的数字，在当时，Gitlab实例中，使用 PostgreSQL 数据库的占比已经高达98.92%，足以说明PostgreSQL 在用户心中的地位。

### **国产分布式数据库的崛起-TiDB** ###

TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

TiDB是国产分布式数据库，也是数据库领域国际范围内的顶级开源项目。现在，TiDB在国产数据库排行榜上稳坐榜首的位置。

![a464c07f3c549b3f77845ca372025b2c.png][]

![326a4a229bd40d3d0158e6d0f499a83f.png][]

![b7b2968c13d770c5b26d366dd88b1655.png][]

![b24098b675f6e831b63f1bef18d42dcb.png][]

TiDB到底有什么优势，可以夺得榜首呢？

官网给出了 TiDB 的五大核心特性，这也就奠定了TiDB数据库强大的基础：

*  一键水平扩容或者缩容
 *  金融级高可用
 *  实时 HTAP
 *  云原生的分布式数据库
 *  兼容 MySQL 5.7 协议和 MySQL 生态

基于这些特性，TiDB 目前在互联网、游戏、金融、大型企业等多个领域，拥有大量可靠的用户群体。而且，在 TiDB Lightning、Dumpling、TiDB Binlog、TICDC 等多种 TiDB 生态工具的加持下，让用户能够更加方便快捷的迁移数据，并快速上手使用 TiDB。

想要了解更多关于 TiDB 的信息，可以进入官网：[TiDB 简介 | PingCAP Docs][TiDB _ _ PingCAP Docs]

### **TiDB For PostgreSQL 的诞生** ###

神州数码在2017年开始接触TiDB，基于多年对 TiDB 的了解，深刻的体会到 TiDB 的过人之处。在实践中，TiDB也没有让我们失望，特别是高可用和无限水平扩展的能力，让我们刮目相看。

但是，TiDB 只支持 MySQL 协议，而我们公司内部许多历史系统都是以 PostgreSQL 作为数据库的。针对日益增加的数据，PostgreSQL 数据库早已成为了瓶颈。当我们想用分布式数据库进行优化的时候，却无从选择。于是，我们想到在 TiDB 源码的基础上进行重构，使其兼容 PostgreSQL ，为一些想要从 PostgreSQL 迁移到分布式数据库的系统提供便利，增加 TiDB 的业务范围，所以诞生了 TiDB For PostgreSQL。

更详细的 TiDB For PostgreSQL 起源、我们已经做过的兼容，可以查看下面这篇文章：

### **TiDB For PostgreSQL 与 Gitlab 的兼容** ###

我们已经在 TiDB4PG 中做了许多的工作，包括实现基本的PostgreSQL 通信协议、PostgreSQL 部分关键字和语法、PostgreSQL 系统表和系统函数等等。基本的 PostgreSQL 已经可以正常兼容，现在就缺少一个兼容对象了。

根据我们的调研，Gitlab 是一个非常理想的兼容对象：Gitlab 是一个开源项目，我们可以轻易的从代码层面着手，判断兼容问题；公司内部已经有本地搭建的 Gitlab 环境。根据调研，发现 Gitlab 使用的 SQL 中，大部分我们已经可以兼容。于是，我们正式开始使用 TiDB4PG 作为 Gitlab 的数据库的尝试。

使用 TiDB4PG 兼容 Gitlab，我们的初步计划是先搭建 Gitlab 12.1以前的版本（既可以使用 MySQL，又可以使用 PostgreSQL ），利用抓包工具把Gitlab 与 数据库通信的 SQL 语句统计出来。根据这些 SQL 语句，我们能轻易的判断，哪些语句可以兼容，哪些语句中的关键字或者是系统表等等是需要我们继续兼容的。等到完全兼容所有的SQL 语句的时候，我们应该可以初步兼容 Gitlab 了。

方案定制完成，接下来开始实施。想着方案实施应该会非常的顺利的，没想到第一步就遇到了问题。

#### **一、Gitlab 源码搭建** ####

本来用源码搭建 Gitlab 环境还是很顺利的。在官网能够找到部署流程，按照流程做就可以部署成功。可是好巧不巧的，在拉取依赖的时候出现了一个报错：

![927f4e0ba81dd76752438fc1a020cdad.png][]

![6c690678414db165a6c59e20558f9ab5.png][]

这是什么情况？于是我去查阅了相关信息，发现这是因为 mimemagic 中的许可证冲突了，所以作者下架了冲突版本的 mimemagic，并更新了修复之后的 mimemagic。Ruby on rails 是根据 gemfile 文件来安装依赖的，所以我在 gemfile中 修改 mimemagic 的版本号，尝试使用更新版本的 mimemagic 来代替旧版，可是，因为新版依赖与旧版差别较大，导致更新版本后，其他依赖都需要去同步升级，牵扯很大，所以这个办法无法进行下去。

通过升级版本无法解决，就需要换个思维。我想到 gemfile 中，都是以 "gem <名称>,<版本号>"来安装依赖的，但是 gem 可以写成 “gem <名称>, github: ‘<github中项目地址>’, branch: ‘分支名’” 来直接编译源码进行安装。所以我只需要找到github中的相关源码就行。于是我在 github 中检索到0.3.2的源码项目了：‘LaSoftRepo/mimemagic-0.3.2’，替换到gemfile中：

![e1c705261bc3fbed3c10e4fb2411917d.png][]

![aa9573ada4a2b9411883cc752b943550.png][]

果然，可以正常拉取依赖了。之后的步骤都非常顺利，配置好各种参数后，就搭建好了 Gitlab 环境，并且可以在浏览器正常访问和使用了。

#### **二、SQL 抓取** ####

部署好了 Gitlab 之后，我们就要开始抓取 SQL 语句了。我们修改了 Gitlab 的配置，让 Gitlab 连接到了另一个机器的 PostgreSQL 数据库上，然后开始抓包。首先抓包的场景是 Gitlab 对于数据库的初始化，包括库中的各种表结构和初始数据。接着我们又抓取了几个场景的SQL语句：用户登录、查看项目、查看分支、创建分支、删除分支和用户退出。在这些场景中，我们抓到了大量SQL语句：

# 部分SQL语句
    SET client_encoding TO 'UTF8';
    SET client_encoding TO 'unicode';
    SELECT t.oid,t.typname FROM pg_type AS t WHERE t.typname IN ( 'int2', 'int4', 'int8', 'oid', 'float4', 'float8', 'bool' );
    SHOW TIME ZONE;
     
    SELECT  c.relname FROM  pg_class c  LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE n.nspname = ANY (current_schemas ( FALSE )) AND c.relkind IN ( 'r', 'v', 'm', 'p', 'f' );
     
    SELECT
        a.attname,
        format_type ( a.atttypid, a.atttypmod ),
        pg_get_expr ( d.adbin, d.adrelid ),
        a.attnotnull,
        a.atttypid,
        a.atttypmod,
        c.collname,
        col_description ( a.attrelid, a.attnum ) AS COMMENT
    FROM
        pg_attribute a
        LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid
        AND a.attnum = d.adnum
        LEFT JOIN pg_type t ON a.atttypid = t.oid
        LEFT JOIN pg_collation c ON a.attcollation = c.oid
        AND a.attcollation <> t.typcollation
    WHERE
        a.attrelid = '"geo_nodes"' :: regclass
        AND a.attnum > 0
        AND NOT a.attisdropped
    ORDER BY
        a.attnum;
     
    SHOW max_identifier_length;
     
    SELECT  1 AS one FROM   "geo_nodes" LIMIT 1;
     
    SELECT  "shards"."name" FROM    "shards";
    
    SELECT  1 AS one FROM (SELECT "namespaces".* FROM "namespaces" INNER JOIN "members" ON "namespaces"."id" = "members"."source_id" WHERE "members"."type" IN ('GroupMember') AND "members"."source_type" = 'Namespace' AND "namespaces"."type" IN ('Group') AND "members"."user_id" = 2 AND "members"."requested_at" IS NULL AND "members"."access_level" = 50
    UNION
    SELECT "namespaces".* FROM "namespaces" INNER JOIN "members" ON "namespaces"."id" = "members"."source_id" WHERE "members"."type" IN ('GroupMember') AND "members"."source_type" = 'Namespace' AND "namespaces"."type" IN ('Group') AND "members"."user_id" = 2 AND "members"."requested_at" IS NULL AND "members"."access_level" = 40
    UNION
    SELECT "namespaces".* FROM "namespaces" WHERE "namespaces"."type" IN ('Group') AND "namespaces"."id" IN (WITH RECURSIVE "base_and_descendants" AS (SELECT "namespaces".* FROM "namespaces" INNER JOIN "members" ON "namespaces"."id" = "members"."source_id" WHERE "members"."type" IN ('GroupMember') AND "members"."source_type" = 'Namespace' AND "namespaces"."type" IN ('Group') AND "members"."user_id" = 2 AND "members"."requested_at" IS NULL AND "members"."access_level" = 30
    UNION
    SELECT "namespaces".* FROM "namespaces", "base_and_descendants" WHERE "namespaces"."type" IN ('Group') AND "namespaces"."parent_id" = "base_and_descendants"."id") SELECT "id" FROM "base_and_descendants" AS "namespaces") AND ("namespaces"."project_creation_level" = 2 OR "namespaces"."project_creation_level" IS NULL)) namespaces WHERE "namespaces"."type" IN ('Group') LIMIT $1;
     
    SELECT  "namespaces".* FROM "namespaces" WHERE "namespaces"."owner_id" = $1 AND "namespaces"."type" IS NULL LIMIT $2;
     
    SELECT "feature_gates".* FROM "feature_gates" WHERE "feature_gates"."feature_key" = $1;
     
    SELECT  "user_statuses".* FROM "user_statuses" WHERE "user_statuses"."user_id" = $1 LIMIT $2;

#### **三、兼容性判断** ####

我们把抓出来的大量 SQL 语句进行整理，找出还未与 TiDB4PG 兼容的部分，单独记录，大致分为一下几类：

1.  TiDB4PG 的飘号与 PostgreSQL 的双引号  
    在 TiDB4PG 中，表名和字段名都是使用飘号括起来的，而 PostgreSQL 中，是用双引号括起来的。
2.  :: 符号，类型转换符号  
    在 PostgreSQL 中，大量使用了:: 符号，而 TiDB4PG 中并没有这种写法。  
    ::regprocedure  
    ::regclass  
    ::regclass::text  
    ::integer  
    ::regtype  
    ::oidvector
3.  系统表（包括数据），系统函数，系统变量  
    PostgreSQL 中的一些系统表、系统函数、系统变量，在 TiDB4PG 中并不存在或不够完整，比如：  
    \#系统变量  
    standard\_conforming\_strings  
    timezone  
    client\_encoding  
    client\_min\_messages  
    max\_identifier\_length  
    search\_path  
    WITH  
    RETURNING  
      
    \#系统函数  
    pg\_get\_expr  
    generate\_subscripts  
    current\_schemas  
    format\_type  
    col\_description  
    array\_in
    
    \#系统表  
    pg\_type  
    pg\_class  
    pg\_index  
    pg\_namespace  
    pg\_attribute  
    pg\_attrdef  
    pg\_range

#### **四、成功兼容 Gitlab** ####

TiDB4PG 不支持的部分内容已经被找到，接下来要做的就是去兼容它们。

我们通过继续重构 TiDB 的源码，使 TiDB4PG 能够更好的兼容 Gitlab。其中，我们也使用了临时表来代替了某些功能的实现，以便更快的看到 TiDB4PG 兼容 Gitlab 的效果。

在小伙伴们没日没夜的不懈努力中，我们成功的使用 TiDB4PG 作为 Gitlab 的数据库，启动了 Gitlab 程序，并且可以正常访问 Gitlab 主页。

![bb41b1e40aba70738be92554d96d67d5.png][]

![2033e6c15aeda244948df7ea14156f18.png][]

能够登录到 Gitlab 主页之后，我们都非常开心，自己的努力有了一个初步的结果。于是我们乘胜追击，继续兼容 TiDB4PG 不支持的部分内容。

截止到目前，我们已经可以使用 TiDB4PG 兼容 Gitlab 的几个场景了：用户登录、查看项目、查看分支、创建分支、删除分支和用户退出。

![0b64141d342d2c2fa85626f02fdf2134.png][]

![5d1ebb4f2ce84f3271b1fcab9106b074.png][]

### **展望未来** ###

这是 TiDB4PG 兼容的第一个项目，非常的有意义。就目前而言，TiDB4PG 还是有很多不完善的地方，还是有很多的路要走。但是 TiDB4PG 已经开源，希望大家对 TiDB4PG 有信心，并且能够和我们一起，让 TiDB4PG 更加完善，更加强大。

我们接下来的要努力实现的方向：

*  PostgreSQL 关键字和语法
 *  PostgreSQL 数据库结构
 *  PostgreSQL 系统表和系统函数
 *  PostgreSQL 权限管理
 *  部署运维相关的工具

下面是我们的邮箱以及github链接，感兴趣的同学可以与我们联系，交流自己的想法和建议。

[dc.opensource@yungoal.com][dc.opensource_yungoal.com]

[Steinar H. Gunderson _blog.sesse.net_blog_tech_2021-12-05-16-41_leaving_mysql.html]: https://link.zhihu.com/?target=https%3A//blog.sesse.net/blog/tech/2021-12-05-16-41_leaving_mysql.html
[d12cced540fdf4e5fcf0ce8f5fd93ded.png]: https://img-blog.csdnimg.cn/img_convert/d12cced540fdf4e5fcf0ce8f5fd93ded.png
[552c495159be6ecd451722a83761b86c.png]: https://img-blog.csdnimg.cn/img_convert/552c495159be6ecd451722a83761b86c.png
[197999b1feec5b15af99d7bbf4ce953f.png]: https://img-blog.csdnimg.cn/img_convert/197999b1feec5b15af99d7bbf4ce953f.png
[1a4033e6bd0ed0f6059ffa44270eee82.png]: https://img-blog.csdnimg.cn/img_convert/1a4033e6bd0ed0f6059ffa44270eee82.png
[428f330c88387611da4a9c7229d759af.png]: https://img-blog.csdnimg.cn/img_convert/428f330c88387611da4a9c7229d759af.png
[2c846bd2f00747551064dad23a972585.png]: https://img-blog.csdnimg.cn/img_convert/2c846bd2f00747551064dad23a972585.png
[9855dfb9abca581bae3d176e7ae29338.png]: https://img-blog.csdnimg.cn/img_convert/9855dfb9abca581bae3d176e7ae29338.png
[a8f75ea3152df62eafcede1d9c9303d1.png]: https://img-blog.csdnimg.cn/img_convert/a8f75ea3152df62eafcede1d9c9303d1.png
[1912f8ba4537bbd8513450e7aed5cfd8.png]: https://img-blog.csdnimg.cn/img_convert/1912f8ba4537bbd8513450e7aed5cfd8.png
[16be2e2821ef6c89ec12c14dce15aa96.png]: https://img-blog.csdnimg.cn/img_convert/16be2e2821ef6c89ec12c14dce15aa96.png
[Link 1]: https://link.zhihu.com/?target=https%3A//gitlab.com/gitlab-org/gitlab-foss/-/issues/30472%23note_27747600
[MySQL]: https://link.zhihu.com/?target=https%3A//gitlab.com/gitlab-org/gitlab-ce/issues/49583
[Link 2]: https://link.zhihu.com/?target=https%3A//gitlab.com/gitlab-org/gitlab-ce/issues/40168
[Link 3]: https://link.zhihu.com/?target=https%3A//dba.stackexchange.com/questions/106589/to-have-postgresql-like-partial-index-in-mysql-5-5
[Geo]: https://link.zhihu.com/?target=https%3A//gitlab.com/gitlab-org/gitlab-ce/merge_requests/11914/diffs
[24d90657efbcfa74bc4745f97b761928.png]: https://img-blog.csdnimg.cn/img_convert/24d90657efbcfa74bc4745f97b761928.png
[6159d7f61086dc67de138e6906c79c16.png]: https://img-blog.csdnimg.cn/img_convert/6159d7f61086dc67de138e6906c79c16.png
[a464c07f3c549b3f77845ca372025b2c.png]: https://img-blog.csdnimg.cn/img_convert/a464c07f3c549b3f77845ca372025b2c.png
[326a4a229bd40d3d0158e6d0f499a83f.png]: https://img-blog.csdnimg.cn/img_convert/326a4a229bd40d3d0158e6d0f499a83f.png
[b7b2968c13d770c5b26d366dd88b1655.png]: https://img-blog.csdnimg.cn/img_convert/b7b2968c13d770c5b26d366dd88b1655.png
[b24098b675f6e831b63f1bef18d42dcb.png]: https://img-blog.csdnimg.cn/img_convert/b24098b675f6e831b63f1bef18d42dcb.png
[TiDB _ _ PingCAP Docs]: https://link.zhihu.com/?target=https%3A//docs.pingcap.com/zh/tidb/stable/overview/
[927f4e0ba81dd76752438fc1a020cdad.png]: https://img-blog.csdnimg.cn/img_convert/927f4e0ba81dd76752438fc1a020cdad.png
[6c690678414db165a6c59e20558f9ab5.png]: https://img-blog.csdnimg.cn/img_convert/6c690678414db165a6c59e20558f9ab5.png
[e1c705261bc3fbed3c10e4fb2411917d.png]: https://img-blog.csdnimg.cn/img_convert/e1c705261bc3fbed3c10e4fb2411917d.png
[aa9573ada4a2b9411883cc752b943550.png]: https://img-blog.csdnimg.cn/img_convert/aa9573ada4a2b9411883cc752b943550.png
[bb41b1e40aba70738be92554d96d67d5.png]: https://img-blog.csdnimg.cn/img_convert/bb41b1e40aba70738be92554d96d67d5.png
[2033e6c15aeda244948df7ea14156f18.png]: https://img-blog.csdnimg.cn/img_convert/2033e6c15aeda244948df7ea14156f18.png
[0b64141d342d2c2fa85626f02fdf2134.png]: https://img-blog.csdnimg.cn/img_convert/0b64141d342d2c2fa85626f02fdf2134.png
[5d1ebb4f2ce84f3271b1fcab9106b074.png]: https://img-blog.csdnimg.cn/img_convert/5d1ebb4f2ce84f3271b1fcab9106b074.png
[dc.opensource_yungoal.com]: mailto:dc.opensource@yungoal.com