原文：HopsFS: Scaling Hierarchical File System Metadata Using NewSQL Databases

TL;DR

HopsFS 目标是成为下一代 HDFS，其核心改进是使用一个分布式的 NewSQL 系统（NDB）替代了 HDFS 原本的单节点 in-memory metadata management。

亮点：

1. 展示了如何使用分离的存储系统来管理 metadata。
2. 仔细设计 schema 以缓解分布式事务对性能的影响。
3. 并行 load inode。

原文：LocoFS: A Loosely-Coupled Metadata Service for Distributed File Systems

TL;DR

LocoFS 的出发点：

1. 降低 metadata 操作的网络延时。
2. 充分发挥 kv-store 的性能。

LocoFS 做了以下两种优化：

1. 将 dir entry 与 child 的 inode 放到一起管理，更有利于将整个 namespace 的树型结构平坦化为 key-value 结构。
2. 将 file metadata 分为 access 与 content 两类，降低单次操作的粒度。

LocoFS 整体上来看对系统限制还是比较强（限制只有一个 DMS），但思路还不错。

Compiler Explorer 一个例子胜千言。

更准确地说明看这里。

原文：Anti-Caching: A New Approach to Database Management System Architecture

TL;DR

Anti-Caching 是基于 H-Store 实现的 in-memory db。作者认为传统的 RDBMS 是以磁盘为主存，内存为缓存（cache），而 in-memory db 则应该反过来，内存才是主存，磁盘只是用于 swap，数据不会同时存在于两个地方，可以认为“没有 cache”，因此称其为 “anti-caching”。

原文：High Performance Transactions in Deuteronomy

TL;DR

Deuteronomy 终于进化到了 MVCC 加持。新的 Deuteronomy 仍然是 TC + DC 的分离架构，但做了大量的优化，如 Bw-Tree、caching、lock-free 算法/数据结构、epoch reclamation 等。

大多数系统其实不是架构不行，而是单纯优化不到位。

总得来说我们能从 Deuteronomy 上看到很多后来的 cloud database 的影子。

TL;DR

分享某位不愿透露姓名的耿老板发现的 libc++ 的某个奇怪行为：std::function 当内部成员体积足够小，且其 copy 函数标记为 noexcept 时，move ctor 或 assign 函数会优先调用内部成员的 copy 函数，而不是 move 函数。

这不是 bug，但很反直觉。

TL;DR

C++20 coroutine 有一个严重的 bug，且这个 bug 本质上来源于 C++ 标准不完善：在分配 coroutine frame 时，没有严格按 alignment 要求。目前看起来 gcc 与 clang 都中招了，只有 msvc 似乎没问题。

本文记录了我是如何被这个 bug 消耗掉了两三天光明。

TL;DR

AP 系统中缓存算子结果是一种很有效的针对重复查询的优化手段。但这种方法严重依赖于结果的不变性，因此并不适用于频繁更新的场景（如 TiFlash）。本文提出一种通过维护运行期的 skip cache，尽可能跳过无效 page 的优化方法，应该对这种场景有效。

有 paper 已经讲过这种优化的话求告知。

TL;DR

小朋友不要乱学

1. 基于参数数量重载宏函数。
2. 当 __VA_ARGS__ 为空时，忽略多余的逗号。

TL;DR

分布式系统中我们经常会使用多副本策略来保证数据的可靠性。常见的多副本策略可以按容错能力分为两类。假设系统需要能容忍最多 f 个节点失败：

1. 需要 2f+1 个副本的 Quorum 策略，如 Paxos/Raft
2. 需要 f+1 个副本，如 chain replication（下文称 CR）。

本文通过简单的模拟计算，得到以下结论：

1. 固定节点失败概率与每个节点上的 shard 数量，数据丢失概率是节点数量的凸函数，即随着节点数量增加，数据丢失概率逐渐增大，到达峰值后再逐渐减小。
2. 同等存储成本下，CR 的数据丢失概率远低于 Quorum。