第8章：评测方法论与 benchmarks —— DM 事务怎么 benchmark

DM 事务领域 12 年的论文积累了大量实验数据，但跨论文对比起来非常困难——硬件不同、benchmark 配置不同、metric 不同、统计严谨度不同。本章把 DM 事务的评测方法论系统梳理：常用 benchmark 的来龙去脉与适配、metric 选择、sensitivity 实验设计、可复现性约定、跨硬件对比方法。读完你应该能拿到一份”看 paper §6（实验章节）“的 checklist——能看出哪些数字可信、哪些数字有水分、哪些对比不公平。

📑 目录

• 1. 4 大 benchmark 全景
• 2. TPC-C：DM 论文的事实标准
• 3. SmallBank / TATP：简单 OLTP 对照
• 4. YCSB：通用 KV
• 5. 自制 microbench：测单点能力
• 6. Metrics：throughput / latency / abort / IOPS
• 7. Sensitivity 实验：CN/MN 数 / threads / coroutines
• 8. 跨论文对比的 8 个不公平
• 9. 可复现性约定与 USENIX AE
• 自我检验清单
• 参考资料

---

1. 4 大 benchmark 全景

DM 事务领域的论文几乎都在这 4 个 benchmark 上报数：

Benchmark	性质	复杂度	DM 论文使用率
TPC-C	OLTP 标准（写多）	高（5 类事务，9 张表）	~95%
SmallBank	简单 OLTP	低（5 类事务，2 张表）	~60%
TATP	电信场景（读多）	中	~40%
YCSB	通用 KV	极低（GET/PUT/SCAN）	~50%

🌟 关键事实：TPC-C 是 DM 事务的”事实标准”——任何不报 TPC-C 的论文会被审稿人质疑。

---

2. TPC-C：DM 论文的事实标准

2.1 TPC-C 历史与定位

TPC-C 是 1992 年制定的 OLTP 标准 benchmark，模拟一个仓储 + 订单系统：

   TPC-C 模型
   ────────────
   - W 个 warehouse（关键参数）
   - 每个 warehouse 10 个 district
   - 每个 district 30K customer
   - 100K stock items / warehouse
   - 5 类事务：NewOrder, Payment, OrderStatus, Delivery, StockLevel

2.2 5 类事务的特征

事务	比例	特征
NewOrder	45%	最复杂：跨 7 张表，10–15 个 stock
Payment	43%	简单：3 张表
OrderStatus	4%	只读
Delivery	4%	批量删除
StockLevel	4%	只读

🌟 重点：NewOrder 是 TPC-C 的核心——它的写复杂度决定了系统的”事务能力上限”。绝大多数 DM 论文只报 NewOrder + Payment 的吞吐。

2.3 关键参数：warehouse 数

   W=1   完全冲突（所有事务争同一仓库）
   W=10  低冲突
   W=40  CREST/AURA 实验默认（中等冲突）
   W=100+ 几乎无冲突（实验上太"友好"）

🌟 常见做法：W=40 是 DM 事务领域的 sweet spot——既能体现热点冲突，数据量又不至于撑爆 MR。

2.4 TPC-C 在 DM 上的适配

   适配点
   ──────
   1. 数据布局：
      - 单机 TPC-C 用 hash + B+tree
      - DM 用 RACE hash + Sherman B+tree
   
   2. record 大小：
      - 原生 TPC-C 行很大（如 stock 306B）
      - DM 经常 strip 字段（只保留事务用到的）
   
   3. 客户端发请求方式：
      - 单机：本地调用
      - DM：CN 持有 transaction logic，RDMA 取数据

2.5 TPC-C 实测数字（c6525-25g 集群）

系统	TPC-C 吞吐 (W=40, 3 CN)
Single-machine PostgreSQL	~10 KTPS
FORD	~250 KTPS
Motor	~240 KTPS
LOTUS	~280 KTPS
AURA	~290 KTPS

⚠️ 注意：这些数字是不同硬件 / 不同 CN 数下的，直接对比不公平——见 §8。

---

3. SmallBank / TATP：简单 OLTP 对照

3.1 SmallBank

   SmallBank 模型
   ────────────────
   - Saving + Checking 两张表
   - 5 类事务：
     - Balance, DepositChecking, TransactSavings,
     - Amalgamate, WriteCheck
   - 每事务 1-3 records

特点：

• 简单（实现 < 500 lines）
• 写少（~30%）
• 经常作为”理想化负载”基线

3.2 TATP

   TATP 模型
   ────────────
   - 4 张表（Subscriber 等）
   - 7 类事务（80% 读，20% 写）
   - 单事务 1-2 records

特点：

• 读密集
• 用于测”读优化”系统（FaRM 早期主战）

3.3 何时用 SmallBank/TATP

场景	推荐
只想快速跑通系统	SmallBank
测读优化	TATP
主体实验	TPC-C

🌟 建议：主体实验报 TPC-C，附录加 SmallBank/TATP 作为对照。

