Review on Database paper

发表于 |

Database paper part 1–7：对照论文原文的核查报告

核对日期：2026-09-22。按 7 篇博文组织，覆盖其中 23 篇论文／技术报告及 Titan 工程延伸，共保留 36 处值得纠正或澄清的表述。

Database paper part 1

博文：Database paper part 1。

C-Store: A Column-oriented DBMS

1. 两类编码的适用条件写反了【明确错误】

  • 博客摘录：“bitmap”；“delta encoding”。位置：CStore 末尾的 RS 存储优化列表。上下文转述：作者把高基数、按本列排序的列对应到位图编码，把低基数、不按本列排序的列对应到差分编码。
  • 论文摘录：“Type 2: Foreign-order, few distinct values”；“b is a bitmap”；“Type 3: Self-order, many distinct values”。见 论文 §3.1，PDF 第 5 页。
  • 为什么不对：论文给低基数、按其他列排序的列建立位图；给高基数、按本列排序的列保存相邻值之差。博客恰好调换了这两项。更正后四种对应关系是：自排序且低基数→游程编码；非自排序且低基数→位图；自排序且高基数→差分；非自排序且高基数→论文暂不编码。

【Response】

确实是笔误。

Kudu: Storage for Fast Analytics on Fast Data

1. 把规划中的 PRE_VOTER 写成了已经采用的机制【论文版本／时态不准确】

  • 博客摘录：“主要引入了 Pre Voter”。位置：Replication 末尾。
  • 论文摘录：“we plan to implement a PRE VOTER replica state”。见 论文 §3.3.1，PDF 第 5 页。
  • 为什么欠妥：所链接论文描述的当时实现会直接把新节点加入为 VOTER；PRE_VOTER 是解决追赶期间可用性下降的计划方案。博客对该方案作用的解释基本正确，但没有区分现有实现与未来设计。

【Response】

这也太会挑刺了。

2. 32 MB 的边界属于 DiskRowSet，不是其内部每个文件【明确错误】

  • 博客摘录：“32MB 大小的文件”。位置：Tablet storage → DiskRowSet 首段。上下文转述：作者称一个 DiskRowSet 被拆成若干个这种大小的文件。
  • 论文摘录：“we roll the DiskRowSet after each 32 MB of IO”。见 论文 §4.4，PDF 第 7 页。
  • 为什么不对：这里是在刷新 MemRowSet 时，每累计约 32 MB I/O 就结束当前 DiskRowSet、生成下一个；一个 MemRowSet 因而可以产生多个 DiskRowSet。论文并未规定每个列文件都是 32 MB。博客把 RowSet 的切分粒度误写成了其内部文件大小，容易误解后续增量压缩的单位。

Cache Craftiness for Fast Multicore Key-Value Storage（Masstree）

1. border node 本身就是该层 B+ 树的叶节点【结构解释错误】

  • 博客摘录：“leaf nodes”。位置：结构中解释图 1 的段落。上下文转述：作者把 border node 描述为组织另一层叶节点的节点，并把图中的五角形理解成叶节点。
  • 论文摘录：“Border nodes resemble leaf nodes in conventional B+-trees”。见 论文 §4.1，PDF 第 3 页。
  • 为什么不对：border node 对应当前 B+ 树的叶层，其槽位保存值或者指向更深 trie 层的指针。不能据图形把它解释成“叶节点上面还有一层 border node”。指向下一层 B+ 树的边，也不等同于同一棵 B+ 树内部从父节点到叶节点的边。

2. 无须递增版本号，依靠的是 value 原子更新，不是 version 对齐【机制解释错误】

  • 博客摘录：“version 的 alignment”。位置：Writer–reader coordination → Update。
  • 论文摘录：“atomically updating values using aligned write instructions”。见 论文 §4.6.1，PDF 第 5—6 页。
  • 为什么不对：论文保证读者只会读到旧值或新值，因此此类值更新可以省去 border node 的版本号递增。博客把原子写的对象从 value 换成 version，反而无法解释为何 version 可以不变。旧值的延迟回收是另一项要求，由随后讨论的 RCU 机制处理。

