为什么 C-Store 中的 Tuple Mover 只考虑比 LWM 早的行？

Question

在 Michael Stonebraker 的 C-Store 论文（链接：http : //db.csail.mit.edu/projects/cstore/vldb.pdf）的 Tuple Mover 部分中，描述了以下内容：

MOP（合并出过程）将查找所选 WS 段中的所有记录，其插入时间在 LWM 或之前（低水位标记；时间戳顺序/纪元值）[...] 中记录的最近插入时间RS' 成为该段的新 t_lastmove 并且始终小于或等于 LWM。[...] 因此，LWM“追逐”HWM（高水位线），并选择它们之间的增量来在需要历史访问权限的用户需求和 WS 空间限制之间进行调解。

我不明白，当将记录从 WS（写优化存储）移动到 RS（读优化存储）时，为什么元组移动器只考虑比 LWM 早的记录？这不是意味着在 LWM 之后插入系统的所有行都只会在 WS 中吗？在 LWM 较小的系统中，即在支持旧历史查询的系统中，这可能意味着大部分记录将仅在 WS 中，我们将错过读取优化存储提供的所有优化。

我错过了什么吗？

Answer 1

鉴于引用的论文已有10 年的历史，我建议您查看 Vertica 分析数据库：7 年后的 C-Store，因为 Vertica 具有更多的自动纪元推进机制。

作为参考，现在使用的缩写词是：

• WOS - 写优化存储
• ROS - 读取优化存储
• AHM - 古代历史标记（低水位标记）
• LGE - 最后的好时代

快速概述 epoch 在 Vertica 中的工作方式：

我不明白，当将记录从 WS（写优化存储）移动到 RS（读优化存储）时，为什么元组移动器只考虑比 LWM 早的记录？

Vertica 将作为后台进程自动推进 epoch。在下面的例子中，一旦数据被提交，它将属于当前纪元。

-- Get the current epoch
dbadmin=> SELECT CURRENT_EPOCH FROM system;
 CURRENT_EPOCH
---------------
           238
(1 row)

-- Insert a row into the table without committing (WOS)
dbadmin=> INSERT INTO tbl (a) VALUES (1);
 OUTPUT
--------
      1
(1 row)

-- Get the epoch for the row
dbadmin=> SELECT a, epoch FROM tbl;
 a | epoch
---+-------
 1 |
(1 row)

-- Commit the insert
dbadmin=> COMMIT;
COMMIT

-- Get the epoch for the row
dbadmin=> SELECT a, epoch FROM tbl;
 a | epoch
---+-------
 1 |   238
(1 row)

这不是意味着在 LWM 之后插入系统的所有行都只会在 WS 中吗？

它不是。WOS 只是一个临时存储位置，直到数据移动到 ROS。时代只是一种管理交易的方式。