ACID 和 BASE 数据库有什么区别？
ACID 和 BASE 是数据库事务模型，确定数据库组织和操作数据的方式。在数据库上下文中，事务是数据库视为单个工作单元的任何操作。事务必须完全完成，数据库才能保持一致。例如，当您将资金从一个银行账户转到另一个银行账户时，这笔钱必须离开您的账户，并且必须添加到第三方账户。如果这两个步骤没有完成，就不能称为事务完成。
ACID 数据库优先考虑一致性而不是可用性，如果事务中的任何步骤出现错误，整个事务都会失败。相比之下，BASE 数据库优先考虑可用性而不是一致性。用户可以暂时访问不一致的数据，而不是让事务失败。数据一致性可以实现，但不能立即实现。
为什么 ACID 和 BASE 很重要？
现代数据库采用分布式数据存储，可在通过网络连接的多个节点上复制数据。它们允许用户在单个事务中执行多种数据操作，例如读取和写入。用户希望在事务结束时确保所有节点的数据一致。但是，在理论计算机科学中，布鲁尔定理（也称为 CAP 定理）指出，任何分布式数据存储只能提供以下三种保证中的两种：
- 一致性：每个读取操作都会收到最近更新的数据或错误。
- 可用性：每个数据库请求都会收到成功的响应，但不保证其中包含最新更新的数据。
- 分区容错性：尽管分布式节点间出现消息丢失或延迟，但系统仍能继续运行。
例如，如果客户在电子商务网站上将商品添加到购物车中，则所有其他客户都应当看到该产品的库存水平下降。如果客户将最后一件商品添加到购物车中，则所有其他用户都应看到该商品缺货。如果事务中的任何操作失败，数据库设计人员必须做出选择。数据库可以执行以下操作之一：
- 取消事务并返回错误，降低可用性但确保一致性。客户无法将商品添加到购物车，或者其他客户无法加载所有产品的详细信息，直到添加到购物车成功。
- 继续操作，提供可用性，但有不一致的风险。客户将商品添加到购物车，但其他客户看到的库存水平不正确，至少暂时不正确。
在某些使用案例中，一致性至关重要，ACID 数据库因此备受青睐。但是，在其他使用案例中，一致性并不重要。例如，当您在社交媒体上接受好友请求时，其他用户在您的社交媒体个人资料上看到的好友数量是否有误并不重要。但是，您不希望在对数据进行排序时失去对社交媒体动态的访问权限。在这种情况下，BASE 便至关重要。
关键原则：ACID 和 BASE
ACID 和 BASE 是不同数据库属性的首字母缩写，表示数据库在联机事务处理时的行为。
ACID
ACID 代表原子性、一致性、隔离性和耐久性。
原子性
原子性可确保单个数据库事务中的所有步骤都已全部完成或恢复到其初始状态。例如，在预订系统中，预订座位和更新客户详细信息这两项任务都必须在一次事务中完成。如果客户资料不完整，则无法预留座位。如果事务的任何部分失败，便不会对数据进行任何更改。
一致性
一致性可确保数据符合预定义的完整性限制和业务规则。即使多个用户同时执行相似操作，所有用户的数据也会保持一致。例如，一致性可确保在将资金从一个账户转账到另一个账户时，事务前后的总余额保持不变。如果账户 A 有 200 美元，账户 B 有 400 美元，则总余额为 600 美元。A 向 B 转账 100 美元后，A 还剩 100 美元，B 有 500 美元。总余额仍为 600 美元。
隔离性
隔离性可确保访问特定记录的新事务要等到前一个事务完成后才能开始操作。它可确保并发事务不会相互干扰，从而造成它们串行执行事务的错觉。再举一个例子，一个多用户库存管理系统。如果一位用户更新了产品的数量，则访问相同产品信息的另一位用户将看到数据的一致隔离视图，而且在提交更新之前，视图不会受到持续更新的影响。
耐久性
耐久性可确保即使系统出现故障，数据库也能保留所有已提交的记录。它可保证在提交 ACID 事务时，所有更改都是永久性的，不会受到后续系统故障的影响。例如，在通信应用程序中，当用户发送消息并收到成功传送的确认消息时，耐久性属性可确保消息永不丢失。即使应用程序或服务器故障，情况也仍然如此。
BASE
BASE 代表基本可用、软状态，以及最终保持一致。首字母缩写强调 BASE 与 ACID 相反，与其代表的化学物质一样。
基本可用
基本可用是指用户可随时对数据库进行并发访问。用户无需等待其他用户完成事务即可更新记录。例如，电子商务平台的流量突然激增时，系统可能会优先提供产品列表和接受订单。即使更新库存数量稍有延迟，用户仍能继续进行商品结账。
软状态
软状态是指即使没有外部触发器或输入，数据也可以具有随时间变化的瞬态或临时状态的概念。它描述了多个应用程序同时更新记录时的过渡状态。只有在所有事务完成后，才会最终确定记录的值。例如，如果用户编辑社交媒体帖文，则其他用户可能无法立即看到该更改。但是，之后，即使没有用户触发该帖文，但该帖文还是会自行更新（反映之前的更改）。
最终一致性
最终一致性意味着所有并发更新都完成后，记录将实现一致性。此时，查询记录的应用程序将看到相同的值。例如，假设有一个分布式文档编辑系统，其中多个用户可以同时编辑一个文档。如果用户 A 和用户 B 同时编辑文档的同一部分，则在更改传播和同步前，他们的本地副本可能会暂时有所不同。但是，随着时间推移，系统会通过传播和合并不同用户所做的更改来确保最终的一致性。
主要区别：ACID 与 BASE
在 ACID 和 BASE 数据库事务模型间进行选择时，需要权衡取舍。
扩展
扩展 ACID 数据库事务模型比较困难，因为它侧重于一致性。任何时候任何记录都只允许进行一次事务，使得横向扩展更加困难。
或者，您可以横向扩展 BASE 数据库模型，因为它不需要确保严格的一致性。在数据库集群中添加多个节点可以提高 BASE 模型的数据可用性，这是驱动数据库架构的原则。
灵活性
ACID 数据库在处理数据时不太灵活。它必须确保即时一致性，如果遇到断网或断电，ACID 数据库可能会限制对某些应用程序的访问。同样，如果其他软件模块正在处理特定记录，则应用程序必须等待，直至轮到其更新数据。相反，BASE 数据库则更加灵活。BASE 没有施加严格的限制，而是允许应用程序在记录可用时进行修改。
性能
ACID 数据库在处理大量数据或并发处理请求时可能会遇到性能问题。由于数据是按照严格顺序处理的，因此每次事务的开销都会造成延迟，从而影响所有访问记录的应用程序。
相比之下，访问 BASE 数据库的应用程序则可以随时处理记录。这减少了过多的等待时间并提高了数据库吞吐量。
同步
ACID 数据库需要同步机制来提交来自事务的更改并反映在所有关联记录中。同时，它必须锁定来自其他方的特定记录，直至事务完成或放弃。同时，BASE 数据库运行时不锁定记录，最终在不提供时间保证的条件下同步记录。在使用 BASE 数据库时，开发人员知道在处理某些记录时可能会出现不一致之处，因此在应用程序中采取了必要的预防措施。
使用时机：ACID 与 BASE
尽管存在差异，但 ACID 和 BASE 数据库系统在不同应用程序中都很重要。ACID 是需要数据一致性、可靠性和可预测性的企业应用程序的理想选择。例如，银行使用 ACID 数据库来存储客户事务，因为数据完整性是重中之重。与此同时，要对结构化程度较低、量大的数据进行在线分析处理，BASE 数据库则是更好的选择。例如，电子商务网站使用 BASE 数据库来更新产品价格，这些价格变化非常频繁。在这种情况下，定价准确性不如允许所有客户实时访问产品价格重要。
数据库可以同时符合 ACID 和 BASE 吗？
根据 CAP 定理，数据库可以满足一致性、可用性和分区容错性这三种保证中的两个。ACID 和 BASE 数据库模型都可以提供分区容错性，这意味着它们不可能既高度一致又始终可用。因此，数据库要么倾向于 ACID 要么倾向于 BASE，无法兼而有之。例如，SQL 数据库是基于 ACID 模型构建的，而 NoSQL 数据库则使用 BASE 架构。然而，一些 NoSQL 数据库虽然可能会表现出某些 ACID 特征，但却不能作为兼容 ACID 的数据库运行。
差异摘要：ACID 与 BASE 的比较
| ACID |
BASE |
|
| 规模 |
垂直扩展。 |
水平扩展。 |
| 灵活性 |
不够灵活。处理时阻止来自其他应用程序的特定记录。 |
更灵活。允许多个应用程序同时更新同一条记录。 |
| 性能 |
处理大量数据时，性能会降低。 |
能够处理具有高吞吐量的大型非结构化数据。 |
| 同步 |
可以。同步时会增加延迟。 |
数据库级别无同步。 |
AWS 如何满足您的 ACID 和 BASE 数据库要求？
AWS Cloud 数据库为每种类型的数据使用案例提供了一系列 ACID 和 BASE 数据库服务。组织在 AWS 上部署数据库可以节省预置、扩展和管理数据存储基础设施的时间。例如：
- Amazon DynamoDB 是一项快速 BASE 数据库服务，支持对云应用程序进行毫秒级数据处理。
- 适用于 Redis 的 Amazon MemoryDB 是另一个 BASE 数据库，允许开发人员为 Web 和移动应用程序部署耐用且高度可用的 Redis 数据库。
- AWS RedShift 是一个 ACID 云数据仓库，允许您为商务智能使用案例运行复杂的 SQL 分析查询。
立即创建账户，开始使用 ACID 和 BASE 数据库。