Ceph: A Scalable, High-Performance Distributed File System

本次对照没有发现需要列为明确错误的可靠问题。博客关于先更新其他副本、后更新 primary，以及 ack 与磁盘 commit 分离的叙述，均符合 2006 年论文 §5.2—5.3，PDF 第 6—7 页。开头把 PG 和 OSD 写成包含关系虽不严谨，但后文已经准确说明对象→PG→OSD 的映射，不建议把它升级为独立技术错误。

Database paper part 2

博文：Database paper part 2。

Greenplum: A Hybrid Database for Transactional and Analytical Workloads

1. 把 10 秒采样窗口解释为一条查询的时长【表述欠妥】

  • 博客摘录：“10s 的查询”。语境转述：作者据此解释引言中的锁开销图。博客，Intro
  • 论文摘录：“on a 10-second sample”。位置：§1，论文第 2 页，配套 Figure 2 在第 3 页。论文
  • 为什么欠妥：原文讲的是 10 秒的采样窗口，没有把某条查询的延迟设为 10 秒。前后讨论的对象反而是短查询在高并发下受到的锁开销。将采样时长写成查询时长会改变读者对实验负载的理解。宜写成“在 10 秒采样中观察锁时间占比随连接数的变化”。

Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

1. 消除的是驱逐时的数据页写出，不是缓存驱逐【明确错误】

  • 博客摘录：“cache evection”。语境转述：作者把它与后台写、checkpoint 一起列为 Aurora 数据库层没有的机制。博客，Offloading Redo Processing to Storage
  • 论文摘录：“the system finds a victim page to evict”。位置：§4.2.3，论文印刷页 1046／PDF 第 6 页。论文
  • 为什么不对：缓存容量有限，Aurora 仍会选择并驱逐页面。变化在于驱逐脏页时不由数据库实例把整页写回存储，因为修改已经通过 redo 日志交给存储层。这是删除 page flush 路径，不是删除 eviction。博客后文也继续讨论驱逐，说明这里应收窄用语。

2. “重启无操作”必须限定为不再集中回放 redo【表述欠妥】

  • 博客摘录：“无需进行任何的操作”。语境转述：作者在说明 redo 下推后，将其作为数据库重启时的总体结论。博客，同一节
  • 论文摘录：“The database does need to reestablish its runtime state”。位置：§4.3，印刷页 1046；后续 undo 说明在 1047。论文
  • 为什么欠妥：启动仍需与每个 PG 的读 quorum 交互、重新确定 VDL、持久记录截断范围，并重建未完成事务信息，随后执行可在线进行的 undo。被消除的是传统数据库启动前集中回放 redo 的工作。论文 §3.2 本身也用了概括性的“启动无需工作”的说法，因此这不是纯粹翻译错误；但结合 §4.3，博客应明确其适用范围。

核验备注（不计为博客误读）：博客给出的页面驱逐条件 pageLSN ≥ VDL 与 §4.2.3 原文一致；按前文 VDL 的持久前缀定义，以及本段要求页面所有修改已持久化的语义推导，应为 pageLSN ≤ VDL。这是论文内部的疑似不等号笔误，不计为博客误读。同页原文

Dynamo: Amazon’s Highly Available Key-value Store

1. Merkle 树叶子散列的是 value，不是只有 key【明确错误】

  • 博客摘录：“key 的哈希值”。语境转述：作者用它定义 Merkle 树的叶子。博客，Handling permanent failures: Replica synchronization
  • 论文摘录：“hashes of the values of individual keys”。位置：§4.7，PDF 第 8 页。论文
  • 为什么不对：副本同步要检测同一个 key 的内容是否不同。如果 A 保存 k→v1、B 保存 k→v2，只对 key 做哈希，两边叶子会相同，树根也无法反映这次内容差异。论文要求对各 key 对应的 value 做哈希，再向上汇总，才能识别这种副本分歧。

