PostgreSQL在5G网管中的应用

1、PostgreSQL数据库在5G网管中的应用技术创新 变革未来5G网管系统PG云化部署 PG性能提升PG异地容灾2018年韩国和美国率先 推出5G商用服务2019年中国5G试商用2020年加拿大、日本、欧洲等国家和地区也将 实现5G商用5G是第四次工业革命的核心技 术和基础设施，它与物联网、 人工智能相结合，将对各行各 业（包括人类社会本身）产生 深远的影响。SG基于SDN/NFV虚拟化技术进行构5，网N架构 复杂，由接入网、承S网/核心网等部分组成SG网N切F，可切出多张虚拟网N，满足多样化业 务需D，实G端到端的按需定制/V离不同的切片特性：低延迟、高吞 吐措、连接密度、频谱效率、流 措容

2、措和网络效率面对如此复杂5网络架构和数量庞大5 网元设备，5G网管系统显得必不可少！ 5G包含2大类部署演进路 线：独立部署(SA)和非 独立部署(NSA) NSA部署，即利用现有的LTE 无线接入网和核心网， 新增5G 无线接入，采用与LTE双连接的部署方式。这使得5G网管系统变得相当复杂！虽然5G时代已经到来，但是5G建设是一个漫 长的过程，在此期间2G、3G、4G 还将并存。 建设目标是支持2/3/4/5G网络统一 融合管理 除了提供传统网管的基础运维外， 还提供基于AI技术的智能运维 提供了对无线接入网、承载网和5G 核心网的运维管理功能中兴通讯5G网管系统是基于云平台的 下一代自动化

3、智能化网络运维系统5G网管系统在PG中存储哪些数据当前告警大数据分析审计日志性能统计资源信息网元配置OLTP数据存储规模小读多写少低并发高并发OLAP数据存储规模大复杂的统计分析5G网管系统PG云化部署 PG性能提升PG异地容灾镜像中心创建简单部署创建复杂部署蓝图中心UME OES XXXPGsIaaSPaaSSG网管平台PaaS23服务服 务 网 4RedisRabbi. MQPG5他 服务配置Cl亘管I管I业务人员PODPODPG Cluster 1PG Cluster 2PODPODPODPG Cluster 3PODPODPODApplications appappApplicatio

4、ns appappappappapp appappappappappIaaSPaaS选择镜像部署PG简单部署：从镜像中心的分类镜像中选择PG镜像，直接创建一 个PG数据库服务编排蓝图选择蓝图部署PG复杂部署：在蓝图中心编排PG数据库服务与网管应用的嵌套组合，以及 业务流关系，通过部署蓝图来创建复杂应用部署方式灵G节点弹性伸缩资源弹性伸缩多租户多集群5.支持异地灾备云平台对PG的部署要求 PG Clusters & ApplicaionsDocker容器化Kubernetes编排管理容器隔离：PG各组件分别制作成独立Docker镜像POD封装：密切相关的容器编排在同一个POD中动态调度：POD可

5、动态调度到任一Node部署运行 多集群：支持动态创建多个PG高可用集群多副本：每个PG高可用集群可支持1n个副本节点Kubernetes是集群管理的核心，负责资源管理、POD调度、弹性伸缩、系统监控等管理功能节点漂移弹性伸缩PG在云平台下的运行特点Node 1L1POD1 PG ProxyPG ServerPacemakerPOD4 POD2 Node 2L1POD4 POD3 POD1 Node 3L1POD2 POD4 POD1 POD1 l创D一个n个副KP数据C集群，可通过RC定4PODP副K数，K8S全自动实时监控O态副K数量l为POD贴上一个标签，比如，定4标签选择，8该Servi

6、ce与标签选择S选出来PPODDR关联 关系PG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerPG ProxyPG ServerPacemakerservicePG在云平台下的部署形态docker容Kubernetes如何解决POD节

7、点漂移问题Node 2POD1 Node 3POD1 PG ProxyPG ServerPacemakerData BData CNode 4POD1 PG ProxyPG ServerPacemakerError!POD1 POD1 PG ProxyPG ServPeGr PErorxryor!PacemaPkeGrServerPacemakerData ANode 1PG ProxyPG Server OK!PacemakernodeAffinity:设置该POD可以部署到哪些Node上podAffinity:设置该POD需要和哪些POD部署在同一个拓扑域中podAntiAffinity:

