共计 2973 个字符，预计需要花费 8 分钟才能阅读完成。
简介：云原生的 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 数据库，会成为下一个五年的云数据库发展趋势。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
