2023-09-22 monetdb-事务管理-乐观并发控制-记录

摘要:

2023-09-22 monetdb-事务管理-记录

相关文档:

Transaction Management | MonetDB Docs

https://en.wikipedia.org/wiki/Optimistic_concurrency_control

monetdb事务管理:

MonetDB/SQL 支持以 START TRANSACTION 标记并以 COMMIT 或 ROLLBACK 关闭的多语句事务方案。如果每个 SQL 语句应被视为独立事务，则可以将会话变量 AUTOCOMMIT 设置为 true（默认）。

在AUTOCOMMIT模式下，可以使用START TRANSACTION和COMMIT/ROLLBACK来指示包含多个SQL语句的事务。在这种情况下，AUTOCOMMIT 由 START TRANSACTION 自动禁用，并由 COMMIT 或 ROLLBACK 重新启用。

如果 AUTOCOMMIT 模式为 OFF，则 START TRANSACTION 是隐式的，您应该只使用 COMMIT/ROLLBACK。

警告：事务管理方案基于乐观并发控制。它为每个事务提供了数据库的一致视图，但更新被收集在事务提交时处理的附录中。如果在提交时可以确保准备更新影响表的数据同时没有更改，则结果将被合并。否则交易将中止。这种乐观并发方案对于查询主导环境特别有用。它会对长时间运行的事务产生负面影响，这些事务同时受到其基础表更新的影响。对于尝试从单个应用程序中的多个线程执行并发更新的应用程序也是如此。它们应该由应用程序在内部序列化，以避免意外的事务中止。

乐观并发控制可能会让那些构建在线事务应用程序的人感到困惑，因为并发控制方案的粒度将显示比预期更高的事务失败。没有锁定模式可以避免这种情况。应用程序可能必须诉诸串行执行。

被删除的元组仅被标记为这样。它们不会减小表的大小。您甚至会在多次更新后遇到查询运行速度变慢的情况，因为每个查询首先必须通过检查删除/更新列表在数据库上建立一致的私有视图。它需要在后台使用真空清洁算法，但目前尚不可用。

使用可选的事务模式或隔离级别启动事务和本地事务（关闭自动提交）。

SET TRANSACTION
| SET_LOCAL_TRANSACTION
  [ READ ONLY | READ WRITE | ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE } |
  DIAGNOSTICS _sqlSize_ ]

使用可选的事务模式或隔离级别启动本地事务（关闭自动提交）

 | { START | BEGIN } TRANSACTION
   [ READ ONLY | READ WRITE | ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE } | DIAGNOSTICS _sqlSize_ ]

禁用自动提交并启动用户控制的事务

注意：事务还可以包含数据定义 (DDL) 命令，例如 CREATE、ALTER、DROP。

 | COMMIT [ WORK ] [ AND [ NO ] CHAIN ]
 | ROLLBACK [ WORK ] [ AND [ NO ] CHAIN ]
 | SAVEPOINT savepoint_id_name
 | ROLLBACK [ WORK ] [ AND [ NO ] CHAIN ] TO SAVEPOINT savepoint_id_name
 | RELEASE SAVEPOINT savepoint_id_name

您需要先启动一个事务，然后才能使用保存点 使自事务启动以来完成的所有更改持久化

例子

SET TRANSACTION;
ROLLBACK;
SET TRANSACTION READ ONLY;
ROLLBACK;
SET TRANSACTION READ WRITE;
ROLLBACK;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
ROLLBACK;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
ROLLBACK;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
ROLLBACK;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
ROLLBACK;

乐观并发控制

乐观并发控制（OCC）也称为乐观锁定，是一种应用于关系数据库管理系统、软件事务内存等事务系统的并发控制方法。OCC 假设多个交易可以频繁完成而不会相互干扰。运行时，事务使用数据资源而不获取这些资源的锁。在提交之前，每个事务都会验证没有其他事务修改了它所读取的数据。如果检查发现冲突的修改，则提交事务将回滚并可以重新启动。[1]乐观并发控制由HT Kung和 John T. Robinson于 1979 年首次提出。[2]

OCC 一般用于数据争用较少的环境。当冲突很少时，事务可以完成，而无需管理锁的费用，也无需事务等待其他事务的锁清除，从而比其他并发控制方法具有更高的吞吐量。然而，如果数据资源的争用频繁，则重复重新启动事务的成本会显着损害性能，在这种情况下，其他并发控制方法可能更适合。然而，基于锁定（“悲观”）的方法也会带来较差的性能，因为即使避免了死锁，锁定也会极大地限制有效并发性。

乐观并发控制的阶段[编辑]

乐观并发控制事务涉及以下阶段：[2]

• Begin：记录标记事务开始的时间戳。
• 修改：读取数据库值，并暂时写入更改。
• Validate：检查其他事务是否修改了本事务已使用（读或写）的数据。这包括在此事务开始时间之后完成的事务，以及（可选）在验证时仍处于活动状态的事务。
• Commit/Rollback：如果没有冲突，则使所有更改生效。如果存在冲突，通常通过中止事务来解决它，尽管其他解决方案也是可能的。必须小心避免检查时间到使用时间错误，特别是如果此阶段和前一阶段不是作为单个原子操作执行的。

例子[编辑]

• MediaWiki的编辑页面使用 OCC。[4]
• Bugzilla使用 OCC；编辑冲突称为“空中冲突”。[5]
• Ruby on Rails框架有一个用于 OCC 的 API。[6]
• Grails框架在其默认约定中使用 OCC 。[7]
• GT.M数据库引擎使用 OCC 来管理事务[8]（甚至单个更新也被视为小型事务）。
• Microsoft的实体框架（包括 Code-First）内置了对基于二进制时间戳值的 OCC 的支持。[9]
• Mimer SQL是一种仅实现乐观并发控制的DBMS 。[10]
• Google App Engine数据存储使用 OCC。[11]
• Apache Solr搜索引擎通过 _version_ 字段支持 OCC。[12]
• Elasticsearch搜索引擎通过版本属性支持 OCC 。[13]
• CouchDB通过文档修订的方式实现OCC。[14]
• MonetDB面向列的数据库管理系统的事务管理 方案是基于OCC的。[15]
• 大多数软件事务内存的实现都使用 OCC。[需要引用]
• Redis通过WATCH命令提供OCC。[16]
• Firebird使用多代架构作为 OCC 的数据管理实现。[需要引用]
• DynamoDB使用条件更新作为 OCC 的实现。[17]
• Kubernetes在更新资源时使用 OCC。[18]
• YugabyteDB是一个主要使用OCC的云原生数据库。[19]
• Firestore是Firebase的 NoSQL 数据库，在其事务中使用 OCC。