前几天发了一篇文章，讲解了信通院分布式数据库发展报告的内容。有朋友告诉我，Aurora、AlloyDB、PolarDB等也属于分布式数据库。觉得有点不解。其实这就是ICT报告中的分类，也与国际通用的分类方法一致。仔细研究它的架构特点，我们也可以发现，这些数据库产品（或者严格来说，数据库服务产品）解耦了传统的中心化数据库和处理负载下载，这与我们传统的中心化数据库读取是不同的。写分离是完全不同的，但是从我们的使用习惯来看，这个数据库好像和我们使用的中心化数据库没什么区别。今天我就以Google的AlloyDB为例，分析一下这类数据库的一些技术特点。今年4月的GOOGLEI/O上??，AlloyDB应该是一个非常亮眼的地方。从谷歌官网也可以看出一些对AlloyDB的信心。以只有谷歌能提供的方式使用PostgreSQL是不是疯了，亚马逊的Aurora何去何从？这么多PG生态的分布式数据库放在哪里？其实上图已经指出了AlloyDB的成功点。PostgreSQL数据库+云原生架构+优秀的工程团队+AI/ML基因是AlloyDB成功的四大关键。根据Google公布的性能，AlloyDB在OLTP场景下的处理性能比原生PG提升4倍，在OLAP场景下提升100倍。虽然目前还没有正式的测试结果，但业内普遍认为，在OLTP场景下，AlloyDB在处理性能上比Aurora快2倍以上，而在OLAP场景下，则呈现秒杀的情况。AlloyDB是如何做到这一点的？我们的数据库厂商是否也能充分借鉴AlloyDB的经验，进一步优化我们的数据库产品呢？其实AlloyDB也是充分学习了Amazon的Aurora“日志就是数据库服务”的理念而开发的数据库服务产品。AlloyDB结合自身优势，发扬了Aurora的优点，有效弥补了Aurora的短板。在官网上，AlloyDB结合了谷歌的横向扩展计算和存储、业界领先的可用性、安全性，以及支持AI/ML的管理，具有完全的PostgreSQL兼容性（基于PG14.4），以及性能、可扩展性、可管理性。用更通俗的语言表达，AlloyDB保持了对PostgreSQL的全面兼容，并在水平扩展、计算能力、可用性和安全性等方面充分利用了谷歌云的分布式架构。并充分利用AI/ML技术。2014年出现的亚马逊Auora是一款真正的云原生数据库产品。其数据库服务本身的RDBMS虽然是基于MySQL和PostgreSQL这两个开源数据库，但是充分利用了多副本复制和多ZONE高可用的特点，打造了一种全新的非对称读写分离的数据库服务架构.8年过去了，作为后来者，AlloyDB在此基础上有很多值得借鉴的创新。我们先来看看AlloyDB的一些技术特点。在高可用方面，AlloyDB实现了真正的99.99%的高可用，包括耗时的维护工作，并且通过准确的自动检测，AlloyDB可以在大多数故障场景下实现分钟级故障恢复，并且无论数据库的负载和大小如何.通过内存中的列模式缓冲，AlloyDB可以支持更复杂的HTAP场景。AlloyDB的特点来自其独特的架构设计。我们先来看看AlloyDB的读写流示意图。AlloyDB可以在一个区域划分多个安全区域，其主库和只读从库位于不同的AZ。这种架构与Aurora非常相似，两者都使用共享块存储。但是如果我们仔细看这张图，就会发现极光或者国内的一些模仿者有些不同。AlloyDB存储层是一个分布式系统，由三个主要部分组成：1）用于非常快速的预写日志（WAL）写入的低延迟区域日志存储服务；2）处理这些WAL记录，为数据库块生成“物化”日志处理服务（LPS）；3)容错、分片的区域块存储，即使在区域存储发生故障时也能确保持久性。让我们关注LPS，这是AlloyDB和Aurora之间的主要区别。AlloyDB对LPS做了很好的优化。master实例中的WAL数据以流的方式实时传输到其他replicas，用于更新replicas的sharedbuffer，这种更新方式比replicas仅仅依靠WALreplay恢复最新数据的效率要高很多，同时也可以避免master实例大量修改导致replicareplay延迟过高的问题。另外，在这个架构下，类似openGauss的BGWRITER或者PAGEWRITER没有了，完全被LPS替代了。主实例只需要将WAL数据流写入低延迟日志存储，数据文件的改变完全通过日志文件的重放来实现。也就是说，数据库一旦创建，以后所有的页面修改都将基于WALSTREAM，那么困扰PG数据库十几年的FULLPAGEWRITE问题也就烟消云散了。在这种结构下，将永远不需要FULLPAGEWRITE和CHECKPOINT。.以上就是AlloyDB的编写过程。我们可以看到只需要将WAL写入LOGSTORE即可。没有BGWRITER，就不用考虑CHECKPOINT的优化了。如果没有FULLPAGEWRITE，一切都由LPS处理。对于读操作，由于LPS的存在，读操作可能会有一定的性能损失，因为读路径的路径比传统方法要长。所有计算存储分离架构的数据库，都会或多或少地拉长读取的路径，因此会对读取性能造成一定的影响。因此AlloyDB采用了非常激进的缓冲策略，希望通过更高的缓冲命中率来弥补这个缺点。其实在激进的缓冲策略上，谷歌的全系列产品都是如此。Google在这方面积累了丰富的经验，AlloyDB也不例外。除了数据库缓冲区之外，AlloyDB还为计算实例添加了“缓存缓存”。这个缓冲区与Oracle的FlashCache非常相似。它的目的是让被DBCACHE淘汰的数据再次缓冲到这里，避免通过很长的读取路径读取。所以Ultra-fastCache被设计成本地化的，类似于Oracle的FlashCache。Ultra-fastCache可以让更多的数据从本实例的缓存中获取，从而大大减少了由于SHAREDBUFFERS没有命中数据块而导致的IO路径上的各种损失。另外值得注意的是，DB缓存中丢失的数据块是从LPS中获取的，而不是从块存储服务中获取的。LPS除了可以处理WAL之外，还支持PostgreSQL的buffercache接口。它通过缓存来自块存储服务的数据块并将它们提供给主实例和副本实例来实现。因此，LPS有效地成为架构中的另一个缓存层。作为一个存储和计算分离的分布式数据库系统，AlloyDB在设计上的创新还没有结束，因为LPS统一了持久化服务，将传统PG的bgwriter/walwriter和前台进程的功能统一为一个服务，切断了同时后台。访问PAGE的读取路径，真正实现了计算层和存储层的完全分离。在这个架构中，LPS成为了整个数据库的性能点，因为LPS需要不断的申请WAL记录，需要服务于主实例和多个副本实例的读请求。为了解决这个问题，数据库持久层被水平划分为称为分片的块组。分片和LPS资源都可以水平和独立地扩展。每个分片固定分配给一个LPS，但每个LPS可以处理多个分片。分片到LPS的映射是动态的，允许存储层通过扩展LPS资源的数量和重新分配分片来弹性扩展。这不仅可以让存储层扩展吞吐量，还可以避免热点。谷歌官网给出了两个参考场景：第一个例子是当整体系统负载增加时，几乎所有的分片都会收到比以前更多的请求。在这种情况下，存储层可以增加LPS实例的数量，例如将它们加倍。然后，新创建的日志处理服务器实例通过接管它们的一些分片来卸载现有实例。由于这种分片重新分配不涉及任何数据复制或其他昂贵的操作，因此它非常快并且对数据库层不可见。又比如当系统中少数分片突然变得非常热时，同一个存储层可以动态地做出反应——在最极端的情况下，如果发现一个分片过热，访问流量不均匀，就可以避免不足通过将具有非常高负载的分片分配给处理分片负载的专用LPS实例来提高过热分片的性能。因此，借助重新分片和LPS弹性，即使在工作负载达到峰值时，系统也可以提供高性能和吞吐量，并在工作负载再次减少时减少其资源占用。这种动态调整大小和存储层弹性对于数据库层和最终用户来说是完全自动的，无需用户操作。这是对AI4DB功能的出色应用。AlloyDB的存储层采用多副本，其数据的三份副本位于不同的ZONE，保证每个zone都有自己完整的数据库状态副本，因此数据库层的blocklookup操作不需要跨越区域边界。另外，存储层在所有区域持续应用WAL记录，数据库层为其请求的每个块提供目标版本LSN，因此在读操作时不需要读仲裁。集中式数据库的便利性。总而言之，AlloyDB通过将数据库的计算层和存储层解耦，获得强大的水平扩展能力，通过LPS将很多数据库读写操作卸载到存储层。即使在存储层，完全分解的架构也允许它作为一个弹性分布式集群工作，可以动态适应不断变化的工作负载，提高容错能力，提高可用性，并启用具有成本效益的读取池以线性扩展读取吞吐量。Offloading也有效提升了主实例的写入吞吐量，因为它可以完全专注于查询处理并将维护任务委托给存储层。而这种能力来自于AlloyDB的智能数据库感知存储层中对AI技术的使用。我想这些设计思路会给我们国内的数据库厂商带来一种全新的数据库设计思路。分布式数据库的整体架构不一定要完全学习Oracle，但也可以脱离Oracle的技术框架，充分利用开源代码，走一条新路。从今天的描述中，可能有小伙伴发现了AlloyDB与传统中心化数据库的区别。目前我们国内的数据库也在学习Aurora，但是学习的不够透彻。最重要的是存储和计算的解耦不够彻底，无法更好地将负载从计算层卸载到存储层。这是因为我们还没有能够完全改造计算层和存储层之间的接口，使其成为水平可扩展的服务。
