关键字: [亚马逊云科技， 生成式AI， Aurora Limitless Database， 关系型数据库， 生成式Ai应用， 数据存储， 数据查询， 应用扩展性]

导读

马丽丽从亚马逊科技介绍了如何利用亚马逊的关系型数据库Aurora Limitless Database和Aurora Disco快速构建生成式AI应用程序。她解释了生成式AI应用对数据库的需求，包括快速部署、自动扩容、数据持久性、查找现有数据以及与Agentic AI应用集成等。Aurora Limitless Database通过有界时钟同步实现了高性能和可扩展性，支持PGVector向量数据库查询。Aurora Disco则采用了无服务器架构、自动扩缩容、跨区域数据同步等特性，并支持与Agentic AI应用的MCP Server集成。最后，她分享了一个基于Strength Agent构建的Agentic AI应用架构，阐述了数据库在其中的作用。

演讲精华

以下是小编为您整理的本次演讲的精华。

在生成式人工智能(AI)如火如荼的时代，构建生成式AI应用程序对我们来说至关重要。马丽丽女士是来自亚马逊科技的数据库解决方案架构师，她将探讨亚马逊的关系型数据库如何帮助我们快速构建生成式AI应用程序。她将从生成式AI应用程序对数据库的需求、亚马逊最新推出的两款关系数据库Aurora Limitless Database和Aurora Disco，以及在昨天的大会上展示的Stress Agent架构与数据库的关联这几个方面进行阐述。

生成式AI与数据库的关系主要有以下几种可能:首先，我们在构建应用时，更重要的是利用自身已有的数据资产，包括数据库中存储的数据、文档信息、资料库和代码仓库等。其次，在与终端用户交互时，记录用户之前与应用的对话历史对于用户体验至关重要。我们可以直接存储原始对话信息，也可以对信息进行提取和总结后存储。第三，在Agentic AI应用中，我们都在讨论如何在大模型的基础上为其增加更多工具能力，比如MACP Server可以让Agentic AI应用更好地、更快地、更便捷地访问底层各种服务工具集，因此需要考虑是否需要在数据库层封装这种MACP Server。再者，在构建Agentic AI应用时，我们有一些现成的工具包，比如最近推出的Stress Agent这样的SDK，只需几行代码就能帮助我们快速构建Agentic AI应用，因此需要考虑Stress Agent这样的SDK能否与数据库良好集成。最后，生成式AI应用本身也是应用，因此需要存储应用本身的元数据，如用户信息、会话信息等。

在构建生成式AI应用时，对数据库的诉求包括:首先，我们希望应用可以快速部署，在部署时无需考虑选择什么样的机型，也不希望数据库在打补丁升级时影响应用的可用性。其次，应用一开始可能没有太多用户，但可能很快就会有大量用户和流量，因此希望数据库在这种情况下不会拖后腿，能够自动扩容。第三，应用数据对我们来说非常重要，我们希望数据不会丢失，即使应用最终扩展到多个区域，某个区域发生故障时也希望数据一点不丢。再者，我们的应用需要查找已有数据，因此希望数据库能够提供各种查找接口，比如通过SQL直接查找，或者以某种方式查找已有的知识库信息。最后，我们希望在构建时，数据库能够与构建Agentic AI应用良好集成，提供相应的工具支持。

为满足上述需求，亚马逊推出了两款新的关系数据库产品:Aurora Limitless Database和Aurora Disco。我们先来看Aurora Limitless Database，它解决的是数据库扩展性问题。它采用有界时钟概念实现分布式事务，避免了节点间时钟同步的开销。具体来说，它利用了亚马逊的EC2 TempSync Service，将节点间时钟误差控制在50微秒以内，从而提高了数据库系统的可扩展性。

Aurora Limitless Database的工作原理是这样的:假设现在有几个不同的事务在执行，它是如何在中间进行协调的呢?比如说，现在有事务1，它启动了一个新的事务，设置为可重复读的事务隔离级别，然后需要读取客户ID为619的订单信息状态。在这种情况下，它会采用快照的方式，直接读取事务启动时刻t100这一时刻该记录的状态。接下来，有事务2也需要读取用户ID为801这条记录的状态，因为事务2是在t103时刻启动的，所以它直接读取这个时刻该记录的状态。

