1、PolarDB for PostgreSQL架构嘉宾：冯遵宝（北侠）公司：阿云-PolarDB产品部1.PolarDB-云原架构2.PolarDB-HTAP架构3.PolarDB-开源PolarDB for PostgreSQL架构1.PolarDB-云原架构扩展性差：加节点时级可靠性差：RPO!=0可性差：RTO 30s-5min成本：存储成本随节点数线性增加，并且预占资源MasterPG Server（最60核）本地盘/云盘Host1StandbyHost2PG Server（最60核）StandbyHost3PG Server（最60核）redo 志异步:1s 同步:=0,性能降20%+

2、扩节点拉数据 15min8h+OSS管控备份 本地盘 15min8hHA&Recovery30s5min本地盘/云盘本地盘/云盘1.PolarDB云原架构-背景（传统数据库痛点）1.PolarDB云原架构-计算存储分离PolarDB 计算-存储分离Shared StorageMemoryCPUPrimary（读写节点）架构优势 扩展性：存储计算分离，极致弹性 成本：共享份数据，存储成本低 易性：写多读/透明读写分离，单机体验 可靠性：三副本、秒级备份MemoryCPUReadOnly（只读节点）MemoryCPUReadOnly（只读节点）计算-存储体Local StorageMemoryCP

3、UPrimary（读写节点）架构挑战 致性：1份存储+N份计算 读写分离：低延迟复制 可：快速Recovery和Failover IO模型：DirectIO1.PolarDB云原架构-模块栈libpfspolarvfs数据预读数据预扩展Persisted BufferPoolFull Page SnapshotWAL BufferWAL SenderLogIndexPageIDLSNWAL Meta QueueCSNRW节点存储层缓存层志层PageIDLSN事务层libpfspolarvfs数据预读数据预扩展Persisted BufferPoolFull Page SnapshotWAL B

4、ufferWAL SenderLogIndexPageIDLSNWAL Meta QueueCSNRO节点PageIDLSNWAL FileShared-Storage多版本Data FileLogIndex FileWAL FileWAL File多版本多版本Data FileData FileLogIndex FileLogIndex File模块栈-关键技术点 事务层：CSN快照 志层：复制WAL Meta、Lazy回放，并回放，LogIndex 缓存层：常驻BufferPool、多版本 存储层：DirectIO、数据预读、预扩展、PolarVFS1.PolarDB云原架构-数据致性内存

5、状态同步 WAL和Data被共享 仅需复制WAL Meta 基于共享的Data和WAL在内存中回放Shared-StorageReplica节点WAL100500Data200Shared-StorageWALMeta 100WALMeta 500100500Master节点500100500200+=问题：数据共享存储 会导致不致500100500200+=200UpdateLSN=200LSN=200500P1数据志数据Shared-StorageLSN=200600P1500P1500P1T1T2发送志200T3接收到并且回放志200T4T5再次从共享存储读取P11.回放位点LSN=20

6、0 2.Buffer淘汰后再次reload 3.期望看到最新的600，因为之前回放过了LSN=200数据此时P1是个“过去”的！P1从BufferPool中淘汰update 500-600时间不落盘RW节点RO节点UpdateLSN=200500P1600P1500P1UpdateLSN=200500P1600P1500此时P1是个“过去”的！1.PolarDB云原架构-数据致性问题1-“过去”“过去”备库在内存中回放得到的新被丢弃LogRecord=200P1Shared-StorageLSN=200P1DataFileRO节点LogRecord=400LogRecord=800LSN=40

7、0 LSN=800WAL FileLogRecord=200P2P2P1P21.PolarDB云原架构-数据致性问题1-“过去”的解法“过去”-解法（按需回放）在只读节点内存中维护每个Page对应的志meta。在读取时个Page时，按需逐个应志直到期望的Page版本 应志时，通过志的meta从Shared-Storage上读取。问题：Page到WAL志的映射 会导致内存放不下1.PolarDB云原架构-“过去”的解法-LogIndex数据结构LogIndex（Page到志的hash映射）本质是个可持久化的hash数据结构 按照区间分组 建PageID到WAL Meta列表的映射 按照LSN回收

