暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

剖析 Google AlloyDB、Amazon Aurora 和 MariaDB Xpand 的架构

原创 eternity 2022-07-11
478

欢迎AlloyDB

最近,谷歌宣布了他们的AlloyDB database-as-a-service(DBaaS)产品,其设计与用于PostgreSQL的AWS Aurora惊人地相似。该公告提到了几种优于Aurora的声称,例如多级缓存、存储层的弹性、在线分析处理(OLAP)查询的柱状数据的矢量化处理等。但从根本上讲,该设计类似于Aurora,Amazon将其描述为“日志就是数据库”。

对于那些不熟悉数据库内部结构的人,绝大多数数据库系统都使用预写日志(WAL)来持久记录崩溃恢复和复制的所有更新操作。除WAL外,传统数据库系统还具有包含实际数据和/或元数据(如系统目录和索引)的数据页。Aurora和AlloyDB背后的主要思想是使WAL成为数据库的主要持久性层,并专用于异步实现和缓存数据页的专用存储服务。这可能适用于写密集型工作负载或具有高缓冲区缓存命中率(高度本地化的访问模式)的读密集型工作负载。然而,对于许多不符合这两个特征的实际应用程序,性能可能会受到影响。原因是,异步物化数据页的成本会带来很大的开销和延迟。这被称为滞后效应。

作为“日志就是数据库”方法的一个隐喻,这就像你从头到尾阅读一本书,但随着作者的更改,你会看到一个带有时间戳的原始手稿编辑列表。大多数作者不是从头到尾写一本书,而是在不同的时间写不同的章节,然后进行多次编辑。类似地,这就像你去听音乐会听交响乐,期待它从头到尾演奏——但相反,你不得不听乐谱的所有变化,按照它们发生的顺序。除了莫扎特之外,大多数作曲家并不是一气呵成地写出他们的杰作。相反,他们在这里和那里写了一些笔记,后来进行了多次编辑,并在不同的时间处理了整个作品的不同部分。对于读者或听众来说,相当具有挑战性的练习是从按时间顺序编辑的集合中重新组合整本书或交响乐。

当必须检索尚未在缓存中实现的数据库片段时,Aurora和AlloyDB都必须处理的问题是,它必须从WAL中重建。这是一项成本高昂的操作,需要根据日志序列号(LSN)和数据页码从WAL中提取一个块。将数据页拼接在一起并最终使用这些物化的页面来满足查询需要时间,这与传统的数据库系统相比会造成延迟,传统的数据库系统只会读取数据页,如果它在缓存中不存在的话。

虽然AlloyDB吹嘘他们的产品是“计算和存储分解”的一个很好的例子,但他们的实现是这种架构的反模式。在某些情况下,“智能”或“应用程序感知”存储可以有益地用于卸载数据库操作,例如谓词下推到存储层。但是,异步执行数据页物化通常不是一个好的设计决策,因为它支持广泛的工作负载类型,例如那些在写入后立即读取最近更新的数据的工作负载类型,这是一种常见的访问模式。

总而言之,这让我有点难过地认为,Aurora和AlloyDB不仅是相似的,他们是LemmingDB的——小白引领小白,加入了一长串以某种方式将自己定位为“PostgreSQL兼容”的数据库产品。作为PostgreSQL的原始开发人员之一,我对20世纪80年代中后期加州大学伯克利分校的Postgres项目的原始目标以及它的演变有一些看法。查看我最近关于权衡PostgreSQL利弊的博客。虽然当前的许多产品以“开放性”的名义声称与PostgreSQL具有一定程度的兼容性,但它们受到PostgreSQL固有的许多问题、缺点和包袱的阻碍。有些人已经设法克服了其中的一些问题,但没有一个能够全部解决。

如果您有兴趣从一长串类似旅鼠的数据库供应商那里购买数据库,请务必考虑使用AlloyDB、Aurora或几种与PostgreSQL兼容的产品中的任何一种。

现代的替代方案:分布式SQL

就我个人而言,我最近决定加入MariaDB Xpand项目,重点关注地理分布能力。Xpand是一种基于无共享架构的成熟分布式SQL数据库。与AWS Aurora或Google的AlloyDB存储复制不同,Xpand是一个真正的多写入程序数据库。任何节点都可以写入,添加节点可以增加读写的规模。

与性能高度依赖于应用程序工作负载特征的数据库不同,MariaDB Xpand为各种客户工作负载类型提供了一流的性价比,而与工作负载的数据访问模式无关。它具有高效的并行查询执行和并行I/O路径,并且不需要“物化”数据页。这与AlloyDB和Aurora采取的方法形成了对比,后者在某些访问模式中受到滞后效应的影响。

很高兴看到AlloyDB认识到需要支持基于柱状模型的操作分析类型查询。Xpand实际上是第一个为OLAP查询实现列索引的现代分布式SQL数据库。Xpand使用列索引直接对事务数据进行实时操作分析,而不会丢失一致性或丢失最新的事务。

更多资源

  • Xpand可以安装在公共云中的本地环境中,并在MariaDB SkySQL中作为一个完全受管理的云数据库服务提供。

  • 接受分布式SQL挑战:如果您正在为即将到来的项目评估分布式SQL,请接受我们的分布式SQL挑战,以获得性能最佳的分布式SQL数据库。

发表评论

登录您的MariaDB ID帐户发表评论。

原文标题:Dissecting the architecture of Google AlloyDB, Amazon Aurora, and MariaDB Xpand
原文作者:Curt Kolovson
原文链接:https://mariadb.com/resources/blog/dissecting-the-architecture-of-google-alloydb-amazon-aurora-and-mariadb-xpand/

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论