最近在学习PostgreSQL的一些知识，偶然看到OpenGauss 两天8小时的训练营活动，就报名参加了。
最近两年国产数据库可谓百花齐放，开展的如火如荼，种类多达上百种，经过两天的课程对OpenGauss 有了初步的了解。
在整个体系结构上OpenGauss与Postgre还是很多不同：
宏观架构
执行模型：
Opengauss 是线程模型，动态分配执行线程，支持1万并发。
postgre 为进程模型，一个连接一个进程，并发小于1000。
内存模型：
opengauss 进程内内存被多线程共享，内存安全性好。
postgre 多进程共享内存，内存安全性弱； 动态扩展难。
事务处理
并发控制：
opengauss 事务支持CSN 快照，procArray 免锁高并发。
postgre 事务ID回卷，长期运行性能因为ID回收周期大幅波动。
日志和检查点：
opengauss 增量checkpoint ,性能波动< 5%
postgre 全量checkpoing ，性能短期波动 > 15%
鲲鹏NUMA ：
opengauss NUMA多核优化，单机两路性能TPMC 大于150W。
postgre NUMA多核能力弱，单机两路性能TPMC < 60W。
数据组织：
opengauss 多引擎，支持行存，列存，内存引擎，在研DFV存储引擎。
postgre 仅支持行存。
印象较深刻的是在两种数据磁盘保护方面：
Opengauss 使用的是double write, Postgre使用的是full page write。
我们知道操作系统数据块是4k, 数据库的数据块一般是8k/16k/32k, 这样有可能造成partial page write （页面断裂）问题，一个数据库数据块刷到操作系统的过程中可能发生宕机造成块损坏数据库无法启动。
mysql 通过双写double write 来解决这个问题，oracle 不管这个问题，有问题时通过rman或dg备库来恢复，pg 通过full_page_write 来解决，就是在数据页第一次发生变更的时候将整个页面记录到xlog日志中，这样出问题就有完整的数据页加xlog日志进行恢复，但这样带来的问题就是大大增加了xlog的日志量，对性能有一定影响。
opengauss实现了类似mysql的双写，写数据块的同时将脏页也写到一个共享的双写空间里，如果发生问题会从双写空间里找到完整的数据页进行恢复。 双写特性参数enable_double_write需要配合增量检查点一起使用。