核验备注：博客关于 hinted handoff 避免临时故障导致请求失败的概括，基本复述论文 §4.6，不能当作独立的误读证据；严格理解仍需结合 §4.5 的 R/W 响应门槛。博客的向量时钟单向比较表述也近乎逐字对应原文，本次也未将其列为博客独立错误。

WiscKey: Separating Keys from Values in SSD-Conscious Storage

对照版本：TOS 2017 扩展版。作者提供的论文全文

1. 恢复扫描的终点写反了【明确错误】

  • 博客摘录：“直到 tail”。语境转述：作者说恢复时从最近持久保存的 head 扫描到该处。博客，Optimizing the LSM-Tree Log
  • 论文摘录：“until the end of the vLog”。位置：§3.4.2，页码 5:14／PDF 第 14 页。论文
  • 为什么不对：tail 是旧数据一端的 GC 边界；head 是追加位置，持久保存的 head 相当于恢复扫描的起点。恢复应从这个检查点继续向文件末尾扫描，以重建尚未进入持久 LSM 的新记录。扫描到 tail 混淆了恢复与 GC 的方向，不能找回检查点之后追加的数据。

Titan（工程延伸）

该节主要是对 TiDB 官方 Titan 文档的工程说明，博文未指定一篇独立的 Titan 论文。已核对其 KV 分离、BlobFile、传统 GC 与 Level Merge 概述，未发现适合按“博客—论文原文”格式列出的可靠问题；不把 WiscKey 的恢复算法直接当成 Titan 的实现规范。

Database paper part 3

博客：Database paper part 3。

DuckDB: an Embeddable Analytical Database

1. 把避免崩溃的设计要求写成崩溃后的隔离保证【表述欠妥】

  • 博客摘录：“不会把宿主程序给崩掉”。上下文转述：作者说内嵌数据库即使已经崩溃，例如 OOM，也不会使宿主程序崩溃，而是终止查询。（博客 DuckDB / Intro / 稳定性。）
  • 论文摘录：“it takes the host down with it.”；“Queries need to be able to be aborted cleanly”。原文 §1，PDF 第 2 页
  • 为什么欠妥：论文恰恰先指出，同一进程内的嵌入式数据库一旦崩溃会连带宿主，然后据此提出资源不足时应可控地中止查询的要求。查询报错并正常返回与数据库已经崩溃是两件事。博客把前者的设计目标写成后者的故障隔离保证；原论文没有说数据库或进程真的崩溃后宿主仍能存活。

Bitcask: A Log-Structured Hash Table for Fast Key/Value Data

未发现足以列为确定错误的问题。 博客实际链接的是二手技术文章；本次另查 Basho 原始技术报告。其关于 active file、内存 keydir、merge、hint file 和操作系统缓存的主要说明与原报告相符。对扫描负载和内存攒批的评价缺乏充分论证，但措辞存在解释空间，不据此硬判错误。

Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing

1. 整个 shard file 可见的条件把最大值写成最小值【明确错误】

  • 博客摘录：“minimum LSN”。上下文转述：作者把这个值不大于读版本作为整个文件可见的条件。（博客 Hologres 列存读取的第 2 个条件。）
  • 论文摘录：“if its maximum LSN is equal to or smaller than LSNread”。原文 §3.4，PDF 第 6 页，印刷页 3277
  • 为什么不对：必须检查文件的 最大 LSN，而不是最小 LSN。例如文件含 LSN 10 和 30，读取版本为 20，最小值虽然小于 20，LSN 30 的行仍不能被读到。博客条件会把部分可见文件误判成全部可见，也使紧随其后的第三种情况无法正常成立。应为：最小值大于读版本则跳过；最大值不大于读版本则全部可见；其他情况逐行过滤。

