云原生数据库海山（He3DB）PostgreSQL版核心设计理念

本期深入解析云原生数据库海山PostgreSQL版（以下简称“He3DB”）的设计理念，探讨在设计云原生数据库过程中遇到的工程挑战，并展示He3DB如何有效地解决这些问题。

He3DB是移动云受到 Amazon Aurora 论文启发而独立自主设计的云原生数据库产品，它与 Aurora 以及其他云厂商的同类竞品共享一些核心设计理念，特别是计算与存储分离、日志即数据库（Log is Database）、以及共享存储。这些理念构成了现代云原生数据库的技术基础，目的是为了提高可扩展性、可靠性和性能。

为了方便大家更进一步的了解 He3DB ，下面我也将逐一解析这几个核心设计理念，并探讨 He3DB 在工程实现或产品核心设计上与 Aurora 及其竞品的不同之处。

云原生数据库核心设计理念

1.计算与存储分离：

这一理念意味着数据库的计算层和存储层在物理上是独立的。这种分离使得两者可以独立地扩展，提高了资源利用率，同时也简化了数据的备份和恢复过程。

2.日志即数据库（Log is Database）：

在这种设计下，所有的数据库修改操作首先被记录到日志中，这个日志之后被用作构建和更新数据库状态的唯一来源。这种方法把所有的写转化为日志写，给予我们更多的方法提升写性能以及跨AZ的高可用能力。

3.共享存储：

使用共享存储架构意味着所有的计算节点可以访问同一个存储系统，这样可以实现数据的高可用性和容错性，同时简化了数据管理。

现在即便许多云原生数据库产品在设计上追求解决类似的问题，但在工程实现和产品能力上依然存在显著差异。这些差异导致了性能、高可用性、容量支持以及成本效益等方面的不同。

其实也很好理解，例如，某些产品通过使用高性能硬件提高了性能，但相应地也增加了成本。另一些产品则在底层存储设计上天然支持跨 AZ，从而在高可用性方面表现更佳。

目前许多云服务提供商在推广其云原生数据库产品时强调了它们在多个方面相对于RDS的优势，但从市场接受度来看，RDS依然占据主导地位。这主要是因为云数据库的主要客户群体是中小型企业，这些企业对数据库的负载和存储容量需求相对较低，而RDS的功能和性能已经足够满足他们的业务需求。但由于云原生数据库的架构设计导致其成本相对较高，且在处理小规模数据和低负载场景时，其性能并不总是能超越RDS。所以业内同类竞品在宣传时，往往更强调它们产品能力上限。

而He3DB产品的研发初期，我们除了需要保证它的上限处于业内主流水平，其实更关注的是它的下限表现，因为我们期望最终实现的不仅是在能力上全面超越RDS，同时在全场景使用下，成本也要明显优于RDS。为此，我们分别从“性能”和“成本”这两个方面设定了以下研发目标：

1.性能目标

l 适应性能：确保在低容量和低负载的场景下，He3DB的性能能与RDS相匹配。

l 优越性能：在面对高负载和高容量的情况时，He3DB的性能要比RDS高出2到3倍。

l 性能指标：实现写入吞吐量（TPS）超过10万，读取吞吐量（QPS）超过100万。

2.成本目标

l 成本效益：任意业务场景负载下，He3DB的成本不高于RDS。

l 成本竞争力：竞品相比，He3DB能够实现至少30%的成本降低。

通过制定这些明确的研发目标，He3DB计划在性能提升和成本控制方面实现突破，从而解决市场推广过程中遇到的主要问题，并为用户提供更优的数据库解决方案。

接下来，我将重点介绍He3DB的架构设计，从而解释我们如何实现设计目标，并使它在成本控制上优于传统的关系数据库服务（RDS）以及同类竞品。

3.He3DB设计目标：

l 支持一主15备，能够满足企业对扩展性的需求。

l 支持高达100TB的数据存储能力，适应大规模数据处理需求。

