简介：云原生的Serverless数据库，正在成为下一个五年的云数据库发展趋势。 近日，在国际数据库顶级会议2021 ACM SIGMOD上，一篇以PolarDB Serverless为主题的论文，被评委会认为指引了下一代数据库服务的发展方向。 这篇题为《PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers》的论文，介绍了阿里云自研数据库PolarDB基于计算存储分离，实现的最新Serverless技术架构研究进展。 PolarDB Serverless论文的录用，标志着阿里云PolarDB数据库在最新一
云原生的Serverless数据库，正在成为下一个五年的云数据库发展趋势。
近日，在国际数据库顶级会议2021 ACM SIGMOD上，一篇以PolarDB Serverless为主题的论文，被评委会认为指引了下一代数据库服务的发展方向。
这篇题为_《PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers》_的论文，介绍了阿里云自研数据库PolarDB基于计算存储分离，实现的最新Serverless技术架构研究进展。
PolarDB Serverless论文的录用，标志着阿里云PolarDB数据库在最新一代架构的探索上迈出领先一步。
以下是这项突破的核心内容介绍：
_01_第一代云原生数据库的困境
早期的云上数据库，大部分是以ECS中的自建数据库和云厂商托管的数据库RDS的形态存在的，到目前为止还是有非常大的用户量。
这些云上数据库架构还是传统数据库的架构，只是运行在云的基础设施上，数据库本身并没有为云做太多的改造和适配。局限于其架构，各项资源等比率的限制在一个范围内，其弹性范围、资源利用率都受到较大的限制，无法充分利用云的红利。
以亚马逊Aurora和阿里云PolarDB为代表的第一代云原生数据库，第一次对数据库架构进行了改造，实现了存储和计算分离，并基于此实现了一写多读，一定程度上适配云架构，存储完成了池化和按量付费，这是对云数据库非常大的进步。
但此架构下，CPU和内存依然是强绑定的，导致计算要实现真正按需供应也非常困难。也就是说，CPU资源和内存资源是一个整体，只能作为一个最小的单位升降级。例如，在亚马逊Aurora中，计算资源和缓存资源的比例是1core CPU：2GB内存。
然而，CPU和内存资源比例的绑定对一些场景下对用户是不合理的：
例如，分析型内存数据库用户，用户使用少数CPU来定期同步和更新数据，但需要大内存，因为维表数据、或者中间结果需要缓存在内存里避免从磁盘来读的延迟。
事务型数据库，例如电商等互联网应用场景里，客户的应用往往存在热点，因此少量的内存就足够保证缓存命中率超过99%，但高峰时CPU需要弹到64c甚至更多核，CPU的需求会高于内存的需求。
简而言之，因为第一代云原生数据库无法实现计算和内存资源的解耦，这也是导致目前云原生数据库价格依然高于RDS和自建数据库，无法占据大部分市场的核心原因。
_02_ 实现新架构的突破
不过，随着PolarDB Serverless新架构的率先提出，这种情况可能要出现极大改变。
PolarDB Serverless的最大创新之处在于：在业内首次实现了内存与计算/存储的解耦，内存进一步池化，形成三层池化，使得弹性能力有数量级的提升，同时内存池化大幅度降低了成本，实现了完全地按量使用和按需弹性，贴合各种场景。
PolarDB Serverless构建了一个全新的数据库形态，即DCaaDB_（Datacenter as a Database）_：
整个IDC形成一个多租户的大数据库，其全部的CPU，内存，存储构成三个独立的资源池。在资源池未耗尽的情况下，任何一个用户（租户）都可能任意的弹性扩展任何一种资源到任何一个规格，用户为其SQL动态消耗的CPU、内存和存储买单，不需要预置任何的规格。
这种情况下，CPU和内存资源因其池化其使用率将会大幅度提升，云原生数据的成本将会远低于自建和RDS等一体化数据库，云原生技术的价值将会得到充分的体现，数据库市场将会重新洗牌。
_03_ 背后的技术难点
在PolarDB Serverless之前，学术界已经对分离架构有一定的研究，并且也进行了一些技术上的实验，但是都没有解决分离架构下的数据库的性能和弹性问题。
PolarDB Serverless通过进行技术创新解决了困扰业界的难题：
1）
PolarDB Serverless中引入了多租户、分布式的内存池的设计，包括页面分配和生命周期管理。
第一个挑战是增加内存池设计后，确保系统能正确的执行事务。 例如，一个被修改过的数据页不应该读到老的数据，即使跨节点也是如此，我们使用全局的缓存一致的机制（类似于多核cpu之间缓存一致性机制）来实现。
还有，当主节点正在分裂或合并一个 B+Tree 索引，其他节点不应看到中间不一致的 B-tree 结构，我们需要使用全局页锁来保护它。 当节点执行只读事务时，它必须避免读取未提交事务写入的任何内容，我们通过在数据库节点之间同步全局视图来实现它。
2）
第二个挑战是高效地执行事务。Serverless架构对数据库的性能会产生负面影， 因为数据库要从远程访问数据（内存池的或者存储池）的，这会引入额外的网络延迟。
我们大量利用RDMA优化，尤其是one-sided RDMA verbs，包括使用 RDMA CAS来优化获取全局页锁的过程。 为了提高并发性，数据库节点使用乐观锁技术来避免不必要的全局页锁。
此外，PolarDB内核引入一些技术减少读写带宽，例如使用重做日志下推技术后，存储可以直接从重做日志回放出最新版本的页面，因此数据库进程不再需要写脏页到远程存储里。当数据库访问页面而本地缓存不命中时，需要跨网络从远程内存和远程存储中获取页面，这会慢于本地内存和磁盘，因此通过预取提升本地缓存的命中率是提升分析查询类负载性能的关键。
3）
在Serverless架构下，数据库从一个单内核的系统，变成了跨节点部署，并且数据库的部分逻辑嵌入到并运行在内存池和存储池服务里。架构变得更复杂，因此增加了系统故障的种类和可能性。
作为云数据库服务，第三个挑战是构建一个可靠的系统。PolarDB设计了对不同节点类型的单节点崩溃的处理策略，以保证系统中没有单点故障。 并且因为内存和存储中的状态与数据库节点解耦，使用Serverless架构的PolarDB节点的崩溃恢复时间比使用单机架构的PolarDB内核快5.3倍。
在PolarDB Serverless架构之下，我们对数据库的性能进行了一些测试，最终的测试结果也远超预期。
这些结果也让我们有理由预测，使用全资源分离的架构来实现云原生的Serverless数据库，会成为下一个五年的云数据库发展趋势。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。