本文由云+社区发表

本文作者：孙旭，腾讯数据库开发工程师，9年数据库内核开发经验；熟悉数据库查询处理，并发控制，日志以及存储系统；熟悉PostgreSQL（Greenplum，PGXC等）、Teradata等数据库内核实现机制。

CynosDB 是腾讯数据库研发团队推出的自研数据库，有PostgreSQL和MySQL两个版本。本文以兼容PostgreSQL版CynosDB为例，介绍我们的架构设计和优化思路。

1、概述

PostgreSQL是世界上最先进的开源数据库，始于1986年，有30多年的社区演进历史。其先进的架构、可靠性以及丰富的功能已经获得业界高度认可。同时，PostgreSQL能够在多种操作系统上运行，支持多种索引类型和扩展，特别是对PostGIS扩展的支持，可以让PostgreSQL轻松的处理地理信息数据。

兼容PostgreSQL版CynosDB作为PostgreSQL在NewSQL领域的一个产品，也具有良好的扩展性。由其架构特点带来的资源池化，可以让用户付出更少的成本而获得同等的性能，并且不损失PostgreSQL数据库原有的功能特性。

2、基础架构

现有共有云上的数据库存在一些不足：

1.网络IO重。传统云上的主备架构下，会有大量数据需要写到磁盘，主要包括：WAL LOG、脏页数据、防止页部分写的Double Write或者Full Page Write。

2.主从实例不共享数据。一方面浪费了大量存储，另一方面进一步加重了网络IO。这样会导致磁盘利用率低、CPU闲置等问题。

而CynosDB可以通过日志下沉、共享存储来解决上述问题，以实现共有云数据库的高性价比、高可用性以及弹性扩展。其基础架构如下：

img

架构中的组件：

\1. master是数据库的主实例，负责接收应用的读写事务请求。

\2. slave是数据库的只读实例，负责处理应用的读请求，可以支持多个slave实例。

\3. CynosStore Client提供访问分布式存储（CynosStore）的接口。DB引擎通过这些接口访问存储，完成数据文件的读写等操作。

\4. CynosStore是一个分布式存储系统，存放数据库的数据和日志，并负责日志到数据页面的转换。

\4. 集群管理服务负责整个系统的管理，例如：存储扩容，实例创建等。

\5. 冷备存储用来存储系统的日志。

master实例将数据的变更以日志方式发送到存储系统（CynosStore）中，同时CynosStore会定期将日志合并到数据页面上。因此，CynosDB无需将脏页写入到存储中，这点与传统数据库是不同的。slave数据库实例没有写事务，不会向存储发送日志，但是会从存储中读取页面，也会接收master实例的日志来刷新内存中的数据页面；如果收到的日志所对应的页面没有在slave的内存中，则会丢弃这些日志。

从架构上看，CynosDB实现了存储和计算分离，并把资源进行池化，因此适合云上部署。而且计算和存储传输数据的仅有日志流，无需写脏页面，因此也减少了系统中的网络量。总的来说，CynosDB具有如下优势：

1.计算能力弹性扩展。可以快速增加slave节点来扩展读能力，而不必进行全量的数据拷贝。

\2. 存储能力弹性扩展。不像传统数据库那样受单机存储能力的限制。

\3. 充分利用硬件资源。缓解传统主备架构中的CPU闲置、磁盘利用率不高等问题。

\4. 备份容易。备份完全由后台持续进行，用户无需干预。

3、兼容PostgreSQL版CynosDB的计算层架构

CynosDB实现了计算与存储分离，系统也因此被分成两大块：计算层和存储层。计算层负责SQL解析、日志生成等；存储层负责数据存储、日志归档以及日志合并等。本节以CynosDB的PostgreSQL兼容版本为例来介绍计算层架构。其计算层架构如下图所示。为了实现这种NewSQL架构，我们对PostgreSQL内核做了新设计：

img

灰色部分是PostgreSQL内核原生模块：

\1. SQL：PostgreSQL的SQL引擎，包括词法/语法分析、语义分析、查询重写/优化和查询执行。CynosDB的设计不涉及SQL层改动，因此它兼容PostgreSQL原来的SQL语法和语义。

\2. Access：数据库的访问层，定义了对象的组织方式和访问方法。其中包括：

lHeap：表实现以及访问方法，包括扫描、更新、插入、删除等。

lbtree/gin/gist/spgist/hash/brin：索引实现，包括各种索引的实现和操作方式，如索引扫描、插入等。

lCLOG/MultiXACT：与事务提交状态以及并发等。

Access是设计和优化的重点模块。当表和索引等数据库对象被修改时，原生的PostgreSQL会生成XLog，并写入到日志文件中。在CynosDB中，这些对象修改时也会生成日志，但是这些日志不会写本地的日志文件，而是发送到CynosStore中。

\3. storage/buffer：buffer pool和存储管理，调用文件接口对数据文件进行读写。在CynosDB中使用CynosStore Client对CynosStore中的文件进行操作。

\5. CynosStore Client提供访问CynosStore的接口，以完成数据库对数据文件的操作。包括数据页面读取接口、日志发送接口等。

\6. 分布式存储CynosStore是一个基于日志的分布式的块存储，在本文中不做重点介绍。

CynosDB的计算层把数据文件修改所生成的日志，通过CynosStore Client发送到分布式存储CynosStore中，而CynosStore会将日志定时合并到数据页面上。这里比较重要的一点是，计算层写出日志并不是PostgreSQL原生的XLog，而是我们自己重新设计的日志系统和日志格式。因此CynosDB不依赖于PostgreSQL的原生日志系统，这种设计也可以让我们有机会在CynosDB上做更多的性能优化。具体可以参见下节。