2. suspended 状态的可调度性写反了【明确错误，可能是漏字】

  • 博客摘录：“被调度”。上下文转述：作者用这个词解释任务队列为空时的 suspended 状态。（博客 Execution Context 生命周期段。）
  • 论文摘录：“Being suspended means the EC cannot be scheduled”。原文 §4.2.2，PDF 第 7 页，印刷页 3278
  • 为什么不对：队列为空时没有任务可执行，EC 不可被调度；有任务提交后才切换为 runnable。博客很可能漏了否定词，但按现有文字理解会直接颠倒调度状态机。

CockroachDB: The Resilient Geo-Distributed SQL Database

1. 节点心跳的方向和两类租约被混在一起【明确错误】

  • 博客摘录：“从 system Range 往”。上下文转述：作者说由 system Range 向各 Range 的 leaseholder 维持 4.5 秒心跳，并笼统说 lease 每 9 秒续期。（博客 SYSTEM OVERVIEW。）
  • 论文摘录：“nodes heartbeat”；“System Ranges”。原文 §2.2.1，PDF 第 3 页，印刷页 1495
  • 为什么不对：原论文描述的是节点每 4.5 秒更新 system Range 中的存活记录，用户 Range 的 lease 绑定其所在节点的存活性。每 9 秒更新的是 system Range 自己采用的到期型租约。博客既反转心跳方向，也省掉 9 秒续期所针对的租约种类，容易被理解成所有 Range 租约都按同一固定到期机制运行。

2. 写写冲突不一定要求重试事务【概括过度；作者以问答补充】

  • 博客摘录：“重试”。上下文转述：作者在问号标注的补充中，将 WW 冲突概括为一定需要重试。（博客解释 leaseholder 算法的问答补充。）
  • 论文摘录：“will wait”；“advances its timestamp”。原文 §3.3.3，PDF 第 6 页，印刷页 1498
  • 为什么不对：论文区分两种情况：遇到较早事务尚未提交的 intent，等待该事务结束；遇到时间戳更高的已提交值，把自己的时间戳向后推进。时间戳推进后若读集验证成功，事务可以继续。发生死锁或读集失效等情况才可能必须中止或重试。博客后文实际上也正确介绍了等待，不能在前面一概断言必须重试。

3. closed timestamp 相对当前时间的方向写反【表述方向有歧义】

  • 博客摘录：“晚 2s”。上下文转述：作者称 closed timestamp 通常比当前时间晚约两秒。（博客 Follower reads。）
  • 论文摘录：“trail current time by ~2 seconds”。原文 §3.5，PDF 第 7 页，印刷页 1499
  • 为什么不对：原意是落后于当前时间，即时间戳数值约为当前时间减两秒，而不是处于当前时间之后。这也解释了为什么该机制服务的是足够旧的历史快照。若作者用“晚”意指时钟走慢，则应改成“早于当前时间约两秒”消除歧义。

核验备注（不计为博客独立错误）：博客在 Algorithm 1 的说明中把 read refresh 写成检查 op.key，随后又写到了整个读集。原论文伪代码第 11 行本身也采用这个简写，正文 §3.1.1、§3.4 才说明验证先前读取的有效性。因此不能把论文自身的简写归咎于博客；实现时应以完整读集验证的说明为准。原文 Algorithm 1，PDF 第 4 页

Database paper part 4

博客：Database paper part 4。

Column-Stores vs. Row-Stores: How Different Are They Really?

1. index-only plan 的性能问题不是回表【明确错误】

  • 博客摘录：“要回表”。上下文转述：作者认为没有过滤条件的列在 index-only plan 中比较慢，是因为需要回表。（博客 ROW-ORIENTED EXECUTION / Index-only plans 的问答。）
  • 论文摘录：“Such plans never access the actual tuples on disk.”。原文 §4，PDF 第 4 页，印刷页 970
  • 为什么不对：这里的执行计划始终从索引获取列值，无须按照行号去基础表取完整记录。没有谓词的列之所以可能很慢，是需要完整扫描该列索引，再与其他索引得到的行号集合进行合并。例如筛选年龄后求平均薪水，独立薪水索引仍要完整扫描；复合索引则可以直接提供符合年龄条件的薪水。把完整索引扫描误读成回表，混淆了两种不同开销，也与博客自己前一段对 index-only 的定义相矛盾。

