首先

请注意，这是关于前文中“ACID特性，CAP定理和BASE”的部分的一些补充说明。
由于这是业余人士随意写下的想法，所以可能包含许多技术不准确或引起误解的描述，请注意。

关于BASE的来源

根据搜寻结果，据称以下资料被认为是BASE的来源。
关于BASE存在以下的权衡被描述。
※ 这可能是关于构建搜索引擎和Web缓存的知识，但由于幻灯片上只有碎片性的信息，所以无法了解详细情况…
朝着强大的分布式系统
https://www.researchgate.net/publication/221343719_Towards_robust_distributed_systems

但为了可用性、优雅降级和性能，我们放弃了”C”和”I”。

可以看出，为了可用性、优雅降级和性能考虑，牺牲了一致性和隔离性。

此外，有关BASE的技术如下所述，尽管“BASE”一词本身并非毫无意义，但实际上它可能更接近于“与ACID进行对比时方便的、易于记忆的谐音”，它是一个涵盖了多种技术的总称，用于确保可用性、性能等必要质量。当然，我认为不存在严格的定义，比如“包含哪些技术算作BASE”。

弱一致性
– 过期的数据可以接受
可用性优先
尽力而为
近似答案可以接受
积极（乐观）
更简单！
更快速
更容易进化

此外，还有以下重要描述，首先ACID和BASE技术并非是互斥选择，而是要根据系统需求进行组合。

但我认为它是一个光谱
真正的互联网系统是酸碱子系统的谨慎混合
– 我们在用户配置文件和日志（用于收入）中使用酸碱。

此外，“Weak Consistency”一词变为“stale data OK”，这意味着它并不完全符合ACID事务中的一致性要求（如唯一约束、CHECK约束、外键等），而是在分布式系统的一致性模型中提供了弱一致性（不保证对副本的原子更新，也不能保证强一致性），主要就是表明了这一点。
※结果来看，Weak Consistency似乎是对ACID一致性要求的放宽…

RDS和Aurora是ACID的还是BASE的？

在单节点的关系数据库中，一开始就要做好在一致性和隔离性上进行妥协的准备。

正如前面所述，BASE的基本理念是“为了改善其他品质特性，而妥协一致性和隔离性”。不过，事实上，在单节点关系型数据库中，为了提高性能，在许多情况下也会妥协一致性和隔离性。

例如，无论是开放源代码软件（OSS）还是商业软件，在主要的RDBMS（Oracle、SQL Server、MySQL、PostgreSQL等）中，为了提高事务的并发性，默认情况下选择的事务隔离级别不是可串行化（serializable），而是读提交（Read Committed）（在MySQL中为可重复读）。请注意，作为一个极端的例子，SQL Server和DB2甚至支持未提交读（Dirty Read）。

例如，在OSS和商业软件中的主要RDBMS（如Oracle、SQL Server、MySQL、PostgreSQL等）中，为了提高事务并发性，transaction isolation level的默认选择是Read Committed（MySQL中是Repeatable Read），而不是Serializable。需要注意的是，作为一个极端的例子，SQL Server和DB2甚至支持未提交读（Dirty Read）。

此外，为了提升复杂查询和视图的性能，常常采用创建并异步更新物化视图的方法（当然，这会带来弱一致性）作为性能改进的技巧。

加入，分组的支持 ≠ ACID事务的支持

如前文所述，“能否执行JOIN和GROUP BY”是与提供的API和查询模型的差异相关的要素，不同于ACID和BASE的独立要素。例如，在RDS和Aurora中，“异步”读取副本（即最终一致性读取）可以执行JOIN和GROUP BY（当然无法获取最新值），而实际上，通过DynamoDB的Athena联合查询，也可以执行包含JOIN、GROUP BY等SQL语句。请注意，“能够执行JOIN、GROUP BY”与“架构是否适合执行这种复杂查询并且是否高效”以及“是否支持类似RDB的快照隔离”是完全不同的方面。

(Translated in simplified Chinese)

快照隔离不是ACID事务。

正如上一篇文章中轻轻提到的，恐怕在本文的上下文中，所谓“一致性”指的是“在执行搜索查询时，数据库通过LSN / SCN显示为一致的快照隔离支持”。然而，尽管这个处理需要是“在某一点上整个数据库都是一致的数据”，但不一定需要是反映最新数据的强一致性读取，快照隔离也可以在读取副本上实现。

目前，在DynamoDB中，要跨多个分区和项目获取一致性数据，目前只能通过执行TransactGetItems来实现。由于以下限制，可以说基于“数据库整体一致性数据”的复杂分析查询更适合关系型数据库。

• 2022年5月時点で最大25アイテムまでしか参照できないこと

• 必ず主キーで検索する必要があること

Join, Group By等がAPIとしてサポートされていないこと

然而，如前所述，“只需要查看特定时间点的快照数据”意味着可以放宽对一致性和隔离性的要求，这与ACID和BASE的比较是不同的元素。

Aurora和RDS必须利用“异步”读取副本。

在Aurora和RDS中，Writer只有一个，为了扩展处理性能，需要利用”异步”读取副本。因此，在Aurora和RDS中，采用BASE范式的技术来缓解一致性问题似乎是大规模Web系统中几乎必需的技术。

