📜  数据库的 ACID 模型与 BASE 模型

📅  最后修改于: 2022-05-13 01:57:01.813000             🧑  作者: Mango

数据库的 ACID 模型与 BASE 模型

ACID 和 BASE 数据库模型之间的区别在于它们处理此限制的方式。

  1. ACID 模型提供了一个一致的系统。
  2. BASE 模型提供高可用性。

为了提供进一步的见解,我们将分别详细讨论每个模型。

酸型号:

形成单个逻辑工作单元的操作集合称为事务,数据库系统必须确保事务的正确执行,而 ACID 数据库事务模型确保执行的事务始终是一致的。更详细、更简单地解释 ACID 是通过分解首字母缩写词 ACID 来理解:

  1. 原子性:该属性状态事务必须被视为一个原子单元,即,要么执行所有操作,要么不执行任何操作,并且数据库中必须没有状态,其中事务部分完成,状态也应定义交易执行前或交易执行后。
  2. 一致性:在任何事务之后数据库必须保持一致状态,任何事务都不应对数据库中的数据产生任何不利影响,如果数据库在事务执行之前处于一致状态,那么它必须在事务执行后保持一致交易的执行也是如此。
  3. 隔离:在同时并行执行多个事务的数据库系统中,隔离的属性表明每个事务都将被管理和执行,因为它是系统中唯一的事务,也没有事务将影响任何其他交易的存在。
  4. 持久性:即使系统失败或重新启动,数据库也应该足够持久以保存其所有最新更新修改后的数据,但如果未执行提交,则不会修改任何数据,并且只能在系统启动时进行。

符合 ACID 的数据库是确保您的数据库符合 ACID 的一种安全方法是选择关系数据库管理系统,如 MySQL、PostgreSQL、Oracle、SQLite 和 Microsoft SQL Server。一些 NoSQL DBMS,如 Apache 的 Couch DB 或 IBM 的 Db2,也具有一定程度的 ACID 合规性(如果要求严格的 ACID 规则,不建议使用 No SQL 数据库)。

基本型号:

NoSQL 数据库的普及为数据操作提供了灵活和流动性,因此,设计了一种新的数据库模型,以反映这些属性。首字母缩略词 BASE 比 ACID 更令人困惑,但是,它背后的词语暗示了 BASE 模型不同的方式,首字母缩略词 BASE 代表:-

  1. 基本可用: BASE 建模的 NoSQL 数据库不会强制要求立即保持一致性,而是通过在数据库集群的节点之间传播和复制数据来确保数据的可用性。
  2. 软状态:由于缺乏即时一致性,数据值可能会随时间变化。 BASE 模型脱离了数据库的概念,该数据库具有自身的一致性,将责任委托给开发人员。
  3. 最终一致:BASE 不强制要求立即一致,但这并不意味着它永远不会实现它。但是,在此之前,数据读取仍然是可能的(即使它们可能无法反映现实)。

就像 SQL 数据库几乎一致地兼容 ACID 一样,一些 NoSQL 数据库也倾向于遵循 BASE 原则,例如 MongoDB、Cassandra 和 Redis 是最受欢迎的 NoSQL 解决方案,还有 Amazon DynamoDB 和 Couchbase。

ACID和BASE的区别:

S. No

Criteria

ACID

BASE

1.

Simplicity

Simple

Complex

2.

Focus

Commits

Best attempt

3.

Maintenance

High

Low

4.

Consistency Of Data

Strong

Weak/Loose

5.

Concurrency scheme

Nested Transactions

Close to answer

6.

Scaling

Vertical

Horizontal

7.

Implementation

Easy to implement

Difficult to implement

8.

Upgrade

Harder to upgrade

Easy to upgrade

9.

Type of database

Robust

Simple

10.

Type of code

Simple

Harder

11.

Time required for completion

Less time

More time.

12.

Examples

Oracle, MySQL, SQL Server, etc.

DynamoDB, Cassandra, CouchDB, SimpleDB etc.

哪个型号更好?

没有正确的答案,也永远不会是判断您的应用程序是否需要完整的仅 ACID 或 BASE 一致性模型的答案。开发人员和数据架构师应该通过逐案选择来选择他们的数据一致性,而不是基于市场趋势,这样可以很花哨地吹嘘或以前使用过什么模型,这样更多的同样的发展可能会变得更加复杂。

鉴于 BASE 松散的一致性,开发人员应该:

  1. 非常了解一致的数据。
  2. 小心一致的数据。

熟悉您选择的聚合存储的基本行为并仅在这些约束内工作以保持一致的数据非常重要。 ACID 事务的简单性在相互比较时总是对 BASE 不利。完整的 ACID 模型数据库非常适合数据可靠性和一致性是最优先考虑的用例,例如银行、PayPal。