To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?

1. 文中的 GFS 正是 Google File System【明确错误】

  • 博客摘录：“不是 Google FS”。（博客 Prior Work / Data layout mechanisms。）
  • 论文摘录：“The Google File System.”。原文 §3.3 引用 Ghemawat，参考文献在 PDF 第 11 页
  • 为什么不对：正文的 GFS 带有 Ghemawat 文献标记，文末直接给出论文全名及 SOSP 2003 出处，因此系统身份没有歧义。博客紧随其后的 64 MB chunk、并发 record append、记录不跨 chunk 等介绍，也都是在讲这个系统。

2. 75% 是旧版碎片整理工具遇到困难的条件，不是自动启动条件【明确错误】

  • 博客摘录：“在跑了”。上下文转述：作者说 NTFS 在磁盘占用超过 75% 时会运行碎片整理机制。（博客同上。）
  • 论文摘录：“have difficulties running when the occupancy was greater than 75%”。原文 §3.3，PDF 第 5 页
  • 为什么不对：论文说的是 NT 4.0 自带的碎片整理工具在磁盘占用超过该阈值时难以运行，并且紧接着说明后续版本修正了这一限制。博客将工具运行受限的条件写成了整理动作的触发条件，还省略了版本范围。原文不能支持 NTFS 到 75% 就自动执行碎片整理的结论。

3. storage age 应明确排除初始装载【表述欠妥；原文定义也不够统一】

  • 博客摘录：“曾经写入”。上下文转述：作者用这个量除以当前仍在使用的数据量，作为 storage age。（博客 Comparing Files and BLOBs / Storage age。）
  • 论文摘录：“bytes in deleted or replaced objects”。原文 Abstract，PDF 第 2 页；实验基准另见 §5.2，PDF 第 8 页
  • 为什么欠妥：如果将“曾经写入”按字面理解成包括初始装载及目前仍存活的数据，总写入量除以存活量在刚装载完时至少为 1；论文实验却把刚装载完定义为 age 0。更清楚的表述是：统计累计被删除或替换的对象字节数，再除以当前存活对象字节数；实验中这相当于平均覆盖轮数。论文 §4.6 自己也用了“once existed”这种不够明确的措辞，博客并非凭空引入歧义。博客摘要和后文也知道 bulk load 对应 0，因此这里应澄清计数起点，不宜定为独立的概念性误读。论文 §4.6，PDF 第 7 页

Cloud Programming Simplified: A Berkeley View on Serverless Computing

1. warm pool 中的虚拟机是待分配，而不是已分配给租户【明确错误】

  • 博客摘录：“被分配给了”。上下文转述：warm pool 中的 VM 被描述为已经分配给某个租户。（博客 Contextualizing Serverless Computing / 隔离。）
  • 论文摘录：“need only be assigned to a tenant”。原文 §2.1，PDF 第 7 页
  • 为什么不对：这里的意思是启动等准备工作已经完成，接下来只需分配给租户，省掉现建虚拟机的成本。它不是说这些实例已经绑定某个租户。原文还在 §4.2 描述了预先启动操作系统和常用库，使准备好的实例池可供不同租户取用；active pool 则是已经执行过函数、保留以供后续调用的实例。博客把待执行的分配动作误译成已完成状态。

2. 共享内存存储的统计复用，不等于超卖，也不要求把计算合到同一台 VM【表述欠妥】

  • 博客摘录：“超卖”；“一个 vm 上”。上下文转述：作者用前者概括内存统计复用，又把单个应用受益解释为原先分布于不同 VM 的服务现在可以放到同一 VM。（博客 System challenges / 高性能存储。）
  • 论文摘录：“a shared in-memory service”；“another VM belonging to the same application”。原文 §4.2，PDF 第 16 页
  • 为什么欠妥：论文此处讨论的是把应用状态放到共享的分布式内存存储里，从而让不同应用、或同一应用在不同 VM 上的函数，按需使用同一存储容量池。计算可以继续位于不同 VM。这个收益来自取消各 VM 对存储容量的固定切分；既不要求承诺容量超过物理容量，也不依赖把函数部署到同一 VM。超卖和计算共置可以是其他资源优化措施，但不是本段正在解释的机制。