l 主备节点共享存储，这意味着增加备机不会造成存储成本的增加，从而实现了成本效优

l 性能方面，He3DB能够达到读取查询处理速率（QPS）100万次、写入事务处理速率（TPS）10万次的高性能标准。

下面我将从技术角度一一解释He3DB如何实现这些目标。

一、如何支持一主15备：

在PostgreSQL中，随着备机数量的增加，流复制会导致主服务器的性能下降，因为主服务器需要将写操作(WAL)复制到每个备机。在复制过程中，主服务器会遇到瓶颈，尤其是当备机的数量增加到5个以上时。He3DB 需要解决的问题是如何有效地同步和分发日志，以支持一主多备（至少15备）的架构，而不会对主服务器的性能造成显著影响。为此，He3DB采取以下设计：

1. 专用的WAL服务：

提供一个专用的WAL日志服务，该服务负责接收主服务器的WAL日志，持久化存储，并将其分发给所有的备机。这样，主服务器只需发送一份WAL日志到WAL服务，由WAL服务来负责分发给各个备机，极大地减少了主服务器的负担。

2. 异步复制：

采用异步复制机制，主服务器在写入WAL后不必等待所有备份确认，可以立即继续处理新的事务，这有助于提高主服务器的性能。

3. 批量发送和压缩：

WAL服务可以将日志更改批量发送，并在传输前对其进行压缩，以减少网络传输的数据量。

4. 负载均衡和缓存：

WAL服务可以使用负载均衡技术来平衡对不同备机的日志分发，同时使用缓存机制来存储热数据，以便快速分发给备机。

5. 多副本一致性算法：

采用一致性算法来确保WAL服务的高可用和数据一致性，即使在WAL服务节点故障的情况下也能正常运行。

通过这样的设计，He3DB才能够确保即使在多达15个备机的情况下，主服务器的性能也不会受到明显影响，同时保持数据的高可用性和一致性。这种设计是在主数据库和备机之间引入了一个中间层，来协调日志的持久化和分发过程。关于这个模块的设计我以后会专门出一期再跟大家进行详细介绍。

二、如何支持100T 容量：

He3DB采用计算与存储分离的架构，并利用S3作为底层的持久存储层，这种设计具有多方面的优势：

1. 存储容量和弹性：

S3提供了几乎无限的存储容量和良好的弹性。它可以根据需要自动扩展，用户无需预先分配存储空间，也无需担心空间不足的问题。

2. 高可用性和耐久性：

S3提供了数据服务的高可用性以及高可靠性，这意味着数据丢失的风险极低。

3. 成本效益：

相比于高性能硬件解决方案，S3提供了成本效益更高的存储服务。由于其按使用量计费和无需前期投资的特性，用户可以在控制成本的同时享受高质量的存储服务。

4. 性能优化：

通过在S3上层增加数据缓存服务层，可以解决访问S3时遇到的高延迟问题。这层缓存可以用于存储数据，提高访问速度。

5. 自动化扩展和缩容：

数据缓存服务层（DS）支持多节点，并且可以根据业务负载自动扩缩容，对外提供透明服务。这允许He3DB动态地调整资源，以应对不同的负载需求。

6. 数据分层：

通过将数据按热度进行分层，冷数据（低频访问数据）可以在S3中进行极限压缩，以降低存储成本。热数据则存储在更快速的缓存层中，以提供更佳的性能。

总的来说，He3DB通过将S3作为持久层的选择，结合数据缓存服务层的设计，提出了一个既能满足大规模数据存储需求，又具有成本效益，同时能够提供必要性能保障的解决方案。这种架构特别适合云原生数据库的需求，可以有效地支持数据的扩展性、弹性和成本控制。

三、如何实现共享存储：

在He3DB这样的一主多备架构中，数据的一致性是通过日志同步机制来保证的。主节点和备节点之间通过WAL（Write-Ahead Logging）日志来同步数据变更。

