想象一下你正在试图组织一个庞大且混乱的图书馆，数以百万计的人正试图同时借阅、阅读和重写书籍。在计算机科学的世界里，这就是数据库所面临的挑战：这些系统存储信息，以便应用程序能够即时查找和更改它。几十年来，一个大问题是如何让这些图书馆在规模扩大以应对整个互联网而不至于崩溃。旧的方法就像是有一个单一的图书管理员必须为每一本书盖章，这导致了漫长的排队，拖慢了所有人的速度。较新的“最终一致性”方法则像是让人们去猜测书里的内容，并在稍后修复错误，这种方法很快，但如果你现在就需要真相，就会面临风险。现代数据库工程的目标是构建一个既拥有猜测法的速度，又具备盖章法可靠性的系统，能够处理每秒数百万次的事务，而无需任何人手动管理书架。

本文介绍了 Aurora DSQL，这是一种由亚马逊网络服务（AWS）设计的全新类型的数据库，旨在解决这个确切的问题。可以将它想象成一个超级智能的自动驾驶图书馆，它可以根据访客数量即时扩张或收缩。作者构建了一个将“思考”（运行 SQL 代码）与“存储”（保存书籍）以及“规则”（确保没有两个人同时修改同一页）相分离的系统。通过使用一个特殊的“日志”（Journal）——它充当了记录每一次变更的永久且不可更改的日记——DSQL 允许系统的不同部分独立工作。论文表明，这种设计让数据库能够从零用户扩展到每秒处理数百万次事务，可以在不同的洲之间高效运行而不减速，并保持数据完美的连贯性，因此你永远不必担心在别人正在重写一本书时读到它。

解构式图书馆的魔力

要理解 Aurora DSQL 如何运作，请想象一个巨大的图书馆，其中的图书管理员、书架和规则制定者都位于不同的建筑中，并通过超快速的电报连接在一起。在旧系统中，这些部分是粘合在一起的；如果书架满了，整个图书馆都必须停止并重新组织。DSQL 将它们拆分了。

首先是查询处理器（Query Processors）。这些是与你交谈的图书管理员。当你索要一本书时，他们并不亲自搬运沉重的书。相反，他们在被称为 Firecracker MicroVMs 的微型、安全的虚拟房间内运行。这些房间非常高效，可以在瞬间创建或销毁。如果你突然涌入大量访客，系统会立即建造更多房间；如果访问量减少，系统会拆除它们，这样你就不会为闲置的空间付费。这就是“无服务器”（serverless）的部分：你不需要管理图书管理员；他们会在你需要时自动出现。

接下来是存储节点（Storage Nodes）。这些是书架。它们并不持有整个图书馆，而仅根据“分片键”（shard key，例如按作者姓氏的首字母对书籍进行分类）持有特定部分的图书。因为图书管理员和书架是分离的，所以图书管理员可以开展自己的工作，而无需等待书架跟上进度。他们从自己所在社区（可用区/Availability Zone）最近的书架中读取数据，这使得读取速度极快。

最后是仲裁者（Adjudicators）和日志（Journal）。仲裁者是决定变更是否被允许的规则制定者。日志是主日记。当你想要修改一本书（即一次“写”操作）时，图书管理员会将变更写在一张纸上，但暂时不将其放入书架。他们会将这张纸发送给规则制定者。规则制定者会检查是否还有其他人正试图同时修改那本书。如果一切正常，规则制定者就会将该变更写入日志。这个日志是最重要的部分：它是记录有史以来发生过的每一次变更的永久且有序的列表。一旦某项内容进入日志，它就是永久安全的，即使书架或图书管理员消失了也是如此。

“无需等待”的阅读技巧

本文中最酷的技巧之一是它如何处理阅读。在许多数据库中，如果你想读一本书，你必须等待图书管理员确认目前没有人正在其中书写。这会导致排队和延迟。DSQL 使用了一种被称为**多版本并发控制（MVCC）**的聪明“时空旅行”技巧。