继续看下去，假设现在需要更改801这条记录的状态，将其标记为“已投递成功”。在提交时，事务会获取当前时间，假设是t110。由于只更改了一条记录，Aurora Limitless Database会利用分片下推的功能，只在该分片内执行更新操作，并将这条记录标记为t110。接下来，它会等待系统的最早时间超过t110，确保所有节点都能看到这条记录的更新，然后再提交事务。

再来看事务3，它在t125时刻启动，读取801记录时，由于t125已经大于t110，因此能够读取到最新的记录状态，这就实现了写后读的一致性。回到事务1，虽然现在是t125时刻，但由于它是以可重复读的隔离级别启动的，因此它会回到自己启动的t100时刻，读取该时刻801记录的状态。

这就是Aurora Limitless Database利用有界时钟和分布式事务实现的工作原理。为了验证其性能，亚马逊进行了一项测试:有三个客户端在一个包含1000亿行的数据表上随机执行更新操作。结果显示，每个客户端的TPS(每秒事务数)大约能达到80万到90万，三个客户端的总TPS可以达到百万级，而延迟只有2-3毫秒。

除了提高扩展性，Aurora Limitless Database还支持PGVector这一PostgreSQL的扩展，可以支持向量数据的存储和查询。由于它的扩展性，因此非常适合用于知识库构建或商品搜索等场景。

接下来，我们来看另一款新产品Aurora Disco，它去年推出Preview版本，最近正式GA。Aurora Disco主要解决了四个问题:第一，提高扩展性，希望数据库能够自动扩展;第二，提高可用性，希望用户访问数据库时能达到更高的可用性，比如99.999%的可用性;第三，减少用户的运维负担，用户无需自行选型、扩容或在打补丁升级时影响应用可用性;第四，让用户能够快速构建应用，并使用熟悉的SQL方式访问数据。

为实现这些目标，Aurora Disco将SQL语句的执行过程分为多个层次，包括查询路由层、查询处理层、仲裁层、事务日志层和存储层，每一层都能独立扩展。它还能够确保无论在什么地方写入一条记录，都能在任何地方读取到该记录的最新状态，这是许多用户所期望的特性。在伸缩时，Aurora Disco能够更好地利用资源，更好地控制成本。

具体来看Aurora Disco的架构，一条查询从上到下执行的过程中，会先到达查询路由层，由它决定该查询应该发送到哪个节点执行。接下来是查询处理层，它会负责执行整个事务，事务的执行过程都在这一层进行。当决定事务最终可以提交时，它会将事务的提交过程发送给仲裁层，由仲裁层判断该事务是否与其他事务存在冲突，如果没有冲突，就可以提交。一旦仲裁层做出提交决定，事务日志层就会将该事务的日志持久化存储。事务日志存储成功后，就会一路返回到查询路由层，最终将执行成功的结果返回给用户。

至于存储层，它会存储不同版本的数据页，并根据事务日志不断重放，维护不同版本的数据信息。如果有读请求到来，就可以直接从存储层获取数据。由于Aurora Disco将功能分解得很细，因此每个模块都能独立扩展。

在可用性方面，Aurora Disco支持单区域和多区域两种模式。在单区域模式下，客户端程序连接的是一个端点，但底层可以有多个节点并行承担写入任务，并且能够实现写入同步。在多区域集群模式下，两个区域的应用可以分别连接各自区域的集群端点进行数据处理，而跨区域的数据同步则由一个Witness Region完成，采用“3写2成功”的机制。

Aurora Disco在无缝化升级方面也做了优化。比如，如果需要对某个模块进行改动，对用户来说是透明的。以查询处理节点为例，如果需要替换一个查询处理节点，直接加入一个新版本的节点，将新查询路由到新节点，旧节点上的负载逐渐减少后就可以将其卸载，在此过程中不会影响用户。