为了帮助大家更好地理解共享存储设计，我再简单介绍一些背景知识：

1. 数据写入和一致性：

l 在主节点上持久化写入数据后，由于备节点的数据同步存在延迟，它们读取的数据可能不会立即反映最新的更改，导致主备节点间的数据不一致。

2. 日志顺序号（LSN）和数据同步：

l PostgreSQL在主备节点间同步数据状态是通过日志顺序号（LSN）来标识的。每当主节点上发生数据更改，都会生成一个新的WAL日志条目，并分配一个唯一的LSN。

l 主节点的WAL日志LSN始终是最新的。备节点不断地处理这些WAL日志来追赶主节点的状态。但在WAL日志负载较高的情况下，主备节点可能会在同一时刻对应不同的LSN，从而导致它们所见的数据状态有所差异。

3. 数据PAGE多版本维护：

l 虽然大部分时间内主备节点看到的数据状态是一致的，某些数据可能会因为WAL日志同步的延迟而出现版本差异。为了确保数据的一致性和准确性，数据库本身需要管理数据的多个版本。

l 多版本数据管理机制防止在查询操作中访问到还未同步的“未来”数据版本，或者已经被覆盖的“过去”数据版本。

通过实现多版本数据管理，He3DB确保了即使在高负载情况下，数据最终也能达到一致性，同时避免了因为访问错误版本的数据而导致的正确性问题。

在业界，一些数据库产品在处理数据PAGE版本差异时，选择在计算引擎或存储引擎层面进行设计。通常做法是记录一个基础数据页面（PAGE），然后通过链表记录与该PAGE相关的WAL日志条目，以此来异步回放并实现多版本的数据页面读取。

He3DB最初的设计也采用了这种方法。然而，这种设计在性能达到理想状态方面存在挑战，并且会占用较多的内存资源，因为需要在内存中管理元数据。此外，一旦出现问题，问题定位过程比较复杂。

为了解决这些问题，He3DB进行了设计上的改进，实现了所谓的“分布式多版本数据PAGE控制”：

1.单一数据版本维护：

l 数据存储服务（DS）仅维护单一版本的数据。DS控制WAL日志的回放节奏，确保DS是最慢WAL回放节点。这种设计实质上意味着DS主要负责维护主备节点读取一致的数据部分，而由于WAL同步的差异影响到的数据通常很少。

2.本地盘缓存模块：

在每个计算节点，He3DB引入了一个本地盘缓存模块，专门用于缓存和维护主备节点之间的差异数据版本。例如，如果主节点的当前LSN是100，备机1的LSN是30，备机2的LSN是60，而DS的回放LSN是25，那么：

l 主节点的本地盘缓存模块会维护从LSN 25到100之间变更的数据页面。

l 备机1会缓存从LSN 25到30之间变更的数据页面。

l 备机2会缓存从LSN 30到60之间变更的数据页面。

随着每个节点的WAL日志的不断推进，计算节点能够迅速回收相关的缓存页面数据，从而有效释放存储空间。

看到这里可能有人会问，如果出现本地缓存数据的问题怎么办。这一点我们也有考虑到。

He3DB会基于DS重新生成备份节点，并将其加入集群中，而不会影响数据的准确性。这种新的设计不仅提高了性能，减少了内存的使用，还简化了问题定位和故障恢复的流程，从而大幅提高了数据库的可维护性和稳定性。

四、如何保证高性能以及控制波动率：

He3DB在不引入任何高性能硬件的情况下实现了高性能和控制性能波动的策略。下面我将从写和读两个场景分析性能表现：

1.写性能

He3DB的设计理念是“日志即是数据库”(log is database)，这意味着所有的写操作都被转换为日志写入。通过将日志写操作外包给专门的WAL服务（wal service），HE3DB能够借助WAL服务的高吞吐量来提升写性能。这个设计允许系统将数据写入操作并行化和分布化，从而提升整体的写入速度。