TDSQL PG 版企业级分布式数据库技术创新实践

TDSQL PG 版产品介绍

TDSQL PG 版经过十余年打磨大概可以分为以下几个阶段，第一个是单机时代引入 PostgreSQL 做为腾讯大数据平台 TDW 的一个补充，弥补了小数据量分析能力不足。随着业务发展，单机瓶颈逐步凸显，促使团队推出了更具有扩展性的 SQL 和兼容 V1 版本，并在 2015 年上线微信支付系统。

此外，TDSQL PG 版提前布局我们 ToB 市场，在 V2 版本支持三权分立，加密透明等安全特性，并在 2018 年拿下数字广东和云南公安等多个标杆客户。TDSQLV3 主要定位 HTAP，在 2019 年上线 PICC 核心业务，直到去年发布 V5 版本，主要是为了去 O，内核具备去 O 和读写分离能力，同时上线的运营商用户还有保险系统。

本次主要分享 V5 这一块。TDSQL PG 版是基于腾讯及 PostgreSQL 开源的自主分布式 HTAP 国产数据库，其全面兼容 PostgreSQL，高度兼容 Oracle 语法，产品采用无共享架构，在提供数据仓库处理的能力的同时，还能支持完整的事物分布式 ACID 能力。

TDSQL PG 版整体能力，从支持上来说它的支持的接口比较丰富，比如 libpq 里面 C 、C++，Jdbc/odbc、Python、Ecpg，各种常用语言接口都是支持的，同时它也支持用户自定义函数操作服务。很多企业用户关心的数据安全方面，TDSQL PG 版是用三权分立安全体系，支持数据脱敏同时还有加密功能，并且支持多种国密算法。

作为一个 HTAB 数据库，我们支持千万级 TPS 事务处理，全并行分布式计算框架，可以让业务高效完成 OLAP 计算。在数据治理方面，可以支持在线扩缩容，用户无感知数据 Rebalance，使用透明的冷热数据分离来减少用户业务成本。此外，我们还支持多种窗口分析常函数，并且高度兼容 Oracle 常见语法。

针对 TDSQL PG 版适用场景从两个方面来看，一是业务特征，如果业务满足这些特征，比如在数据量上 OLAP 超过 1 个 T，OLAP 超过 5 个 T 或者并发链接达到 2000 以上，业务峰值每秒 100 万笔左右，同时还必须要有一个分布式的水平扩展能力，需要 OLTP 和 OLAP（03:55 英）混合场景，并且需要严格的事务保证，那么 TDSQL PG 版是很适合的。第二是业务场景，比如说 TDSQL 在地理信息系统，高并发实时计算方面，比如说 Oracle 兼容都是一个非常好的选择。

TDSQL PG 版架构

下面介绍 TDSQL PG 版整体架构。GTM 全局事务管理器，它是全局的事务信息的管理节点并且管理全局对象。Coordinator 协调节点，主要是业务访问的入口，CN 节点中每个节点都是对等的，也说访问三个节点中任何一个它的结果都是一样的。图中下层是一个数据节点，数据节点是实际处理数据的一些地方，每个数据节点都会有一份本地的原数据，并且还有一些本地数据分片，中间数据交互总线也会把所有的节点有机联合起来，负责整个集群中所有的数据交互。最左边我们的管控系统，就负责我们节点的资源分配、高级安全审计、数据治理、扩容等运维能力。

下面对重点能力进行介绍。首先我们今年支持了一个多引擎、支持集中式和部署模式还有分布式部署模式，其中集中式部署模式和单机 PostgreSQL 相同，没有分布式开销的，并且支持一组多备的部署模式和两地三中心，都具有完备的 Oracle 兼容能力。在金融或运营商保险这种场景中，可以达到 98%兼容性。并且在业务需要扩容时，都可以无缝扩展成分布式集群。

从集中式扩展到分布式，我们拥有完整的 ACID 能力，并且在分布式场景，也支持分部件更新全局索引，可以极大减少我们业务，进行一些分布式适配的改造量。并且在分布式场景中，TDSQL PG 版也支持提供高性能 OLAP 能力，能够支持业务做分类型查询工作。

TDSQL PG 版同时支持集中式和分布式，集中式与分布式支持完整的 ACID，其中分布式事务，是基于 GTS 提供的 MVCC 并发控制逻辑，这里一个核心点是 GTS 时间戳，是由 GTS 集群进行提供。

GTS 集群是从零开始单向递增的逻辑时钟，通过硬件提供足够稳定保障，并且是单向递增，我们利用这个特性来进行高性能分布式事务。而 GTS 对硬件没有要求，可以通用服务器来做 GTM 节点，同时 GTS 本身可以通过流复制来保证可靠性。在性能方面，在 24 核服务器能够处理 1200 万的 QPS，几乎可以满足所有场景的需要。

TDSQL PG 版性能

TDSQL PG 版在全并行计算方面。我们的并行能力分为三个层级：

一是节点级并行，所谓节点级并行是系统拿到一个查询后，会把查询下发给不同的 DN，并且通过 DN 之间的分片查询节点级并行。

二是进程中并行，在执行器拿到算子以后，把它算子并行化，允许多个 CPU 同时用资源来完成查询工作。

