He3DB是基于PostgreSQL开发的面向算力网络的云原生数据库，那么它是如何实现的，相比PostgreSQL又做了哪些改动呢？我们将分析He3DB是如何设计的，思考其背后的设计逻辑。分析村算分离、日志服务两个方面的优化提升。
云原生数据库的由来
最早的数据库都是部署在物理机上，比如PostgreSQL、MySQL。后来，随着云计算的发展，应用上云，有了在云上部署数据库的需要，诞生了云数据库。但是云数据库有其不足之处，为了解决云数据库的不足，云原生数据库Aurora诞生了，提出了Log is database的概念，采用存算分离共享存储的架构。
设计逻辑
存算分离
云原生数据库须采用存算分离的架构，否则无法发挥其云计算相比物理机的最大优势——弹性。在存算分离的架构下，原有数据库刷页落盘持久化，WAL只作为Redo日志作为故障恢复使用，其中后台进程不断的刷页落盘将不再可行，因为存储节点与计算节点是分离的，不再是处在同一个单机实例中，刷页落盘需要通过网络进行，而网络是非常慢的，采用这种方式其相比单机PostgreSQL数据库，其还有性能劣势，明显，这种方案是不可行的，即计算节点与存储节点之间不能采用原有的刷页落盘持久化的方式。那怎么办呢？除了缓存中的页，WAL日志存储了数据库的所有修改，可将其发送到存储节点，存储节点不断的重放WAL日志，代替刷页，其相比页空间要小很多。
所以，相比PostgreSQL，He3DB计算节点要将WAL日志发送到存储节点，不再将WAL放到pg_wal本地盘中。
日志服务
PostgreSQL中高可用是通过主备方式实现的，即，主节点通过流复制将WAL日志发送到备节点，备节点重放WAL日志。而在He3DB中，高可用是通过存储节点集群实现的，即将WAL存储在分布式存储中，在分布式存储中，WAL会保存多副本，通过Raft协议保证副本一致性。这样即使1个存储节点挂了，也不会造成数据丢失。
所以，He3DB计算节点，需要将生成的WAL日志发送到Tikv中存储，将WAL元数据信息通过Wal sender进程发送到推进节点的wal receiver进程中，不在需要将完整WAL日志发送到只读节点。
当然，不同的云原生数据库，其设计是不同的，这里只分析He3DB的逻辑，其实，大的方向都是想通的。都可以参考Aurora的设计。