Database paper part 5

博文：Database paper part 5。

Fast Scans on Key-Value Stores

1. 将扫描性能不足概括为只有点查能力【表述欠妥】

  • 博客摘录：“只支持点查”。语境转述：作者在 Why is it Difficult? 中把 Cassandra、HBase 等 KVS 归入这一类。博客
  • 论文摘录：“have difficulties to process scans with a competitive performance”。位置：§8，印刷页 1536／PDF 第 11 页。论文
  • 为什么欠妥：论文讨论的是扫描性能不能满足分析负载，而非这些系统没有扫描能力。Table 1 已测出 Cassandra 和 HBase 的扫描耗时，§8 还明确提及 Cassandra 的扫描功能。这里应写成“设计和优化主要面向 get/put，分析扫描性能不足”。§2.2 原文也有将其设计目标概括为只服务 get/put 的宽泛措辞，因此这是未结合全文补充范围，而非博客凭空编造了一个结论。

核验结论：其余关于 TellStore-Log／TellStore-Col 的主要数据布局、版本链、self-contained metadata 和 GC 流程，未找到足够可靠的独立误读。博客中若干过于概括的并发与 MVCC 表述，在论文原文中同样存在，不按博客特有错误累计。

PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees

1. 把降低内存开销列为收益，与实验结果不符【明确错误】

  • 博客摘录：“内存开销”。语境转述：摘要将降低它与降低写放大并列为 FLSM 的目标／收益。博客，摘要
  • 论文摘录：“PebblesDb consumes about 300 MB more than HyperLevelDB.” 位置：§5.5、Table 4，PDF 第 15 页。论文
  • 为什么不对：论文的核心收益是减少写 I/O，并未证明普遍节省内存；其实现为 Bloom filter 的保存与构建额外使用内存。Table 4 中，PebblesDB 的读负载内存为 500 MB，HyperLevelDB 为 154 MB，RocksDB 为 36 MB。即使写负载下 PebblesDB 比 RocksDB 占用更少，也不能概括为相对 LSM 普遍降低内存开销。应明确比较对象与负载，并说明空间成本的权衡。

2. guard 的异步插入被写成并行处理【术语不准确】

  • 博客摘录：“并行的”。语境转述：作者以此总结 Inserting and Deleting Guards 的延后插入方案。博客
  • 论文摘录：“guards are inserted asynchronously into FLSM”。位置：§3.3，PDF 第 5 页。论文
  • 为什么不对：这里强调将 guard 先记为 uncommitted，到后续 compaction 再调整 SST 并发布新 guard，避免立即承担跨层改动成本；异步描述任务何时生效，并不意味着这些层同时并行执行。论文另在 §3.4 讨论不同 guard 的 compaction 可以并行，这是另一件事。博客随后对 uncommitted 集合和生效时机的说明基本正确，替换这个术语即可。

核验备注（不计为独立误读）：博客关于 compaction 通常不重写 SST 的说法，直接对应 §3.4 原文；作者还主动质疑分割是否需要重写。结合 §3、§3.7，应理解为避免重写目标层已有数据，每份数据通常每层写一次，而非整个 compaction 零写入。博客前面的摘要和 Guards 节已经提到同层限制，因此不宜再把这一句孤立为确定错误。

The Snowflake Elastic Data Warehouse