8、 作“过去”“未来”加速回放UpdateLSN=200LSN=200500P1数据志数据Shared-StorageLSN=200700P1700P1700P1T1T2发送志200T3接收到并且回放志200T4T5再次从共享存储读取P11.回放位点LSN=200 2.Buffer淘汰后再次reload 3.期望看到最新的600，由于Master刷脏看到了超前的700数据此时P1是个“未来”的！P1从BufferPool中淘汰update 500-600-700Master节点RO节点500P1UpdateLSN=200500P1600P1700此时P1是个“未来”的！LSN=300LSN=30

9、0志LSN=300LSN=200LSN=200500P1700LSN=300LSN=300刷脏进程将最新P1刷到共享存储上1.PolarDB云原架构-数据致性问题2-“未来”“未来”主库刷脏速度于备库回放速度1.PolarDB云原架构-数据致性问题2-“未来”解法“未来”解法-刷脏控制：1.只读节点回放到T4位点;2.主节点在刷脏时，对所有脏按照LSN排序，仅刷在T4之前的脏(包括T4)，之后的脏不刷;3.其中，T4的LSN位点称为“致性位点”;回放位点UnflushableFlushable存在未来太多占满BufferPool，导致Primary不可全部未来Master节点的 BufferP

10、oolMaster节点RO节点T4T2T1T3T4T2T1T3T5T6T7问题：控制主库刷脏速度：可能导致主库内存不1.PolarDB云原架构-数据致性问题2-“未来”解法“未来”-多版本：1.主库刷脏时写“多版本”；2.多版本信息通过LogIndex同步到备库；3.备库回放时按需读取Page的特定版本和WAL志；避免写放：刷脏控制+多版本 1.PolarDB云原架构-低延迟复制WAL bufferShared storageDMLWalsenderWalreceiverShip metaLogIndex meta queueLogIndexLogIndex meta queue户/后台进程C

11、ritical path for lagParse MetaBuffer 内容修改读取PageDML回放进程LogIndexBuffer内容修改读取PageOffloading基于LogIndex 多版本回放仅标记为Outdate不在BufferPool中需读取回放Master节点RO节点1.仅复制Meta；2.延迟回放；3.回放offload到session进程；络传输量（MB）0350070005112,274PGPolarDBRO上负载场景延迟对(ms)030060090012001301,104PGAuroraPolarDB*32C/256G TPC-B scal

12、e=5000 time=30min2.PolarDB-HTAP架构2.PolarDB-HTAP-背景TP系统处理AP查询的挑战：1.法发挥多个计算节点的CPU/Mem/IO 2.法发挥存储 池的吞吐能读写节点IOShared-StorageProcessChunkSvrCHUNKChunkSvrCHUNKPolarFSNICCPUMem.只读节点IOProcessPolarFSNICCPUMemChunkSvrCHUNK查询只能单机Scale Up般的解决案：TP数据导到AP系统中 1.数据时效性不好 2.成本增加 3.运维难度增Primary（读写节点）ReadOnly（只读节点）ReadO

13、nly（只读节点）ReadOnly（只读节点）ReadOnly（只读节点）MemoryCPU2.PolarDB-HTAP架构基于共享存储的MPP 1.ScaleOut：充分多个RO节点资源 2.套数据，两套计算引擎（毫秒级数据新鲜度）1.单机执：并发TP查询 2.分布式MPP执：复杂AP查询 3.Serverless：SQL级别弹性扩展计算资源 4.TP和AP物理隔离MemoryCPUMemoryCPUMemoryCPUMemoryCPUShared-StorageChunkSvrCHUNKChunkSvrCHUNKChunkSvrCHUNK单机引擎：TP型查询分布式并计算引擎：AP型查询2.