8、设置该POD不能和哪些POD部署在同一个拓扑域中5G网管系统PG云化部署 PG性能提升PG异地容灾影响PG性能的主要因素CPUIO内存网络硬件因素应用技巧操作系统选型库表逻辑设计文件系统选型数据库参数调优索引类型与设计SQ 编写技巧新型 硬件容器资源弹性伸缩，动态调节PG处理能力 实时监控容器资源使用情况CPU%、IO、内存、网络等物理资源数据库连接数、读写请求数、表空间等监控包括网管系统和数据库系统等2个层面p 根据监控结果产生预o2息CP%占用达70%预警，0示增加CPU核数内存、磁盘占用达到间值时提示增加配置 动态压缩Docker容器资源配置根据情况增加容器的CPU、内存、磁盘等CPU核

9、数建议适当超配，以提高实际使用率磁盘空间的缩容比较难办，不建议做读写分离，充分发挥Slaves点能力SlaveMastersyncsyncSlavereadwrite/readPG参数synchronous_commit指事务提交所要求的WAL记 录同步等级，可以取5个有效值：CDoff:事务提A不需c等待WAL日志刷写入(flush)本地磁盘Q)local:事务等待WAL 日志刷写入本地磁盘后才提Aremote write:事务等待同步L节点接收到WA W志并写入操作_统才a提Aon:事务等待同步L节点接收到WA W志并刷写到(flush)磁盘才a提Aremote_replay:事务等待同步

10、L节点接收到WA W志并回放完毕才a提AR/W AppWrite AppRead AppPG Proxy优化SQL 之一：做好数据库的逻辑设计场景S案例把JSONB表转换成普通表提高性能J 有些X务原hd用MCBgCDBR迁移t1G之后直接d用,S0/B类型替a 不同模块需要动态地添v各自的X务字段L 复杂查询SGR051 BYR0RDER BYR输出结果集50U%00USELECT value FROM t1 WHERE ( value - a IN (1,2) ANDvalue - v = 1 AND ( value - m IS NULL OR value - m - value IN

11、(0) ) ) AND value - p IN (1,2,3,4) ) ) ORDER BY value - s DESC, value - id DESC LIMIT 10 OFFSET 40 ;问题：复杂查询执行时间太长，不能满足业务需求。表现为S虽然灵活，表达力强大，但是所有元素（子字段）都存放在一个JSONB字段中（注，整个表就一value字段),在查询处理过程中,从单个value字段解析出各个子字段耗费了大量CPU，在并发查询场景下，CPU几乎100%解决：把JSONB表转换成普通表，把公共字段提取出来，创建一个父表tb，然后利用PG的表继承特性，各业务模块继承父表tb创建自己的子

12、表tXXXR在子表中添v各自独有的X务字段O或者RN公共字段改造成普 通字段R预留一Y,S0/B字段让各YX务模块添v自己的独有字段O效果S查询性能提升10f左右R满足X务需求O优化 SQL之二：选择和设计合适的索引Subquery Scan on t (cost=274591.10.281092.97 rows=173383 width=32) (actual time=15004.376.17488.863 rows=4 loops=1)Output: to_jsonb( t .*)Buffers: shared hit=34395, temp read=30752 written=307

13、64- GroupAggregate (cost=274591.10.278925.68 rows=173383 width=72) (actual time=15004.299.17488.691 rows=4 loops=1)Output: .Group Key: .Buffers: shared hit=34395, temp read=30752 written=30764- Sort (cost=274591.10.275024.56 rows=173383 width=1467)(actual time=15004.264.16796.003 rows=173379 loops=1

14、) Output:.Sort Key:.Sort Method: external merge Disk: 246016kBBuffers: shared hit=34395, temp read=30752 written=30764- Seq Scan on .Output: .Filter:.Buffers: shared hit=34395 Planning time: 2.098 msExecution time: 17800.406 ms(18 rows)Subquery Scan on t (cost=39162.99.39163.04 rows=3 width=32) (act

15、ual time=5314.232.5314.244 rows=4 loops=1)Output: to_jsonb( t .*) Buffers: shared hit=34395- Sort (cost=39162.99.39163.00 rows=3 width=72) (actual time=5314.187.5314.188 rows=4 loops=1)Output: .Sort Key: .Sort Method: quicksort Memory: 25kB Buffers: shared hit=34395- HashAggregate (cost=39162.92.39162.97 rows=3 width=72) (actual time=5314.167.5314.169 rows=4 loops=1)Output:.Group Key:.Buffers: sha