1. 一致性哈希的对象是表文件名，不是 table id【明确错误】

  • 博客摘录：“table id”。语境转述：在 Local Caching and File Stealing 一节，作者说按表的标识做一致性哈希，使访问同一张表的查询集中到同一 worker。
  • 论文摘录：“consistent hashing over table file names”。见 论文 §3.2.2，PDF 第 4 页／印刷页 218。
  • 为什么不对：分配单位是同一张表的不同文件。这样既能复用同一文件的缓存，又能把大表扫描分给多个 worker。若改成按 table id 映射，便会把整张表的初始文件分配和缓存亲和性集中到同一 worker，改变论文所描述的并行扫描与缓存分布机制；后续的 file stealing 是另一项负载调整措施。

2. 向量化执行与延迟物化不是同一个概念【概念混淆】

  • 博客摘录：“也是 late materialzation”。语境转述：Execution Engine 一节将 vectorized 直接解释为延迟物化。
  • 论文摘录：“in batches of a few thousand rows in columnar format”。见 论文 §3.2.3，PDF 第 4 页。
  • 为什么不对：此处说的是按列式批次将中间结果传给下游，避免先生成完整中间结果。延迟物化讨论的是何时把不同列的值组装为元组。两者可以配合，但批处理并不自动等于推迟元组重建；论文此处也没有将二者定义为同义词。

3. proprietary engine 被误解成专有硬件【翻译错误】

  • 博客摘录：“专有硬件”。语境转述：Storage Versus Compute 一节据此描述计算层。
  • 论文摘录：“(proprietary) shared-nothing engine”。见 论文 §2，PDF 第 3 页／印刷页 217。
  • 为什么不对：proprietary 修饰的是 Snowflake 自有的查询引擎软件，不是硬件。§3.2 随后明确说 VW 由 EC2 实例构成。此处应写成使用 Snowflake 自有的 shared-nothing 引擎。

Database paper part 6

博文：Database paper part 6。

PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers

1. 双端口网卡被写成了两块网卡【事实错误，影响较小】

  • 博客摘录：“两个 RDMA NIC”。语境转述：Disaggregated Data Centers 一节用它解释连接两个 ToR 的网络冗余。
  • 论文摘录：“a dual-port RDMA NIC”。见 论文 §2.2，PDF 第 3 页。
  • 为什么不对：论文描述的是一块双端口网卡，两个端口分别连接不同 ToR。两块网卡与一块双端口网卡的故障边界不同；原文这里只保证单条网络链路失效时的连续服务，不能把端口冗余改写成网卡冗余。

2. slab 容量单位应为 GB【单位笔误】

  • 博客摘录：“1Gb”。位置：Remote Memory Management。
  • 论文摘录：“slab is 1 GB”。见 论文 §3.1.2，PDF 第 4 页。
  • 为什么不对：大写 B 表示字节，小写 b 通常表示比特，二者相差八倍。这里应保留论文的 1 GB，不应按 1 Gb 理解容量。

Monkey: Optimal Navigable Key-Value Store

1. 单层极限的参数写错，还遗漏了合并策略的区别【明确错误】

  • 博客摘录：“T 为 1”。语境转述：作者称此时层数 L 为 1，LSM 退化为 log。位置：Tuning the Merge Policy and Size Ratio。
  • 论文摘录：“As T approaches Tlim, the number of levels L approaches 1.”。见 论文 §2，PDF 第 3 页。
  • 为什么不对：论文模型中 T 从 2 开始，单层极限是 T 接近 Tlim = N·E/Mbuffer，不是 T=1。并且 §3 区分了两种极限：tiering 退化为 log，leveling 退化为 sorted array。博客前面的 Buffering Updates 已正确说明 T 取上限时 L 为 1，故此处可能是把 T 与 L 混写的笔误；仍需纠正参数，并补全策略条件。

2. T=2 不能称为读写共同最优点【概括过度】

  • 博客摘录：“读写最优”。语境转述：作者据 Figure 4 将 tiering 在 T=2 时的位置如此定性，并说此时才与 leveling 打平。
  • 论文摘录：“update cost decreases/increases whereas lookup cost increases/decreases”。见 论文 §3，PDF 第 4 页。
  • 为什么欠妥：在 tiering 模型里，增大 T 仍可降低更新成本，但会增加查询成本；T=2 是两种策略渐近复杂度接合的位置。不能据此推出存在一个读写同时最优的通用点，或 tiering 全面劣于 leveling。选择取决于工作负载和内存配置。