4、架构优化

CynosDB计算层的架构设计遵循了如下思路：

1.“极简IO”。即，降低网络/磁盘IO

\2. 高效的系统设计。异步的日志设计、降低计算层CPU负载

通过这些设计，使CynosDB的性能比云上的同等配置性能要高。本节主要介绍计算层所做的优化手段。

4.1 日志系统

兼容PostgreSQL版CynosDB的底层存储CynosStore是一个支持日志写的、可以提供多版本读的、分布式的块设备，DB引擎对存储中文件的修改，都是以日志的方式发送到存储中。其日志格式是：<页面号，页面偏移，修改内容，修改长度>，含义是：在页面的哪个偏移做了什么内容的修改。这样设计的日志是幂等的。

以表插入元组为例，PostgreSQL原来的XLog日志格式可能是：

<relfilenode, pageno, offsetnum,informask2,infomask,hoff,tuple_data>：代表在页面（由relfilenode和pageno来确定一个页面）的offsetnum位置插入一条元组，插入的元组是在恢复时由informask2, infomask, hoff, tuple_data等信息进行重构。

同样的操作，在CynosDB中生成的日志可能如下。假设在页面号为n的页面上插入元组tuple：

<n,10,(char *) &pd_flag,2> -- 保存页面头pd_flag到日志

<n,12,(char *) &pd_lower,2> -- 保存页面头pd_lower到日志

<n,14,(char *) &pd_upper,2> -- 保存页面头pd_upper到日志

<n,36,(char *) &ItemIdData,4> -- 保存ItemIdData数组的第3个元素到日志

<n,7488,(char *) tuple,172> -- 保存tuple到日志

这些条目记录了页面在插入元组时的所有修改，它们最终会在CynosStore Client中形成一个MTR（mini-transaction record：多条日志的集合，代表对数据库存储结构的一次原子修改，例如：btree结构、页面结构的修改；在日志重放的时候需要将一个MTR的所有日志都应用完毕，否则会导致数据库存储结构的破坏），并放到日志流中发送到存储。当存储需要将这个MTR合并到页面时，要保证MTR中的所有日志应用完毕，任何不完全的应用都会导致页面结构不正确。

利用日志特点，我们对PostgreSQL 的内核进行了优化，而优化之后的日志大小开销与PostgreSQL的原生XLOG差不多。这些优化和设计包括：

\1. 移除原本PostgreSQL中full page write（FPW）特性。为了保证系统crash再重启之后，那些部分写的页面（torn page）可以被正确恢复，PostgreSQL在Checkpoint之后，对页面执行第一次被修改时，会将整个页面记录到日志中，这种特性就是FPW，类似MySQL的double write。当crash recovery时，系统会以这个全页作为基页面进行日志回放，并将恢复好的页面写到存储，而不必关心存储页面中的页面是否是半页。由于CynosDB日志的幂等性，当出现半页写时，系统直接重新在此页面上直接进行日志回放，即可将页面修复到一致状态。因此CynosDB中无需原生的FPW，从而减少了日志量。

\2. 移除系统中脏页面刷盘操作。CynosDB通过日志保存页面的修改，并且可以通过在基页上合并日志而得到最新页面，因此无需原本系统的刷脏操作，仅仅刷日志就足够。

通过如上优化，可以很大程度上减少网络IO和日志量。

\3. 除了以上对PostgreSQL内核的优化，CynosDB对日志的记录方式也进行了精简和压缩。CynosDB的日志都有日志头（LogHeader），如果修改同一个页面的多条日志共享一个日志头，则可以省去多个日志头的开销，如下图所示：

img

LH代表LogHeader，Log Element代表对页面的页一次修改。如上图，有两条对Block1的修改日志，并且每个修改都有一个日志头（LH），经过日志头合并优化后，形成新的MTR中，修改Block1的那些日志共享了同一个日志头。

如果修改同一个页面的两条日志是相邻的，那么可以将两条日志进一步合并成一条日志。这种方式减少了日志条目，从而可以提高日志合并和页面生成速度。

4.2 页面CRC

在PostgreSQL中，页面在刷盘前会计算并填充页面的CRC属性，而在CynosDB中，如果为CRC也生成了一条日志写入到存储中的话，会增加计算节点的CPU负担和日志条数。为了解决这个问题，我们将CRC的计算任务下放到存储中，从而减轻了计算层的CPU负担，以及日志条数。

4.3 异步表扩展

原生的PostgreSQL数据库使用的是本地文件系统存储数据，其文件扩展操作同步并实时的反映到磁盘文件上。但是CynosDB的扩展操作是通过日志实现，如果每次扩展都对日志做一次flush操作，让扩展实时的反应到存储上，势必会影响系统的性能。因此，我们实现了文件的异步扩展，即文件扩展的日志先保留在系统的日志buffer中，而不是每次扩展都实时的刷新到存储中，当事务提交的时候再把这些日志刷到存储上，对数据批量导入的性能提升很明显。另外，扩展操作可以一次性在文件中扩展出多个页面，减少调用扩展操作的次数。

后续

后续我们会在新硬件、多Master架构等领域作更多探索，为云上的数据库产品形态带来更多惊喜和亮点。

此文已由作者授权腾讯云+社区发布

---