---

4. YCSB：通用 KV

4.1 YCSB 模型

YCSB（Yahoo Cloud Serving Benchmark）：

• 简单 KV 操作（GET / PUT / SCAN）
• 可配置 read/write ratio
• 6 个 workload pattern（A-F）

4.2 在 DM 论文里的角色

用途	说明
索引性能测试	RACE / Sherman / SMART 主战场
简单事务	多 GET/PUT 组合做事务
不适合复杂事务	NewOrder 类无法表达

4.3 YCSB 不适合 DM 事务的原因

⚠️ 限制：

• YCSB 没有”复杂事务”概念
• 多数 DM 事务系统不报 YCSB
• 报的话通常是为了对比 KV 索引

🌟 结论：YCSB 在 DM 事务领域是次要 benchmark，主要用于 KV 索引论文。

---

5. 自制 microbench：测单点能力

5.1 为什么要自制 microbench

标准 benchmark 是”端到端工作负载”——但研究中经常需要测单点能力：

测什么	自制 microbench
atomic IOPS 上限	ib_atomic_bw + 自己改改
锁争用下的退化	hot key benchmark（所有事务争 1 个 key）
跨节点协调代价	cross-cohort txn microbench
MVCC GC 效率	long tx + GC 触发

5.2 LOTUS / AURA 的 motivation microbench

   AURA motivation 实验
   ──────────────────────
   - 1 MN, N CN
   - 50% 写事务，全部争同一个 record
   - 测 atomic IOPS 在 N=1, 2, 3 下的扩展性
   - 结论：N=3 已经触顶（5.8 Mpps）

5.3 microbench 的工程价值

⭕ 互补：microbench 不能替代标准 benchmark，但可以：

• 隔离单一变量（比如只测 atomic）
• 揭示标准 benchmark 看不到的瓶颈
• 配合做 sensitivity 分析

🌟 建议：主体 = TPC-C，motivation 章节 = microbench，二者互补。

---

6. Metrics：throughput / latency / abort / IOPS

6.1 主要 metric 清单

Metric	含义	单位
Throughput	每秒提交事务数	KTPS / MTPS
Latency p50/p99/p999	单事务延迟分布	µs
Abort rate	提交失败率	%
Atomic IOPS	NIC 实测 atomic 速率	Mpps
CPU utilization	CN/MN CPU 占用	%
Network bandwidth	RDMA 吞吐	Gb/s

6.2 哪些 metric 是必报

   主体实验必报
   ──────────────
   - Throughput（核心 claim）
   - Abort rate（说明协议有效性）
   - Latency p99（SLO 指标）
   
   补充实验
   ──────────────
   - Atomic IOPS（motivation 章节）
   - CPU/network utilization（reasoning 章节）

6.3 哪些 metric 容易作弊

⚠️ 常见水分：

metric	水分点
Throughput	没说 abort 比例（高 abort 也能高吞吐）
Average latency	隐藏 tail latency（用 p99 / p999）
Atomic IOPS	用 single QP（多 QP 才反映真实上限）
Recovery time	不说包括什么（lease 还是真的 recovery）

🌟 审稿人 checklist：看 latency 必看 p99 + p999，不看 average。

6.4 Bootstrap CI 的重要性

第 5 章模块十五已经详细讲过。简短重复：

   单次实验数字不靠谱
   ──────────────
   - 噪声大（5-10%）
   - 不知道差异是否显著
   
   bootstrap 95% CI
   ──────────────
   - 5 次实测
   - bootstrap 重采样 10000 次
   - 报 95% CI [low, high]

---

7. Sensitivity 实验：CN/MN 数 / threads / coroutines

7.1 必做的 sensitivity 实验

   主流 sensitivity 维度
   ──────────────────────
   1. CN 数 (1, 2, 3, 4, ...) → 扩展性
   2. MN 数 (1, 2, 3) → MN 容量与瓶颈
   3. Thread 数 (per CN) → CPU 瓶颈
   4. Coroutine 数 (per thread) → I/O bound 适应
   5. Warehouse 数 (W=1, 10, 40, 100) → 冲突敏感性
   6. Workload mix (NewOrder %, Payment %, ...) → 负载形状

7.2 经典 sensitivity 图

   CN 数扩展性图
   ──────────────
   y轴：吞吐 (KTPS)
   x轴：CN 数 (1, 2, 3, ...)
   ─────────────────
   ideal:    线性增长
   atomic 触顶:  在 N 处饱和
   AURA:     近线性
   ↑ 这是 LOTUS / AURA 的核心 selling point figure

7.3 没做 sensitivity 的论文

⚠️ 审稿信号：只报单一配置 + 不做 sensitivity 的论文质量普遍不高——审稿人会怀疑作者只测了”最有利”的配置。

---

8. 跨论文对比的 8 个不公平