Are You Sure You Want to Use MMAP in Your Database Management System?

1. MMAPv1 与 WiredTiger 的迁移历史属于 MongoDB【明确错误】

  • 博客摘录：“MonetDB”。语境转述：在 MMAP Gone Wrong 中，作者将使用 MMAPv1、2015 年改用 WiredTiger 的历史归到这个系统名下。
  • 论文摘录：“MongoDB deprecated MMAPv1 and then completely removed it in 2019”。见 论文 §2.3，PDF 第 3 页。
  • 为什么不对：论文明确在讲 MongoDB。MonetDB 是上一段列举的另一个使用 mmap 的系统；把二者混为一谈，会错误归属存储引擎及其更替历史。

SLM-DB: Single-Level Key-Value Store with Persistent Memory

1. leaf-node-scan 的目的不只是合并小文件【解释欠妥】

  • 博客摘录：“合并小文件”。位置：Selective Compaction。
  • 论文摘录：“improve the sequentiality of KVs stored in L0”。见 论文 §3.3，PDF 第 7 页／印刷页 196。
  • 为什么欠妥：选择条件关注一个连续键区间分散在多少个不同 SSTable 中，而非各文件是否太小。即使文件都很大，若相邻键分散在太多文件中，范围扫描仍会产生较多随机访问。合并的目标是改善键的存储顺序性，文件数量减少只是可能的结果。

2. 按总重叠率选择、多文件合并，被缩成最大重叠的两文件配对【算法描述错误】

  • 博客摘录：“最大的 SST”。语境转述：Selective Compaction 一节说数据库把给定 SST s 与和它重叠率最高的那一个 SST 合并。
  • 论文摘录：“total sum of overlapping ratios for s”；“maximum overlapping ratio value”。见 论文 §3.3，PDF 第 7 页／印刷页 196。
  • 为什么不对：论文先为候选表中的每个 s 累加它与其他候选文件的重叠率，选出总分最大的 s′，再和候选表中与 s′ 重叠的文件合并，并限制一次合并的文件数。最大化的是每个候选文件的总分，不是选出与给定 s 重叠最多的单个搭档；后续也不局限于两文件合并。

Database paper part 7

博文：Database paper part 7。

We Ain’t Afraid of No File Fragmentation: Causes and Prevention of Its Performance Impact on Modern Flash SSDs

1. 文件碎片化与 die 分布不均不是必然关系【表述欠妥；原文引言也有同样简化】

  • 博客摘录：“不能被放置在 contiguous dies 上”。语境转述：Introduction 一节将这一结果直接归因于文件发生 fragmentation。
  • 论文摘录：“presence of file fragmentation does not inevitably result in uneven page distribution over dies”。见 论文 §2.3，PDF 第 5 页／印刷页 196。
  • 为什么欠妥：文件系统块地址是否连续，与 SSD 内部页面在哪些 die 上分布，是不同层次的事情。论文后文给出两类反例：文件有碎片但 die 分布仍均匀；文件没有碎片，却因覆盖写入造成 die 分布失衡。因此更准确的结论是：交错写入等因素可能破坏理想映射，从而增加冲突，不能仅凭文件有碎片就断定内部映射必然失衡。论文引言本身也使用了类似的绝对表述；这里批评的是笔记没有吸收正文限定，而非作者凭空误译。

数值核验补充：博客中文将 NVMe 每队列命令数也写成 65,535，并据此平方，和紧随其后的英文摘录不一致。不过，论文 §2.2 与 §3.1 自己也交换了 65,535 和 65,536 对应的队列数、队列深度。本报告不据这篇内部不一致的论文，把它提升为作者独立造成的架构错误。论文 §2.2、§3.1