另一方面，关于写入操作，它在单一节点上执行，通过牺牲可用性和可扩展性来支持ACID事务。因此，可以看出处理中包含了ACID和BASE这两个要素，具体取决于处理的内容。

总结

上述的方法在关系数据库中也是一种常见的提高性能的手段，即通过减轻一致性和隔离性。此外，关于连接、分组和快照隔离，虽然在关系数据库中更擅长处理，但实际上也可以在基于BASE范式的环境下实施，并不一定需要始终以强一致性和强隔离性进行执行。

DynamoDB是ACID还是BASE？

接下来，我们将讨论DynamoDB是ACID还是BASE。

原始Dynamo（2007年）和DynamoDB（2012年）之间的差异。

首先作为前提条件，需要注意的是，虽然《Dynamo》论文于2007年发布，而《DynamoDB》于2012年发布，二者之间存在相关性，但它们却是“不同的产品”，并且在架构上存在差异。

通过结合原始Dynamo和SimpleDB受到好评的特点，发展出了DynamoDB。我们来看一下原始Dynamo的特性。亚马逊的DynamoDB是一种专为互联网规模应用设计的快速、可扩展的NoSQL数据库服务。
参考链接：https://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html

根据《Dynamo Paper》中对原始Dynamo的描述，可以看出原始Dynamo是为了amazon.com的购物车使用而设计的，它更注重于“始终能够读写”的特点，而非强一致性。

因此，负责管理购物车的服务需要能够始终对其数据存储进行读写操作，并且它的数据需要在多个数据中心之间可用。

通过采用Multi-Master（无主机）架构，同时对多个节点进行写入特定的项目，可以通过添加Sloppy Quorum、Vector clock或在客户端进行读取时进行处理来提高可用性，并为临时服务器故障做好准备。

高可用性的写操作
使用向量时钟在读操作中进行调和
处理临时故障
松散一致性和提示转交

由于在多个节点上同时进行写入操作，并且存在数据不一致的可能性，因此为了解决这个问题，我们需要进行同步操作。
※ 这与BASE中的软状态和最终一致性特性相对应。

从永久性失效中恢复
使用默克尔树进行反熵处理

请参考以下中文翻译：

如上所述，与简单的Quorum Read/Write相关的问题存在一个根本性的难题，即“在节点之间无法达成共识形成的值不存在”，因此无法确保Single key的线性可用性，即使进行了各种设计也无济于事。此外，由于缺乏回滚操作，我们还了解到为了提高性能，减少查询节点的数量会带来Dirty Read的风险。

在2012年推出的DynamoDB中，这一部分已经得到改进。在分区内进行Leader选举，并通过Leader进行写入操作。在分区内，经过同意的节点作为Leader，一定会保存最新的结果，确保在Single key模式下的线性一致性。

从上面的视频中可以看出，被称为”Eventual Consistency Read”操作实际上在实际中是”以2/3的概率获取到最新的数据”，并且不一致的数据只是”简单地过时了”，是在之前由Leader提交的值，不存在像之前提到的”Quorum Read”那样的脏读风险。

※由于共识协议的复杂性，我无法完全了解是否真的没有边缘情况，但如果考虑实施，那将是非常困难的…

根据上述结构，在DynamoDB中可能会失去了原始Dynamo的“写入高可用性”特性，即使部分服务器宕机时仍可以执行写入操作，但根据下文所述的文章，领导者选举具有许多优点，因此可能已经进行了这种结构上的更改。

此外、「Amazon DynamoDB – 一种专为互联网规模应用设计的快速可扩展的NoSQL数据库服务」中还存在以下描述，并强调了不强制特定的一致性模型。
※这段描述并非关于前述的ACID，BASE范式的比较，而是专注于分布式系统中的一致性模型，老实说我觉得这更加容易理解。

灵活。Amazon DynamoDB是一个非常灵活的系统，不强制用户采用特定的数据模型或一致性模型。DynamoDB表没有固定的模式，而是允许每个数据项拥有任意数量的属性，包括多值属性。开发人员在访问数据库时可以选择使用更强的一致性模型，以简化模型为代价牺牲一些性能和可用性。他们还可以利用DynamoDB的原子自增/自减功能来实现计数器。

总结

根据以上内容，在DynamoDB中，性能和可用性都很重要。虽然该产品支持基于BASE范式的最终一致性读取，但目前的DynamoDB支持线性一致性，并且没有强制实施特定的一致性模型。

此外，正如上篇文章所述，DynamoDB还支持跨多个节点/项的ACID事务。尽管与关系数据库具有数据模型和API上的差异，但DynamoDB既包含ACID范式的要素，也包含BASE范式的要素，因此需要根据应用程序的要求进行选择。

那么，如果不使用CAP，ACID和BASE这些术语，我们应该如何解释它们的区别呢？

仅仅解释数据模型和支持的API各自擅长的处理方式的差异就足够了。正如我们一直强调的那样，ACID和BASE并不是互斥选择的特性，所以将关系型数据库说成是ACID，而DynamoDB说成是BASE，这是明显错误的说法，并且很容易导致混淆和误解。