Aurora Disco在性能方面也有独特之处。一般来说，如果每条语句都需要跨区域协调，那么包含10条语句的事务就会变得非常慢。但Aurora Disco只在事务提交时进行一次跨区域同步，这样无论事务包含多少条语句，只需要一轮同步，从而提高了性能。对于读请求，由于每个区域都有最新数据，因此可以直接从本区域读取，无需跨区域访问。

在事务隔离级别上，Aurora Disco目前支持快照隔离级别，这种级别能解决脏读、不可重复读、幻读等问题，同时也能达到较好的性能。另外，Aurora Disco可以根据负载动态添加读副本，实现读能力的扩展。比如，如果某个节点上的读请求较多，就可以为该节点自由添加几个读副本，从而分担读压力。

此外，Aurora Disco还推出了MACP Server，可以集成到Agentic AI应用中，让智能体直接操作Aurora Disco数据库。

回顾一开始提出的对数据库的诉求，Aurora Limitless Database和Aurora Disco都是无服务器架构，用户无需选择机型，升级对用户也是透明的，因此能够实现快速部署。两者都能自动扩容以应对流量增长。Aurora Disco通过强一致性能够确保数据不丢失。两款数据库都支持SQL查询，并且都支持向量数据的存储和查询，因此能够满足查找已有数据的需求。它们都可以与构建Agentic AI应用良好集成，Aurora Disco甚至推出了MACP Server来支持这一点。

最后，根据昨天大会展示的Stress Agent架构，数据库可以在以下几个模块发挥作用:首先，通过MACP Server访问数据库数据，让智能体能够更好、更快、更便捷地访问底层数据。其次，利用PGVector构建知识库，存储向量化的文档信息，以支持知识库查询。再者，利用AriaPG Serverless的PGVector能力，存储用户与AI的交互记忆。最后，像普通应用一样，需要存储应用本身的元数据，如用户信息、会话信息等。

马丽丽女士表示，这只是她最近的一些探索和想法，她希望未来有更多机会探讨数据库在生成式AI时代的作用，共同努力利用数据库的功能更好地构建生成式AI应用程序。

总的来说，这场分享全面阐述了生成式AI应用对数据库的需求，并介绍了亚马逊的两款新数据库Aurora Limitless Database和Aurora Disco如何满足这些需求，同时结合具体的Stress Agent架构案例，为构建生成式AI应用程序提供了数据库层面的支持和思路。Aurora Limitless Database通过有界时钟概念实现分布式事务，将节点间时钟误差控制在50微秒以内，提高可扩展性。测试显示三个客户端可达到百万级TPS，延迟只有2-3毫秒。Aurora Disco则将SQL执行过程分层独立扩展，支持单区域多写节点和两区域“3写2成功”的多区域集群，只在事务提交时进行一次跨区域同步，提高性能。两款数据库都支持快照隔离级别，Aurora Disco还可动态添加读副本扩展读能力。它们都推出了MACP Server，可集成到Agentic AI应用中。通过利用这些新数据库，我们能够更好地构建生成式AI应用程序。

下面是一些演讲现场的精彩瞬间：

总结

在生成式AI时代，构建高效的应用程序对于数据库有着独特的需求。亚马逊云科技推出了两款新的关系型数据库产品:Aurora Limitless Database和Aurora Disco，旨在满足这些需求。

Aurora Limitless Database采用了有界时钟的概念，通过时钟同步实现了高度可扩展的分布式事务处理能力，能够支持百万级TPS和PB级数据量。它还支持向量数据库查询，有助于构建知识库和商品搜索等应用。

Aurora Disco则通过模块化设计实现了自动扩展、高可用性和低运维负担。它支持跨区域数据同步，确保数据不丢失，并提供了与MCP Server的集成，方便构建Agentic AI应用程序。

这两款数据库产品都旨在帮助开发者快速部署、自动扩展、保证数据安全，并提供了与生成式AI应用程序集成的能力，为构建高效的生成式AI应用提供了强有力的支持。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。