想象一下，每当一本书被修改时，图书馆并不会抹掉旧版本。相反，它会创建一个带有时间戳的新副本。当你索要一本书时，你不是在问“这本书”，而是在问“下午 2:00 时的这本书”。系统随后会找到在 2:00 时有效的那个版本。由于系统使用了极其精确的时钟（精确到微秒），它确切知道应该向你展示哪个版本。这意味着你可以在别人编写新版本的同时阅读书籍，而不会看到他们凌乱、未完成的修改。你看到的是过去的一个完美、冻结的快照。这使得数百万人可以同时阅读，而永远不会互相阻塞。

多区域超能力

论文还解决了距离问题。通常，如果你在纽约有一个图书馆，在伦敦也有一个，保持同步需要时间，因为受限于光速。如果你试图同时更新两地的书籍，你必须等待消息跨越海洋，这会减慢一切。

DSQL 通过实现**双活（active-active）**来解决这个问题。这意味着你可以在纽约有一个图书馆，在伦敦也有一个，并且两者都可以同时全速营业。当你在纽约做出变更时，系统将其写入日志。随后，日志会将一份副本发送到伦敦。神奇之处在于，这仅在你在点击“提交”（完成事务）的那一刻发生一次。在消息传输期间，系统不会阻止你进行阅读或写入。它使用“法定人数”（quorum）系统，意味着它只需要在三个区域中的两个区域确认变更，即可称之为安全。

论文测量了这一点，并发现即使在弗吉尼亚州和俄勒冈州之间存在距离（往返约 62 毫秒）的情况下，系统也仅在每次事务中支付一次这种“距离税”。对于阅读，速度甚至更快，因为你从本地图书馆进行读取。作者指出，这种设计使得数据库即使在整个区域（如整个城市）因灾难而离线时，仍能保持快速且一致。

游戏规则

作者对他们的承诺非常谨慎。他们选择了快照隔离（Snapshot Isolation），这是一套关于事务行为的具体规则。这就像是在说：“你可以阅读开始阅读时的书籍状态，也可以在结束时修改它，但如果在此期间有人修改了它，你必须重试。”这与更严格的规则不同，后者会强迫你等待锁定，从而降低速度。

论文明确排除了需要单个“领导者”来管理一切的想法。在许多系统中，一台计算机是老大，如果它坏了，一切都会停止。DSQL 没有单一的老大。每个部分都可以向上或向下扩展，如果某个部分失效，其他部分仍能继续运行。论文还排除了需要你自己管理硬件的想法。系统会自动处理“热度”（即哪些部分变得过于繁忙）。如果图书馆的一个区域变得过于拥挤，控制平面（图书馆管理者）会自动将其拆分为两个较小的部分，并将一些书移动到新的书架上，而无需你进行任何操作。

测试理论

作者不仅仅是猜测这行得通；他们进行了大量的测试。他们使用了一种称为**确定性模拟（deterministic simulation）**的方法，即在计算机程序中运行该系统，该程序可以在极短的时间内模拟数百万个错误、网络延迟和崩溃。他们发现，系统可以处理这些错误而不会丢失数据或产生混乱。

他们还运行了现实世界的风格测试（例如模拟繁忙商店的 TPC-C 基准测试）。结果显示，DSQL 可以从冷启动（即资源非常少的状态）扩展到处理每分钟数百万次操作。它大约需要 25 分钟才能从完全空白的状态升温到全速运转，但一旦进入热状态，它的速度就非常惊人。论文指出，虽然他们对这些结果非常有信心，但他们仍在努力添加更多功能，如外键（用于链接表）和存储过程。

核心结论

Aurora DSQL 证明了你可以兼得两全之利：一个既像简单服务一样易于使用（你无需管理任何内容），又像大规模全球系统一样强大的数据库。通过将思考、存储和规则分离，并利用永久日志来追踪时间，它允许应用程序从零增长到处理数百万次事务而毫不费力。这是一个为这样一个世界设计的系统：在这个世界里，事物变化迅速，灾难随时可能发生，而你需要确信你正在阅读的信息就是此时此刻绝对的真相。