三是通过指令级，比如可以通过特殊的 CPU 指令，SIMD 指令，进行算术运算等，来提升计算效率。

今年新增另一特性全局索引，要知道如果在分布式设计中，表配置非分布键性能它比分布键性能差距是比较大的。举个例子，比如说分布键是其它键，那这里用一个非分布键，比如说 Mike 这个名称。

由于这个键它不是我们的分布键，数据库其实不知道它在到底存储到哪个节点。那这样我们就需要在节点上，比如说 DN1、DN2、DN3 都需要扫描。假设我这条数据只有一条，是多了很多无用扫描，特别是你节点数越来越多时。当然有了全局索引时，相当于有一个全局索引来存储 MAC 这条记录对应的存储节点，那这样就可以比较快的去找到这一个节点。并且随着节点数的增多，性能也是稳步提升。

这里需要一个全局事务来保证我们的全局索引，保证数据表之间的一致性。可以看一下右下角这个图，蓝色是非分布键的索引，黄色的是分布键，灰色的是全局索引。可以看到相对于非全局索引它的提升还是很大的。相对于我们的分布键查询，它的性能是比较接近的。全局索引的高性能还可以用在外键或者全局唯一约束上，这样可以极大减少业务的分布式改造成本。

这里还有一个特性就是透明压缩，也就是支持数据库透明压缩能力，这个是完全对业务透明的。通过简单的 Alter table，可以把一个表直接压缩成它的 1/3，或者它的 1/4、1/5。然后从左边的图可以看到透明压缩主要存储层工作，页面在落盘的时候，调用指定的一个压缩算法，然后存储在对应文件系统里面来减少磁盘空间。

当业务需要使用一个页面读取出去时，我们会在内存里进行解压，供业务来使用。下面是 TPCC 模型测试结果。可以看到一个磁盘压缩率大概是降低了 70%左右，CPU 大概是增加 20%，因为要花额外 CPU 去做压缩，性能 TPCC 查询性能是降 28%的。这样我们比较推荐是这张表对存储敏感会比较适用一些。

另外我们支持全面的循环校验。这是对磁盘损坏的保障方案。我们都知道磁盘坏块概率是比较低的，但是随着业务量增长，集群数、服务器数增多，它会成为一个必然的事件。TDSQL PG 版支持全流程校验，例如定期全量校验，主动实施故障探测，故障阻断，在故障发现之后，会自动发起增量修复去完成副本的修复。在这样一个手段中，可以保证坏块不会扩散到冷备还有备机，相当于病毒一样，不能让它扩散到所有副本上。

在表还有我们的一个数据中，维护了一个块级别的 CRC 信息，从介质里面读取的时候我们可以校验一下来做数据保护。最后来说当故障发生时，做数据储备转换时，可以保证在数据正确情况下，第一时间恢复业务，再异步修复流程。通过备份或者说冷备中，来拿取受损页面推进修复。在线修复可以通过可用的副本来进行，没有可用副本才会从冷备中拉取。

另外一点 Direct IO 因为 Page Buffer 问题，导致内存的利用率并不高，并且在某些情况下容易引起性能波动。TDSQL PG 版是支持 Direct IO，经过测试可以提高内存的使用率。并且在 TPCC 测试，它的波动是更加平稳的，也就是说它能够提高业务稳定性。在新版本中，我们支持多种定位视图，一是全局事物视图，支持全局链接管理。第二是我们内存占用视图，可以对当前内存使用量进行一些统计。

用户案例

接下来是我们的经典用户案例。TDSQL PG 版是在 2015 年，替换微信支付的分库分表系统上线，支撑微信支付从 500 万笔到 1000 万再到 10 亿笔，保证业务稳定性还有连续性，这里用到了数据治理功能。图上右上角是我们的 CLB 腾讯的内部的一个负载均衡的组件。

CLB 是我们接入的节点，在 DN 上涨，我们是存储四个月的数据，四个月内的数据是存在一个高性能的 SSD 里面，四个月前的数据会存到比较普通的设备，比如大存储硬盘。它使用了大小商户策略，例如可以解决不同体量用户倾斜问题，从而高效保证系统运行。通过这种方式，把整个业务成本降低到 1/4 左右。

在外部有比较大的一个保险公司，上线了非常多的实例。这里只展现了我们的一个部署架构。首先分为两个平面，一个是读写平面，一个只读平面，读写平面业务可以通过 VIP 来提供读写能力，我们的只读平面，VIP 在多个节点中做负载均衡，提供一个业务只读的能力。

TDSQL PG 版在数据生成后，还要把数据同步到其它的系统上，比如说 Elasticsearch、MySQL、INFORMIX 或者 Oracle 在 TDSQL PG 版中可以在通讯的同时把它解成一个 Json 形式，把它同步到 Kafka 同步工具，最后通过 Kafka 通到其它业务系统。

最后一个案例是去年冬天刚上线的的七人普系统，这个项目是国家核心重点项目，涉及 700 万的普查员以及 1 亿人自主申报，并且在 15 天内完成数据量采集。在项目中 PostgreSQL 承担了非常重要的分析业务，同时具备了实时写入还有海量数据同时分析能力。今天的分享到此结束，谢谢大家。