PostgreSQL分布式数据库总览
前言
PostgreSQL单机版我们都很熟悉了，那么基于PostgreSQL分布式数据库呢，那么多鱼龙混杂的产品，如何挑选一款最契合我们的产品呢？这也是本篇文章的由来。本文不会去阐述分布式相关的知识，诸如CAP、BASE、2pc、3pc、TCC、Raft、Saga、TSO、HLC等这些晦涩难懂的知识。本文仅仅做一个PostgreSQL系分布式数据库的科普。
注：以下资料均来源于公开资料，侵删。
Citus
分为开源版（社区版）和商业版。下面针对开源版。官方文档：https://docs.citusdata.com/en/v10.2/
介绍
Citus是一款基于PostgreSQL的开源分布式数据库，自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅仅是客户端协议的兼容还包括服务端扩展和管理工具的完全兼容）。和其他类似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL，PostgreSQL-XC相比，Citus最大的不同在于Citus是一个PostgreSQL扩展而不是一个独立的代码分支。
因此，citus可以用很小的代价和更快的速度紧跟PostgreSQL的版本演进，同时又能最大程度的保证数据库的稳定性和兼容性。
架构
Citus的架构如上图所示，为Share Nothing的分布式架构，包含两种类型的节点：
•Coordinator协调者节点•负责接收来自客户端的交互请求，并把请求按照规则转发给对应Worker节点执行；•本地维护Metadata元数据，例如Shard分片信息，放置节点信息等；•Worker工作节点，也叫数据节点•负责用户数据表的实际存储
Citus通过Extension的方式扩展了PostgreSQL下面的功能：
•System catalogs：新增分布式元数据表等•Planner hook：新增"增删改查"操作的分布式查询计划•Executor hook：新增"增删改查"操作的分布式执行逻辑•Utility hook：修改Alter Table，Create Index，Vacuum等逻辑支持分布式；•Transaction & resource handling：支持同时打开更多文件描述符•Background worker process：新增后台任务进程如：死锁检测，任务跟踪进程等；•Logical decoding：支持在线数据迁移
表类型
Citus 集群中有三种类型的表，包括Distributed Tables（分布式表）、Reference Tables（参考表）以及Local Tables（本地表），每种类型用于不同的目的，
•分片表•hash：按分片字段hash值分布数据•Append：分片size增加到一定量自动创建新的分片•参考表：仅一个分片，每个worker一个副本，主要用于维度表。•本地表：仅驻留在CN节点的表。Citus 9.5+进一步增强了对本地表的支持，比如元数据支持。
分布式表是最常见的类型，一般建议把大于10G的业务表创建为分布式表，它们在Workers工作节点之间水平分区。分片字段的选择：
•每个SQL中都带等值条件的字段（比如用户ID）•Join关联的字段•高基数且值分布均匀的字段•日期（按天）通常不适合作为分片字段，业务往往倾向于访问最近的数据，容易形成热点
限制
最新版本已经10.2了，目前根据一些资料得到了一些限制：
Citus中没有全局的事务快照，这和MyCAT等常见的分库分表方案一样。这样可以简化设计提升性能，带来的问题就是不能保证全局的一致性读，而只能实现的最终一致性。
举个例子，从用户A的账户上转账100块到用户B的账户上，用户A和B对应的记录分别位于不同的Worker上。
Citus使用2PC处理这个分布式事务，具体处理步骤如下
1.Worker1 : BEGIN;2.Worker2 : BEGIN;3.Worker1 : UPDATE account_$shardid SET amount = amount - 100 WHERE user = 'A';4.Worker2 : UPDATE account_$shardid SET amount = amount + 100 WHERE user = 'B';5.Worker1 : PREPARE TRANSACTION 'tran1';6.Worker2 : PREPARE TRANSACTION 'tran2';7.Worker1 : COMMIT PREPARED 'tran1';8.Worker2 : COMMIT PREPARED 'tran2';
在步骤7和8之间，参与2PC的2个子事务一个已提交另一个还没提交。如果此时有人查询账户总额，会得到一个不正确的值。SELECT sum(amount) FROM account;
案例
小结
这个产品主打的是实时HTAP场景，接入层coordinator可横向扩展，计算和存储层datanode也可以横向扩展，datanode层支持内部Shuffle。
同基于PG-XC架构的tbase， antdb， opengauss分布式版本等产品相比，Citus优势是：
•它只是个插件， 可以跟随PostgreSQL大版本升级一起升， 轻量化， 维护简单。
同greenplum这个PostgreSQL系列AP的老大哥相比，Citus优势是：
•接入层可横向扩展， 实时写入不存在问题， TP能力明显强于greenplum.
Citus弱点是：
•Shuffle没有greenplum彻底•语法支持没有antdb，tbase等兼容性好•存储层面靠PostgreSQL原生，没有greenplum的列存储， AP性能相对GP更弱，citus 10.x 发布了列存支持，基于PG tableaccessmethod api的列存储引擎， 使得HTAP场景的分析能力有较大提升。
同shardingsphere这种中间件相比：
•Citus的优势是， 使用门槛低， 对业务透明。•Citus的弱势是， TP性能没有shardingsphere这种中间件好， 因为shardingsphere可以做到LIB层， RT无损。
关于shardingsphere，多唠几句，最近挺火。Sharding-JDBC 最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 ShardingSphere，2020年4⽉16⽇正式成为 Apache 软件基⾦会的顶级项⽬。随着版本的不断更迭 ShardingSphere 的核心功能也变得多元化起来。如图7-1，ShardingSphere生态包含三款开源分布式数据库中间件解决方案，Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar。
Apache ShardingSphere 5.x 版本开始致力于提供可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。目前，数据分片、读写分离、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。开发者能够像使用积木一样定制属于自己的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，而且仍在不断增加中。
openGuass和shardingsphere提供了一个分布式的解决方案，可以参考《openGauss X ShardingSphere，分布式方案的另一种最佳实践》
关于shardingsphere的原理可以参考《深度剖析分库分表最强辅助Sharding Sphere》
回到Citus，Citus未大面积流行的原因:
1.Citus 10.x发布以前， rebalance是未包含在开源版本里面， 集群扩缩容门槛较高， 也是导致开源版本使用率不是特别高的原因之一， 苏宁自己研发了一个扩缩容插件并开源，cigration，cigration是一个由一系列工具函数组成的PostgreSQL扩展，主要用于执行Citus的在线分片迁移，可用于Citus集群扩容和缩容场景。cigration是Citus + migration的拼写。地址在https://github.com/cloud-sn2/cigration。Citus估计看到了这个问题10.x就把rebalance开源了。2.被微软收购以及它的AGPL开源许可导致云厂商未跟进， 也是市场没有铺开的原因之一。3.官方社区一直在主导基于fdw的sharding方案 (https://wiki.postgresql.org/wiki/WIP_PostgreSQL_Sharding)。
支持fdw sharding的企业包括:
•EnterpriseDB•NTT•Postgres Professional•HighGo Software Inc•2ndQuadrant•NTT Data•Fujitsu
社区一直在完善sharding相关优化器能力。
目前已经支持了：条件、排序、聚合、DML、JOIN下推， FDW分区， FDW分区表感知JOIN、FDW异步并行计算、batch(bulk) insert操作.
暂未支持：2阶段、全局snapshot、Shuffle， rebalance， 便捷的扩缩容管理，但是对PG用户选择sharding方案也会造成一些影响。
Greenplum
目前是Greenplum6，今年会release Greenplum7，基于12的内核，TP的能力会大大增强，使得Greenplum成为一款真正的HTAP数据库。
介绍
PostgreSQL是世界上最先进的单机开源数据库。Greenplum基于PostgreSQL，是世界上最先进的开源MPP数据库。Greenplum最早是在大约在2002年左右出现的，基本上和Hadoop是同一时期。从用户角度来看，Greenplum是一个完备的关系数据库管理系统(RDBMS)。从物理层面，它内含多个 PostgreSQL 实例，这些实例可以单独访问。为了实现多个独立的 PostgreSQL实例的分工和合作，呈现给用户一个逻辑的数据库，Greenplum 在不同层面对数据存储、计算、通信和管理进行了分布式集群化处理。Greenplum 虽然是一个集群，然而对用户而言，它封装了所有分布式的细节，为用户提供了单个逻辑数据库。这种封装极大的解放了开发人员和运维人员。Greenplum6已经将内核升级到了9.6，Greenplum7会将内核升级到12，大大提升TP能力，称为一款HTAP(Hybrid Transaction and Analytical Process)的数据库。以下简称为GPDB。
Greenplum的特点如下
1.从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。而现在的 NoSQL，NewSQL和Hadoop 对 SQL 的支持都不完善，不同的系统需要单独开发和管理，且移植性不好。2.支持分布式事务，支持ACID。保证数据的强一致性。3.拥有良好的线性扩展能力4.GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，Cognos，Informatic，Tableau等5.支持海量数据存储和处理6.较好的并发支持及高可用性支持除了提供硬件级的Raid技术外，还提供数据库层Mirror机制保护，也剧场将每个节点的数据在另外的节点中同步镜像，单个节点的错误不影响整个系统的使用。对于主节点，还提供Master/Stand by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务
Greenplum的整体架构图如下：
•Master节点：是整个系统的控制中心和对外的服务接入点，它负责接收用户SQL请求，将SQL生成查询计划并进行并行处理优化，然后将查询计划分配到所有的Segment节点进行并行处理，协调组织各个Segment节点按照查询计划一步一步地进行并行处理，最后获取到Segment的计算结果，再返回给客户端；从用户的角度看Greenplum集群，看到的只是Master节点,无需关心集群内部的机制，所有的并行处理都是在Master控制下自动完成的。Master节点一般只有一个或两个(互为备份mirror)，当主master出现故障时，备master会接替担任工作。•Segment节点：每个segment存放一部分数据，分布策略包括哈希分布、随机分布和Greenplum6版本中新增加的复制分布，同时Segment节点是Greenplum执行并行任务的并行运算节点，它接收Master的指令进行MPP并行计算，因此所有Segment节点的计算性能总和就是整个集群的性能，通过增加Segment节点，可以线性化得增加集群的处理性能和存储容量。•Interconnect：Master节点与Segment节点、Segment节点与Segment节点之间的数据传输组件，它基于千兆交换机或万兆交换机实现数据在节点间的高速传输
Greenplum的主要特点是询速度快、数据装载速度快、批量DML处理快、性能可以随着硬件的添加呈线性增加、拥有非常良好的可扩展性。主要适用于面向分析的应用，如构建企业级ODS/EDW、数据集市等。同时Greenplum7会将内核升级到PostgreSQL12，TP能力大幅增长，成为一款真正的HTAP数据库。
特点
案例
Greenplum是pivotal公司推出的一款开源OLAP的MPP数据库，Greenplum的用户在某种程度上甚至超越了PostgreSQL，很多人可能是通过Greenplum才认识的PostgreSQL，可见Greenplum的风靡。国内据笔者知道的基于Greenplum的有
•国内有姚老板带队的Matrixdb，基于Greenplum7和时序组件，主打时序场景•OushuDB，由Apache HAWQ项目创始人（常雷）和团队在2016年创立，主打云上数仓，湖仓一体•阿里ADB（做了multi master segment）•杭州拓数派，Greenplum中国创始人兼总经理Ray创办•还有一些其他基于Greenplum的国产数据库，比如KADB等
Yugabyte
介绍
YugabyteDB是一个高性能、云原生的分布式SQL数据库，旨在支持所有的PostgreSQL特性。YugabyteDB最适合云原生的OLTP应用（实时性、企业级业务），这些应用需要绝对的数据库一致性并且至少需要如下特性中的一点：可扩展性、高容错性或全局分布式部署。
YugabyteDB的核心特性包括：
1.强大的RDBMS SQL能力（以下简称YSQL），重用了PostgreSQL的查询层（类似于 Amazon Aurora PostgreSQL），因此支持大多数PostgreSQL特性（数据类型、查询、表达式、操作符、函数、触发器、存储过程和插件等）。下面是YSQL目前支持的特性列表：https://github.com/yugabyte/yugabyte-db/blob/master/architecture/YSQL-Features-Supported.md2.分布式事务：事务设计基于谷歌Spanner架构。通过Raft协议实现强一致性写入，并且通过"混合逻辑时钟"Hybrid Logical Clock (HLC)实现实例级的分布式ACID事务。同时支持快照和可序列化的隔离级别。读(查询)在默认情况下具有很强的一致性，但可以动态调整从追随者和读副本中读取。3.持续可用性：YugabyteDB拥有强大的本地故障转移和修复能力，因此对于常见的故障自愈能力很强。YugabyteDB可以对磁盘、节点、分区、区域和云故障等自动容错。对于一个典型的部署方式：公有云上，跨多个可用区的单数据中心，RPO是0(意味着没有数据丢失),RTO 3秒(即故障节点可以在3秒内恢复提供服务)。4.水平扩展性：只需向集群中添加节点即可横向扩展YugabyteDB，以实现更多的IOPS或数据存储。5.跨地域、混合云：YugabyteDB可以部署在公有云中，也可以本地部署在Kubernetes中。YugabyteDB支持部署在跨三个或三个以上的区域，如多可用区、多中心、混合云部署。它还支持使用单向主从配置和双向多主配置的xCluster异步复制，这些配置可用于两个区域的部署。为了以更低的延迟提供服务，也支持副本读。6.支持多种API：YugabyteDB的查询层是可扩展的。目前，YugabyteDB支持两种分布式SQL API：Yugabyte SQL（YSQL）（一种完全重用PostgreSQL查询层的关系型API）和Yugabyte Cloud QL（YCQL）（一种半关系型SQL的API，支持Document/Indexing）类似Apache Cassandra。7.100%开源：YugabyteDB是基于Apache 2.0协议。开源版本也同样具有强大的企业特性，如分布式备份、静态数据加密、实时TLS加密、CDC、只读副本等。
SQL层
•YSQL, a distributed SQL API wire compatible with PostgreSQL•YCQL, a semi-relational API built for high performance and massive scale, with its roots in Cassandra Query Language•Every YB-TServer is configured to support these protocols, on different ports. Port 5433 is the default port for YSQL and 9042 is the default port for YCQL.
Yugabyte 的查询层目前支持同时 SQL 和 CQL 两种 API，并且还会持续扩展
其中 YCQL 是兼容 Cassandra 的一种方言语法，对应于文档数据库的存储模型；而 YSQL 是直接重写了PostgreSQL的查询层
存储层
YB-TServer
见官网的这个例子，一个四节点的YugabyteDB集群，一张表被分成了16个tablet（tablet 是数据分布的最小单元），复制因子是3（对应peer1 、peer2、peer3）形成一个 Raft Group，通过 Raft 协议保证数据的高可用和持久性，tablet的副本均匀分布在各个node上，保证数据不会倾斜，Group Leader 负责处理所有的写入负载，其他 Follower 作为备份
其中tablet是基于Hash或者range而来，也可以先哈希再范围，tablet也可以理解为我们熟知的chunks，具体算法可以参考：https://docs.yugabyte.com/latest/architecture/docdb-sharding/sharding/#hash-sharding
YB-Master
YB-Master保存系统元数据和相关记录，例如系统中存在哪些表、它们的tablet在哪里、存在哪些用户和角色、与它们相关联的权限等等。它还负责协调后台工作(如负载平衡或数据重分布)和执行各种管理操作，如创建、修改和删除表。Master 本身也依靠 Raft 实现高可用。
基于 RocksDB 的本地存储
每个 TServer 节点上的本地存储称为 DocDB。和 TiDB/Cockroach 一样，Yugabyte 也用 RocksDB 来做本地存储。
案例
•国内Airwallex（空中云汇）有上百套•MemfireDB基于Yugabyte衍生而来•Yugabyte在C轮融资中获得了1.88亿美元•https://www.yugabyte.com/success-stories/
小结
•YugabyteDB 是开源New-SQL 中实现上讲 是最像google spanner 的，TIDB、Yugabytedb、CRDB等数据库都是在谷歌的2PC模型的基础上改造的。
Percolator模型很适合在分布式数据库上建立SNAPSHOT ISOLATION级别的ACID强一致性事务，因此十分广泛的被分布式数据库使用。其lock、write、data分离的模式实现起来架构十分清晰，不过因为一个事务被分为三个控制结构，因此在事务控制中需要更多的网络交互，因此会增加分布式事务的成本。谷歌为了解决这个问题，使用了一种高精度的原子钟，从而避免在全球部署的数据库环境中产生中心点，同时也通过砸钱解决了昂贵的网络延时问题。而TiDB使用了论文中提到的TSO（Timestamp Oracle），这让PD成为了一个中心点。CRDB为了去中心化，没有使用集中式的TSO。采用了一种更为廉价的实现方式，通过NTP来同步集群节点之间的时钟，从而获得不太精确的全局TIMESTAMP。
1.传统基于MVCC+2PC+GTM做的分布式事务，在高并发的情况下这种基于GTM全局快照的设计会在GTM上有比较大的性能压力。一个是GTM加锁遍历生成全局快照中活动事务列表计算的开销以及锁冲突开销，另一个是高并发下活动事务列表过大导致快照大小膨胀带来的网络开销。这两点导致这种设计在高并发情况下性能受限。2.Google Spanner基于原子时钟和true time api实现了一致性的分布式事务，但需要昂贵的设备支持。Google Percolator采用全局时钟提供一致性分布式事务，但Percolator在一阶段提交时需要遍历数据将锁信息写入到数据单位，二阶段时又需要遍历数据释放锁写入提交时间戳等信息。事务提交开销变大且与数据量相关。
•主打的并不是AP也不是HTAP，就是纯粹的mission-critical TP业务•YugabyteDB的竞争对手应该来说可以算是MySQL和PG生态的OLTP场景分布式数据库, 包括 citus, postgresql, mysql, spanner, cockroachdb, tidb, pg-xc以及衍生品等。•Yugabyte 和 Cockroach 一样选择的是 Hybrid Logical Clock (HLC)。HLC唯一的缺点是不能提供真正意义上的外部一致性，仅仅能保证相关事务之间的“外部一致性”。另一种方案是引入中心授时节点（TSO），也就是 TiDB 使用的方案。TSO 方案要求所有事务必须从 TSO 获取时间戳，实现相对简单，但引入了更多的网络 RPC，而且 TSO 过于关键——短时间的不可用也是极为危险的。•YugabyteDB 和CockroachDB都兼容PostgreSQL，但是YugabyteDB是代码层直接复用，兼容性更好。CockroachDB只是协议兼容，语法兼容性较差。
CockroachDB
CockroachDB (蟑螂数据库）是一个可伸缩的、支持地理位置处理、支持事务处理的数据存储系统。
为什么叫做蟑螂？
因为这个数据库只要损坏的节点不超过总数一半，那么集群仍然可以正常工作，生命力超强。
通过分布式一致性算法实例来调节确保一致性，它所选择使用Raft一致性算法。所有的一致性状态存在于RocksDB中。
Cockroach 是一个分布式的 SQL 数据库。首要设计目标就是 可扩展性，强一致性，可存活性，就像它的名字一样。Cockroach 的目标是在无人工干预的情况下，以极小的中断时间容忍磁盘，主机，机架甚至 数据中心灾难 。Cockroach 的节点是对等的，其中一个设计目标是以最少配置加无依赖，部署去中心化的对等节点。中文社区地址：cockroachdb-cn。
CockroachDB 提供两种不同的的事务特性，包括快照隔离（snapshot isolation，简称SI）和顺序的快照隔离（SSI）语义，后者是默认的隔离级别。
CockroachDB 是一个分布式的K/V数据仓库，支持ACID事务，多版本值存储是其首要特性。主要的设计目标是全球一致性和可靠性，从蟑螂的命名上是就能看出这点。蟑螂数据库能处理磁盘、物理机器、机架甚至数据中心失效情况下最小延迟的服务中断；整个失效过程无需人工干预。蟑螂的节点是均衡的，其设计目标是同质部署（只有一个二进制包）且最小配置。
CockroachDB 和 TiDB、YugabyteDB 都公开声称设计灵感来自 Spanner，所以往往会被认为是同构的产品。CockroachDB 和 TiDB，经常会被大家拿来比较。
区别：
•CockroachDB 采用了标准的 P2P 架构，只要损坏的节点不超过总数一半，那么集群仍然可以正常工作。•CockroachDB 支持全球化部署，因为它采用了混合逻辑时钟（HLC），所以能够在全球物理范围下做到数据一致性。•分片管理机制的不同。•CockroachDB兼容PostgreSQL协议，对于报文的封装和解析完全按照PostgreSQL的方式进行，所以用户可以直接使用PostgreSQL的客户端访问CockroachDB。•CockroachDB对于用户的SQL语句按照PostgreSQL的语法进行解析，解析完成后生成抽象语法树(AST)
注意，CockroachDB只是兼容PG协议。
PGXC
介绍
Postgres-XL是一款开源的PG集群软件，XL代表eXtensible Lattice，即可扩展的PG"格子"之意，以下简称PGXL。
官方称其既适合写操作压力较大的OLTP应用，又适合读操作为主的大数据应用。它的前身是Postgres-XC（简称PGXC），PGXC是在PG的基础上加入了集群功能，主要适用于OLTP应用。PGXL是在PGXC的基础上的升级产品，加入了一些适用于OLAP应用的特性，如Massively Parallel Processing (MPP) 特性。
通俗的说PGXL的代码是包含PG代码，使用PGXL安装PG集群并不需要单独安装PG。这样带来的一个问题是无法随意选择任意版本的PG，好在PGXL跟进PG较及时，目前最新版本Postgres-XL 10R1，基于PG10。
整体架构和Citus类似，分为协调节点(CN)和数据节点(DN)，CN节点主要存储元数据信息，多个CN之间需要相互同步元信息，而DN数据节点则是存储数据的地方，数据通过Hash分布到不同的数据节点上。不同于Citus，PGXC中增添了全局事务管理组件(GTM)，以此保证全局的事务的致性。GTM是整个系统的瓶颈点，并发上来的情况下，GTM的瓶颈就会显现，每一个事务开启都会去和GTM进行交互，获取事务号和快照信息，因此不少基于PGXC二次开发的产品都着重优化了GTM的逻辑。
另外和Citus类似，数据表也可以分为分布表和复制表(也可以称为广播表)，复制表在每一个数据节点都有一份全量数据，适用于数据量较小、更新较少又频繁需要连接的表。
小结
PGXC已经EOL了。开源的PGXL不建议使用，一堆BUG，并且不支持事件触发器、存储过程等。
XC系分布式
前文也说了，开源的PGXC已经EOL了，国内不少厂商选择基于PGXC二次开发。
TBase
笔者的老东家，第七次人口普查就是TBase承载的，也是笔者从事过的最大的最苦逼的项目。目前腾讯已经将Tbase、TDSQL、cynosDB统一品牌为TDSQL，原TBase名为TDSQL-A，类似于POLAR，也是经典的PGXC架构。
开源版的TBase也于最近进行了一次较大的优化：
1月11日，腾讯云TDSQL PG版（开源代号TBase）再升级：分布区表关联查询性能（join）提升超10倍，同时提升了产品在分布式场景下的易用性，增加灵活可用的功能组件。
我们知道PGXC的架构，GTM很容易成为单点瓶颈，GTM主要与协调节点进行交互，协调节点开启一个事务首先需要去GTM取全局事务号和事务快照信息，并发一大再加上全局事务快照列表（xip_list）一多的话，性能就会下降得很厉害。TBase 在分布式事务上的能力做了较大优化，
首先我们对 GTM 集群做了优化，从原始的全局 XID 改成了分配全局时间戳GlobalTimeStamp（GTS），GTS 是单调递增的，我们基于 GTS 设计了一套全新的 MVCC 可见性判断协议，包括 vacuum 等机制。这样的设计可以把提交协议从 GTM 的单点瓶颈下放到每一个节点上，减轻压力，同时通过时间戳日志复制的方式实现 GTM 节点主备高可用。
这种协议下 GTM 只需要去分配全局的 GTS，这样的话单点压力就会被解决得比较明显。根据我们的推算， 滕叙 TS85 服务器每秒大概能处理 1200 万 TPS，基本能满足所有分布式的压力和用户场景。
我们刚才也提到，在 Percolator 的实现下，需要对 Tuple 上锁并修改记录，这样的话性能是比较差的。而实际上我们对提交协议做了一个优化，在对 Tuple Header 的 GTS 写入做了延迟处理，事务提交的时候不需要为每一个 Tuple 修改 GTS 信息，而是把 GTS 的信息存储在相应的 GTS Store File 当中，作为事务恢复的保障。
当用户第一次扫描数据的时候，会从 GTS Store File 中取到状态，再写入到 Tuple Header 中，之后的扫描就不需要再去遍历状态文件，从而实现加速访问，做到事务处理的加速。这样在整体上，让数据库在事务层面保证了比较高效的设计。
POLARDB的实现就借鉴了TBase：Some code and design ideas are based on other open source projects, such as PG-XC/XL (pgxc_ctl), TBase (Timestamp-based vacuum and MVCC), Greenplum and Citus (pg_cron). We thank the contributions of the preceding open source projects.
AntDB
AntDB 是一款源自于 PG 内核的通用分布式事务性关系数据库，是一款面向金融、电信、政务、安全、能源等行业的国产、自主、安全可靠、高性能的企业级分布式事务型关系数据库产品。具备持续的集群自动高可用，秒级在线扩缩容，强大的 Oracle 兼容，异地容灾，SQL 语句级自定义分片，分布式事务和 MVCC ，最大保护最大性能最大可用的自适应切换，全局一致性位点恢复等企业级应用的核心能力。对应用完全透明，可实现从 Oracle 的平滑迁移。
AntDB除了支持行列混存，O兼容，也对事务模型进行了优化改造。
GuassDB
以下资料来源：https://blog.csdn.net/enmotech/article/details/103154268
最初，华为的数据库公布出来的型号系列有三款，分别是 100、200 和 300 ，统一的命名都是 GaussDB 。
GaussDB 100 ，以 OLTP 为方向，最初和招商银行联合研发，然后推广，在 2020年6月，将会开源单机版本；
GaussDB 200，以 PostgreSQL 为出发点，面向 MPP 研发，工商银行率先尝试使用，然后推广；
GaussDB 300，以 HTAP 为方向，民生银行尝试使用。
在2019年10月左右，华为 GaussDB 的命名再次调整：
GaussDB 100 ，更名为 GaussDB T ，以 OLTP 和集群为方向；
GaussDB 200 合并 300 的部分设计，更名为 GaussDB A，以分析型为主方向；
GaussDB 300，型号取消，涉及功能并入 100 或 200 。
2020年6月开源的也就是我们熟知的openGuass，而mogdb、vastbase等，则是基于openGuass的企业版。
GaussDB200是华为与工行合作研发的纯OLAP类数据库，GaussDB200基于经典pgxc架构，底层基于postgresql9.2版本研发，是一款分布式mpp数据库，目前已经在工行有大规模应用。
GaussDB300是基于GaussDB200演变而来，在原有集群上做了很多OLTP的适配，是一款HTAP混合负载分布式数据库，当然现在GaussDB300也有单机版，目前300也在和国内某大行进行合作研发。
相比postgresql-xc架构，GaussDB200分布式数据库新增了集群管理cmserver作为集群的大脑进行集群调度管理，增加cmagent作为集群每个节点上的agent来完成cmserver下发的具体任务，增加ommonitor监控组件监控每个节点上相关进程状态，实现进程故障自愈等功能。集群管理功能比较强大，目前实现了集群节点故障或者亚健康的自动切换，故障场景涵盖面比较全，比如宕机、数据库进程异常终止、网卡故障、文件系统只读、磁盘缓慢等场景都能够触发自动切换。总体架构如下：
GaussDB300数据库在200的基础上新增了etcd集群，用于保存gtm的全局事务id号，同时数据节点由原来的主-备-从（从节点不含数据，当主节点宕机切换后，从节点才有数据）变为现在的一主多备模式，每个备节点都有数据，节点间使用quorum协议。Gtm集群由原来的一主一备变为了一主多备。总体逻辑架构如下 ：
内核方面主要的优化：
1.进程模型改为线程模型2.XID事务号从32位改为64位（v15正在做64位的事务ID，各位拭目以待）3.GTM性能增强还有一些其他小众的基于XC的数据库，这里就没有罗列了。
小结
PGXC 架构是从分库分表方案演进而来的。它设置了协调节点，在代理功能的基础上增加了分布式事务管理、跨节点查询功能；原有的单体数据继续作为数据节点；新增了全局时钟和分片信息管理两个功能，这两个功能又有两种实现情况，一是拆分为两个独立角色节点，例如 GoldenDB，二是合并为一个角色节点，例如 TBase。NewSQL 架构是原生分布式数据库，架构中的每个层次的设计都是以分布式为目标。