8.1 不公平点列表

   不公平点（按严重程度）
   ──────────────────────
   1. 硬件不同（CX-3 vs CX-6 atomic IOPS 差 5×）
   2. 节点数不同（1 CN vs 3 CN 不能比）
   3. CN-MN 配比不同（1:1 vs 3:1）
   4. record size 不同（FORD 缩了 stock 行大小）
   5. warehouse 数不同（W=1 vs W=40）
   6. 客户端 thread 数不同
   7. 事务 mix 不同（不全 5 类事务）
   8. metric 定义不同（average vs p99）

8.2 一个真实例子

   "FORD: 250 KTPS, LOTUS: 280 KTPS"
   ──────────────────────────────────
   实际：
   - FORD 测的是 c6525, 2 CN, W=40
   - LOTUS 测的是 c6525, 3 CN, W=20
   ↑ 节点数和 W 都不同
   ↑ 不能直接说 "LOTUS 比 FORD 快 12%"

8.3 公平对比的标准做法

   公平对比 checklist
   ──────────────────
   [ ] 完全相同硬件（同一集群）
   [ ] 完全相同 CN/MN 配置
   [ ] 完全相同 workload 参数
   [ ] 同一份 baseline 实现（不是从论文里抄数字）
   [ ] 同一个 metric 定义（average vs p99）
   [ ] bootstrap 95% CI

🌟 AURA 的实验做法：在自家集群上重新跑 LOTUS 复现 + FORD baseline + AURA——保证 apples-to-apples。

---

9. 可复现性约定与 USENIX AE

9.1 USENIX Artifact Evaluation 三档

等级	要求
Available	代码可下载
Functional	至少能跑通一个实验
Reproducible	能复现 paper 主要图表

DM 事务论文目标至少 Functional，Reproducible 加分。

9.2 可复现包必备

   Reproducibility package（参考模块十五第 9 章）
   ────────────────────────────────────────────
   ├── README.md（5 分钟内能跑通的 quickstart）
   ├── docker/Dockerfile（锁定环境）
   ├── scripts/
   │   ├── bootstrap.sh
   │   ├── run_fig2.sh, run_fig3.sh, ...
   │   └── plot.py
   ├── configs/（每个实验的 config）
   ├── seeds/（workload random seed）
   └── data/（论文用的原始 CSV）

9.3 可复现的现实困难

⚠️ 现实：

• DM 实验需要特定硬件（CloudLab c6525）
• 即使代码开源，没硬件读者也跑不动
• “Reproducible” 真正达成的论文 < 30%

🌟 AURA 的做法：详见模块十五第 9 章——bootstrap_apt_cluster.sh + 完整 patch 清单让任何 CloudLab 用户能复现。

9.4 替代方案：trace-driven simulation

如果硬件复现不可行：

   Trace-driven 复现
   ──────────────────
   - 在硬件平台上录制 trace（事务 + RDMA op）
   - 公开 trace
   - 读者用 simulator 复现

⭕ 互补：trace-driven 牺牲精度（不能反映真实 NIC 行为）但提高 reproducibility——特定 metric（abort rate / hot key）下足够准。

---

✅ 自我检验清单

• 4 大 benchmark：能列出 TPC-C / SmallBank / TATP / YCSB 各自定位
• TPC-C 的 5 类事务：能列出比例 + 哪个最复杂
• W=40 是 sweet spot：能解释为什么不是 W=1 或 W=100
• TPC-C 在 DM 上的适配点：能列出至少 3 个
• SmallBank vs TATP 区别：能说明主要差异
• YCSB 不适合 DM 事务：能解释原因
• microbench 的价值：能描述至少 2 种 microbench
• 必报 metrics：能列出 throughput / abort / latency p99
• water marks：能说明为什么 average latency 容易作弊
• bootstrap CI 必要：能写计算代码
• 6 维 sensitivity：能列出 CN/MN/thread/coro/W/mix
• 8 个不公平：能列出至少 5 个跨论文对比的不公平点
• 公平对比 checklist：能默写至少 4 项
• USENIX AE 三档：能区分 Available / Functional / Reproducible
• 可复现包内容：能列出 4-5 个组成部分

---

📚 参考资料

Benchmark 标准

• TPC-C 官方规范：tpc.org/tpcc
• YCSB 论文（Cooper et al., SoCC’10）
• SmallBank / TATP 文档

评测方法论

• Statistically Rigorous Java Performance Evaluation (Georges et al., OOPSLA’07) —— 经典
• A Note on Reproducibility (Henderson et al., 2018)
• USENIX Reproducibility Guidelines：usenix.org

模块十五参照

• 模块十五第 8 章 实验方法论：本仓库 docs/guides/模块十五-分离式事务的动态锁所有权/第8章-实验方法论把故事讲圆的工程套路.md
• 模块十五第 9 章 端到端实战：包含完整 bootstrap 脚本

工具链

• bootstrap CI 库（scipy.stats）
• matplotlib / pgfplots：figure 渲染