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

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

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 承担了非常重要的分析业务，同时具备了实时写入还有海量数据同时分析能力。今天的分享到此结束，谢谢大家。