File tree Expand file tree Collapse file tree 1 file changed +2
-2
lines changed Expand file tree Collapse file tree 1 file changed +2
-2
lines changed Original file line number Diff line number Diff line change @@ -605,7 +605,7 @@ COMMIT;
605
605
606
606
两个进展引发了这个反思:
607
607
608
- - RAM 足够便宜了,许多场景现在都可以将完整的活跃数据集保存在内存中。 (请参阅 “[ 在内存中存储一切] ( ch3.md#在内存中存储一切 ) ”)。当事务需要访问的所有数据都在内存中时,事务处理的执行速度要比等待数据从磁盘加载时快得多。
608
+ - RAM 足够便宜了,许多场景现在都可以将完整的活跃数据集保存在内存中(请参阅 “[ 在内存中存储一切] ( ch3.md#在内存中存储一切 ) ”)。当事务需要访问的所有数据都在内存中时,事务处理的执行速度要比等待数据从磁盘加载时快得多。
609
609
- 数据库设计人员意识到 OLTP 事务通常很短,而且只进行少量的读写操作(请参阅 “[ 事务处理还是分析?] ( ch3.md#事务处理还是分析? ) ”)。相比之下,长时间运行的分析查询通常是只读的,因此它们可以在串行执行循环之外的一致快照(使用快照隔离)上运行。
610
610
611
611
串行执行事务的方法在 VoltDB/H-Store,Redis 和 Datomic 中实现【46,47,48】。设计用于单线程执行的系统有时可以比支持并发的系统性能更好,因为它可以避免锁的协调开销。但是其吞吐量仅限于单个 CPU 核的吞吐量。为了充分利用单一线程,需要与传统形式的事务不同的结构。
@@ -657,7 +657,7 @@ VoltDB 还使用存储过程进行复制:但不是将事务的写入结果从
657
657
在特定约束条件下,真的串行执行事务,已经成为一种实现可串行化隔离等级的可行办法。
658
658
659
659
- 每个事务都必须小而快,只要有一个缓慢的事务,就会拖慢所有事务处理。
660
- - 仅限于活跃数据集可以放入内存的情况。很少访问的数据可能会被移动到磁盘,但如果需要在单线程执行的事务中访问 ,系统就会变得非常慢 [ ^ x ] 。
660
+ - 仅限于活跃数据集可以放入内存的情况。很少访问的数据可能会被移动到磁盘,但如果需要在单线程执行的事务中访问这些磁盘中的数据 ,系统就会变得非常慢 [ ^ x ] 。
661
661
- 写入吞吐量必须低到能在单个 CPU 核上处理,如若不然,事务需要能划分至单个分区,且不需要跨分区协调。
662
662
- 跨分区事务是可能的,但是它们能被使用的程度有很大的限制。
663
663
You can’t perform that action at this time.
0 commit comments