TL;DR

本文探讨如何基于 AWS 的多种存储介质（本地 SSD、EBS 与 S3）实现一个 cloud native 版的 kv engine（比如 TiKV [狗头]），以及其中为什么要引入文件系统这一层抽象。

TL;DR

TiFlash 是 MPP + 列存的 HTAP 引擎，这篇主要介绍它的执行器的线程模型。

TL;DR

1. 为什么接口设计要表达清晰明确的语义？
2. 为什么一次代码修改（cl/pr/commit）要有唯一明确的意图？
3. 工作中为什么要树立自己的人设？
4. 如何让 OKR 发挥作用？
5. 如何三句话让客户为你的产品花钱？

TL;DR

std::enable_shared_from_this必须要public继承，否则调用shared_from_this()不会编译失败，但运行时会抛std::bad_weak_ptr的异常。

TL;DR

对于一个成员 X 是另一个成员 Y 的引用的类，C++编译器会默认为它生成移动构造函数和移动赋值函数，但这两个函数是有问题的。建议手动禁掉这种类的移动函数。

但这类问题（dangling）是 C++的根本缺陷，没有好的解法，不要想着有什么万全之策了，接受它。

原文：Hekaton: SQL Server’s Memory-Optimized OLTP Engine

年代：2013

Hekaton是SQL Server的一个内存数据库子系统，它有以下特点：

• 数据全在内存中，但具备持久化存储能力（不会丢数据）。
• 使用无锁结构（latch-free/lock-free）。
• MVCC结合乐观并发控制（optimistic concurrency control）。
• 存储过程可以预编译为C代码，再进一步编译为机器指令。

LLAMA是一种无锁的page管理系统，它包含内存cache与磁盘log structured store（LSS）两部分，并自动控制page在两者之间移动（flush、换入/换出）。

它有以下特点：

• 所有操作都是无锁的（latch-free），内存部分基于epoch机制回收数据。

  优点：系统并行度高；epoch机制几乎是额外开销最小的回收机制，且容易实现。

• 所有page都是immutable的，对page的修改要通过附加一个delta来实现，并通过对mapping table进行CAS来让新的page可见。

  优点：既满足了无锁的需求，又对cache非常友好。

• 磁盘部分是一种log structured store，可以写入完整的page，或delta。

  优点：可以只写入delta能显著降低写放大；LSS这种append-only的结构将所有随机写转化为了顺序写，性能更高，且可以省掉Flash的FTL。

LLAMA可以作为Bw-tree的底层系统。

TL;DR

Wound-wait 与 wait-die 是 DBMS 中处理死锁的两种常见策略，它们的优缺点为：

• Wait-die 会导致更多 rollback，但 rollback 的代价更低：被 rollback 的事务做过的事情比较少。
• Wound-wait 导致的 rollback 较少，但 rollback 的代价更高：被 rollback 的事务做过的事情比较多。

另外 [1] 中提到：

还有一种方法，no wait，就是请求不到锁就回滚，不去做判断。现在的一般看法是，不等比等好，尤其是应用于分布式事务时。

原文：Windows Azure Storage: A Highly Available Cloud Storage Service With Strong Consistency

年代：2011

Windows Azure Storage（WAS）是Azure的存储层，它的特色在于基于同一套架构提供了对象存储（Blob）、结构化存储（Table）和队列服务（Queue）。

这三种服务共享了一个提供了强一致、global namespace、多地容灾、支持多租户的存储层。

个人猜测这种设计（同时推出三种服务）更多出于组织架构的考虑，而不是技术层面上有非这么做的理由。

以及这篇文章作者中有多名后来加入阿里云存储的大佬，所以可以从这里面看到一些后来阿里云存储产品发展的影子。

原文：Hyper: A Hybrid OLTP&OLAP Main Memory Database System Based on Virtual Memory Snapshots

年代：2011

TL;DR

HyPer是一种内存数据库，它有以下特点：

1. 基于H-Store的设计，串行（因而无锁）执行事务（存储过程）。
2. 通过fork子进程方式服务OLAP请求。

通过fork来隔离OLTP与OLAP还挺有创意的，OS的实现显然比自己控制请求间的数据隔离更高效。

目测这仍然是研究大于实用的项目（至少在文章发表时）。