TDSQL PostgreSQL版 选型建议

一、架构解析

TDSQL PostgreSQL 版分布式架构实例采用无共享 share nothing 架构。数据库实例分为三种节点：

·Coordinator：协调节点（简称 CN），对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图。在功能上 CN 只存储系统的全局元数据，并不存储实际的业务数据。

·Datanode：数据节点（简称 DN），处理存储本节点相关的元数据，每个节点还存储业务数据的分片。在功能上，DN 负责完成执行协调节点分发的执行请求。

·GTM：全局事务管理器（Global Transaction Manager，GTM），负责管理集群事务信息，同时管理集群的全局对象，如序列等。

1. 选型原则：集中式能承载的情况下，尽量选择集中式。

2. 选择分布式数据库的一般标准：

指标	阈值	说明
数据量大	热数据 > 2TB全量数据 > 5TB	1、热数据（排除日志表、历史流水表）超过2TB。2、全量数据量超过5TB，从运维角度建议采用分布式数据库，避免单节点数据量过大，备份、运维时间太长的问题。
活跃会话较高	最大值 > 300	集中式的并发处理能力上限受物理服务器 CPU 约束。
负载的复杂度	单个服务器资源不足	例如：高峰时段事务频率：最大值 > 1500，CPU 使用率 > 70%
适合使用分布式数据库的场景	有	1. 数据库已经做了分库分表。2. 数据适合分片，且数据分布均衡。3. 业务适合分布式改造，业务的逻辑不存在大量跨 DN 的分布式操作：分布式事务、分布式查询。

3. 选择分布式数据库的其他标准：

指标	阈值	说明
有可扩展性要求	有	每年有大量数据增长，或者不能预期增长情况时，可以考虑使用分布式架构。
有相对较高的秒杀场景	有	定期有秒杀场景，即有大量并发用户访问数据库的情况，可以考虑使用分布式架构。

·CN：承接连接创建，以创建连接需要的内存为参考，建议最低需要2组 CN。

·DN：承接 SQL 计算，关系到 SQL 处理效率，以服务器 CPU 单核处理能力为参考。不能少于 CN 的总内存，内存越大，缓存的数据越多，效率越高。

·GTM：跟数据库的 TPS（Transactions Per Second）相关，CPU 使用率非常高，建议 24CPU 以上。私有化部署时，建议单台服务器独立部署。公有云会根据 CN 和 DN 的配置来自动分配。

·CN 节点组所需要的内存 = (连接数 / CN 数 * (work_mem + temp_buffers) + (maintenance_work_mem * 3 + 后台进程占用 + 系统预留)) * CN 数 / 0.75
其中，默认参数如下：

·temp_buffers：8MB

·work_mem：4MB

·maintenance_work_mem：

·32GB及以下，用512MB。

·(32GB,64GB]，用1GB。

·(64GB,128GB]，用1.5GB。

·128GB以上，用2GB。

·shared_buffers：1/4 内存。

·后台进程占用：(CN * DN * DB数量 * 10) * 4MB，可以按照1GB来估算。

·系统预留：1GB~3GB。

·数据重分布内存：根据实际情况调整，不在估算范围内。

·DN 节点 CPU 单核的处理能力：2个 – 10个活跃并发连接数/核

假设当前 CN 和 DN 已部署完毕，基于所部署的机型，为达到资源利用的最大化，可选的配置如下：

若当前活跃的并发连接数为1000，则配置建议如下：

·由于 DN 节点 CPU 单核的处理能力为：2个 – 10个活跃并发连接数/核，因此 DN 可选配置为：16核64GB * 8 、32核128GB * 4 或 64核256GB * 2。

·CN master 总内存 = (连接数 / CN 数 * (work_mem + temp_buffers) + (maintenance_work_mem * 3 + 后台进程占用 + 系统预留)) * CN 数，因此 CN 可选配置为：4核16GB * 2。

·DN 的总内存不能小于 CN 的总内存。

实例的配置如下：

·CN：2组，每组4核16GB。

·DN：8组，每组16核64GB 或4组，每组32核128GB或2组，每组64核256GB。

·GTM：建议 GTM master 单独物理机部署，CPU 不少于24核。