原文：Ceph: A Scalable, High-Performance Distributed File System
这篇文章介绍了Ceph，一种分布式文件系统。它的最大特点是数据层与元数据分离所带来的高弹性。不像其它分布式文件系统（如GFS）master通过本地表记录数据分布，在Ceph中数据是由一种伪随机函数CRUSH来确定分布在哪个对象存储设备（OSD）上的。OSD本身是高度自治的单元，负责replication、错误检测、恢复。这种设计具备了非常高的弹性与灵活性。
（通篇看下来感觉Ceph是挺适合云上部署的，另外明显感觉到分布式系统、存储、数据库三个领域需要融合，至少在2006年）
这篇文章提出了一种行列混合的布局方式PAX，可以在不改变operator的前提下提升cache利用率。现在这种布局几乎成为了各种OLAP系统的标配。虽然这篇文章是针对OLTP的，但OLTP中使用PAX的似乎不是很多。
Chubby的第一个版本基于一个第三方可容错的商业数据库（下文称为3DB），它的replication有很多bug，并没有基于任何已有证明的算法，也无法证明其正确性。最终Chubby将3DB替换为了基于Paxos的实现。
作者在实现Paxos的过程中，发现这个工作并不trivial：
这篇文章就在讲作者将Paxos从理论搬到实际的过程中的一些挑战。
TL;DR
这篇文章是Jim Gray和Leslie Lamport两位图灵奖大佬的合作产物，是数据库与系统两个领域在consensus方面的结合。
Paxos Commit算法使用Paxos弥补了2PC在容错性上的软肋，而进一步的Fast Paxos Commit算法则减少了一轮commit的延时跳数，代价是增加了总的通信次数。
文章另外还论证了经典的2PC就是Paxos Commit的一种特例。
TL;DR
Pig Latin又是一个瞄准了MapReduce表达能力弱点的类SQL语言，它声称“集合了体现SQL精神的高阶查询与类MapReduce的过程式程序”。
关于Pig Latin的逸事：大数据那些事(7)：腾飞的拉丁猪
TL;DR
2005年的前文：‘One Size Fits All’: An Idea Whose Time Has Come and Gone
和前文一样，这篇文章仍然在呼吁针对不同的新兴领域使用不同类型的数据库系统，而不是传统的一套系统打所有（one size fits all）。
原文：An Integrated Approach to Recovery and High Availability in an Updatable, Distributed Data Warehouse
TL;DR
这篇文章介绍了HARBOR，一种针对高可用数仓的新的恢复与高可用机制。相比传统的基于ARIES的系统，HARBOR不依赖log，而是利用冗余replica，在恢复时query其它replica来恢复数据。
总的来说不太适合作为生产系统，错误处理与恢复流程需要考虑非常多的corner case。K-safety机制似乎是database社区对distributed system社区的一种反抗（我偏不用Paxos）。
TL;DR
我们都知道数据库开销的大头是I/O，但在现代机器架构下，CPU与内存的交互成本也不容忽视。这篇文章比较了四种商用数据库在三种典型场景下的性能分解，得出结论：
这篇文章是1999年的，机器是PⅡ，在当前（2021年）的系统中本文的结论仍然有效，且可能有更大的影响。
Amazon Aurora目前有两篇文章：
其中第一篇内容比较多，重点讲架构与实现；第二篇重点讲的是细节，比如一致性、优化、恢复过程、成员变更。
Deep Dive on Amazon Aurora这个slide还介绍了很多paper中没提到的特性，比如cache在DB进程之外、锁优化、索引构建优化等。
我在阿里云Tablestore团队工作了接近6年，这期间几个老板说过一些对我影响特别大的话，记录一下（以及感谢各位老板）。