Merge pull request #300 from FangYuan33/patch-2

补充谓语
This commit is contained in:
YIN, Gang 2023-03-25 22:09:18 +08:00 committed by GitHub
commit 6e615430f7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

2
ch7.md
View File

@ -608,7 +608,7 @@ COMMIT;
- RAM 足够便宜了,许多场景现在都可以将完整的活跃数据集保存在内存中(请参阅 “[在内存中存储一切](ch3.md#在内存中存储一切)”)。当事务需要访问的所有数据都在内存中时,事务处理的执行速度要比等待数据从磁盘加载时快得多。 - RAM 足够便宜了,许多场景现在都可以将完整的活跃数据集保存在内存中(请参阅 “[在内存中存储一切](ch3.md#在内存中存储一切)”)。当事务需要访问的所有数据都在内存中时,事务处理的执行速度要比等待数据从磁盘加载时快得多。
- 数据库设计人员意识到 OLTP 事务通常很短,而且只进行少量的读写操作(请参阅 “[事务处理还是分析?](ch3.md#事务处理还是分析?)”)。相比之下,长时间运行的分析查询通常是只读的,因此它们可以在串行执行循环之外的一致快照(使用快照隔离)上运行。 - 数据库设计人员意识到 OLTP 事务通常很短,而且只进行少量的读写操作(请参阅 “[事务处理还是分析?](ch3.md#事务处理还是分析?)”)。相比之下,长时间运行的分析查询通常是只读的,因此它们可以在串行执行循环之外的一致快照(使用快照隔离)上运行。
串行执行事务的方法在 VoltDB/H-StoreRedis 和 Datomic 中实现【46,47,48】。设计用于单线程执行的系统有时可以比支持并发的系统性能更好因为它可以避免锁的协调开销。但是其吞吐量仅限于单个 CPU 核的吞吐量。为了充分利用单一线程,需要与传统形式的事务不同的结构。 串行执行事务的方法在 VoltDB/H-StoreRedis 和 Datomic 中实现【46,47,48】。设计用于单线程执行的系统有时可以比支持并发的系统性能更好因为它可以避免锁的协调开销。但是其吞吐量仅限于单个 CPU 核的吞吐量。为了充分利用单一线程,需要与传统形式的事务不同的结构。
#### 在存储过程中封装事务 #### 在存储过程中封装事务