14、PolarDB-HTAP架构-原理Shared-Storage只读节点(Coordinator)Hash JoinShufflePxScan AHashShufflePxScan BShuffleShuffleHash JoinHashShuffleShuffleShufflePxScan AShufflePxScan BLocalAggLocalAggShuffleShuffleShuffleFinalAgg表A表B部分A只读节点只读节点部分B部分A部分B只读节点只读节点只读节点只读节点PxScan分扫描算Shuffle算如同执单机算样Hash JoinAggScan AScan B架构理论

15、 1.Shuffle算屏蔽数据分布 2.PxScan算屏蔽共享存储Virtual Partition-1Virtual Partition-2Virtual Partition-3Virtual Partition-4Virtual Partition-1Virtual Partition-2PX ExecutorParser/Analyze/RewriterPlanner单机ExecutorTransformationsPxSeqScanPxIndexScanPxBitmapScanPxShufflePX Planner(GPORCA)TransformationsProperty Enfo

16、rceTransformationsPolarDB-O CostModelShared-Storage AwareMVCC(CSN)Buffer PoolStorage Layer优化器执器事务层Buffer层存储层2.PolarDB-HTAP架构-模块栈SeqScanIndexScanSortAggHash/NestLoop/MergeJoin.interconectDispatcher分布式执引擎 1.分布式执器 2.事务致性 3.分布式优化器 4.SQL全兼容Global Snapshot致性PxShareSeqScanPxShareIndxScanPxDynamicScan2.Pola

17、rDB-HTAP架构-基于共享存储MPP的优势弹性扩展优势：1.多个Coordinator 2.计算/存储动态扩缩容 3.SQL级别动态并度消除数据倾斜：能者多劳2.PolarDB-HTAP架构-TPCH性能分布式并/单机并的加速0 x23x45x68x90 x62增加CPU和执时间关系 1.16到128core线性提升 2.单条SQL线性提升分布式并/单机并的加速 1.3个SQL加速60 x 2.19个SQL加速10 x增加CPU和总时间关系(秒)0200040006000800016core32core64core128co

18、re256core0300600900895122PolarO(dop=1)dop=2dop=4dop=8dop=16测试环境：1TB，16RO，16c，126GB2.PolarDB-HTAP架构-TPCH性能04008004567895122GreenplumPolarDB(dop=1)PolarDB(dop=16)相同并度时(dop=1)：1.PolarDB性能是GP的90%02000400060008000GreenplumPolarDB(dop=1)dop

19、=2dop=4dop=8dop=16PolarO弹性扩展到dop=8时：1.PolarDB性能是GP的6.2倍并度2*16=32弹性扩展CPU，数据需重分布并度4*16=64并度8*16=128并度16*16=256并度16并度16RWShared StorageHeap File(QC进程)(btbuild进程)Branch pageleaf pageleaf pagePagePx Gather SortIndex FileIndex PageShareMemBTBuildbuild index tupleRO1PxScansortRO2PxScansortRO3PxScansort2.Po

20、larDB-HTAP架构-加速索引构建导数据之后会建量索引：1.MPP加速排序 2.全流+Batch写500GB索引创建时间(秒)050001248单机并PX跨机并索引字段的个数写IndexPage读取HeapPage 并排序效果：1.建索引性能提升45倍PagePagePagePagePagePagePagePagePagePagePageIndex PageIndex PageIndex Page2.PolarDB-HTAP架构-加速时空数据库背景 1.计算密集型 2.RTree索引粗过滤单表查询计算区域积006000原单机1个RO2个RO3个R

21、O4个RO5个RO2表join计算重叠积0750050000原单机1个RO2个RO3个RO4个RO5个RONestLoop Index JoinPartital Scan(A)RTree Index Share Scan(B)分布式执 1.NestLoopIndex Join 2.感知共享存储的ShareIndexScan时空业务提速效果：80CPU，提升71倍测试环境：40000w，500GB，5RO，16c，126GB3.PolarDB-源代码开源3.PolarDB-源代码开源PolarDB开源策略 1.100%兼容PostgreSQL 2.内部代码全部开源 1.PolarDB内核 2.PolarDB分布式件系统 3.PolarDB云管控https:/ 1.整体架构档 2.核功能档 3.快速档 4.每周有直播讲解PolarDB内核原理