云原生数据库海山（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计划在性能提升和成本控制方面实现突破，从而解决市场推广过程中遇到的主要问题，并为用户提供更优