原文：Performance Tradeoffs in Read-Optimized Databases

TL;DR

有点旧，有些结论可能不适合现在的列存数据库了。

这篇文章讲的是，在面向读优化的数据库中，行存和列存的性能差异在什么地方，分别适合什么场景。

大概结论就是projection的列比例越低、selectivity越低、CPU相比于I/O的速度优势越大，列存的性能越有优势。

原文：Integrating Compression and Execution in Column-Oriented Database Systems

可以与The design and implementation of modern column-oriented database systems对照阅读。

TL;DR

一篇略老（2006年）的paper，但很重要。

数据库中压缩算法的使用是非常影响性能的。这方面列存要比行存更有优势：每列排列在一起天然就适合压缩，而行存中相同列的值是被其它列隔开的。

这篇文章探讨的是，如何在列存数据库中使用压缩，以及不同压缩算法在不同场景中的比较。

原文：TiDB: a Raft-based HTAP database

TL;DR

TiDB是一个HTAP系统，目标是同时服务TP和AP服务，且能保证隔离性和数据新鲜度。它的架构受到了Spanner和F1的影响：计算层类似于F1，无状态；存储层类似于Spanner，支持分布式事务。

它的存储层分为了行存的TiKV和列存的TiFlash，其中TiKV各个replica之间通过Raft保持一致，TiFlash则作为Raft的learner保证看到最新的数据。相比Kudu，TiDB物理上分离了TP和AP，隔离性更好；相比F1-Lightning的基于CDC的replay，TiDB的新鲜度更好。

一些看法：

• TiKV底下使用了RocksDB，但LSM的compaction会导致性能不稳定，在高并发的TP场景可能会有问题，如何解决？
• TiFlash是绑在TiKV上的：
  • 数据一定要先进TiKV再进TiFlash，对于没有强事务需求的场景而言有些浪费，是否能提供更低开销的ingestion？
  • 列存和行存的key order是一样的，是否能有列存格式的索引？
• 与Kudu等系统类似，TiKV的Raft与多副本是绑定的，对支持erasure coding有阻碍，对上云也有阻碍（使用云存储）。

原文：The snowflake elastic data warehouse

TL;DR

Snowflake是一个云原生的数据仓库。它的价值在于：

1. 展示了云平台与分布式系统的差别，如何利用好云上的基础设施。
2. 如何真正以用户体验为导向去设计一个系统。
3. 做系统的startup如何赚钱。

前2条参见最后一小节“Lessons Learnd and Outlook”。

第3条很有价值。（以下一堆马后炮）

之前做系统的startup的商业模式是做开源系统，然后卖license、技术支持。但云时代了，这条路不太好走，前途一眼可见。问题在哪：

1. 你的开源系统要有竞争力，这就过滤掉了很多小用户了，他们用开源系统已经可以满足需求了，为什么要花钱？
2. 大客户不需要买你的服务，首先小公司的技术能力不一定能解决大公司特有的问题，其次大公司也有足够的人和资源，可以自己解决。
3. 最后剩下一些中等客户，他们往往要的是解决方案，而不是某个产品。但“基于开源”这个原则限制住了对应的闭源系统：要么小打小闹，只能解决局部问题而没办法提供好的方案；要么需要大改，甚至还要把周边系统一起改掉，没办法兼容开源生态。

国内做系统的startup很多也有这方面的问题，而且更严重，大客户要资质，小客户不花钱。估值上就能看出来，想达到独角兽要比做业务的公司难得多。

Snowflake选择了基于现成的云平台做第三方云服务商，做附加值。这个思路初看上去不太可行，云平台为什么不抄你的方案？但实际上云平台不是整体，它是由一个个独立的团队组成，互相有着说不清道不明的既合作又竞争的关系。而第三方相当于是每个团队的客户，是可以合作的。而且大公司人虽然多，但不养闲人，分摊到每个方向的人其实很少，尤其是这种要整合资源、探索新模式的工作，更是人嫌狗厌。这就是细分市场、垂直领域、小而精的团队的机会。

可以看到这几年各种startup都开始搞第三方服务了，这是Snowflake的最大的价值：让工程师先富起来。

这种模式国内的公司不太好学，因为国内的云平台通常没那么友善，有着足够多的焦虑的工程师，会抢走任何赚钱不赚钱的业务。那么要出海吗？问题在于出海的话你的优势在哪，国外的客户为什么要买一个中国公司的服务？甚至国内出海的客户也不见得更倾向中国公司提供的服务。

然而2020告诉我们的就是，一切都会变的。

原文：Kudu: Storage for fast analytics on fast data

TL;DR

Kudu是一种同时支持高效的随机读写与扫描的存储系统，是用来弥补Hadoop生态中HDFS与HBase的gap的。它的特点是：

• 自己用Raft实现了多副本（没有用HDFS）。
• 精巧的列存设计。
• 两种一致性级别，有可选的commit wait来实现外部一致的snapshot ioslation。
• codegen。

Kudu应该也属于HTAP系统（或者更接近于HSAP），它的列存设计很棒。但这种使用Raft实现的多副本shard-nothing架构，计算和存储是耦合的，会给后面的扩展带来很多麻烦（比如怎么支持erasure coding）。

原文：Impala: A Modern, Open-Source SQL Engine for Hadoop

TL;DR

Impala是建立在Hadoop生态之上的MPP query engine，它有以下特点：

• MPP，所有节点都可以参与query执行。
• 代码生成。
• 基于pub-sub的元数据同步。

原文：F1: A distributed SQL database that scales

TL;DR

F1是Google用于替换分库分表的MySQL的RDBMS系统。它在Spanner之上建立了一套关系模型，拥有Spanner的跨datacenter的同步replication能力。F1还开发了新的ORM模型，从而将同步geo-replication导致的延时隐藏了起来，保证了E2E延时在替换后没有上升。

原文：Spanner: Google’s Globally-Distributed Database

TL;DR

Spanner 是划时代的 OLTP 系统，它的创新点是：

1. 用 TrueTime 实现了广域的物理 timestamp，这样不引入全局唯一的 TSO 就提供了基于 2PC 的分布式事务与 Snapshot Isolation。
2. 将数据分为了若干个 PaxosGroup，使用 MultiPaxos（但后来 透露他们的实现更接近于当时还未提出的 Raft）实现了高可用。

Spanner 启发了很多后来者，但它的 TrueTime 是很难模仿的，后来者也通常使用 TSO 或 HLC 来代替，但这样就很难做到像 Spanner 一样跨越大洲部署仍然能提供合理的延时。

原文：Large-scale incremental processing using distributed transactions and notifications

TL;DR

Percolator是Google用于构建增量web索引的数据系统。它的价值在于提出了一种基于NoSQL（BigTable）的两阶段提交（2PC）实现。

Percolator的2PC实现有以下特点：

1. 部分去中心化：依赖中心化的Timestamp Oracle（TSO），但不依赖集中式的锁管理节点。
2. 乐观锁：不能阻塞，检测到冲突需要abort。
3. Snapshot Isolation：读比较旧的ts时不会被写block；但为了避免违反SI，读比较新的ts时可能会被写block。
4. 惰性清理：client失败导致的状态不一致不会立即被清理（没有中心节点）。client之间有种协作关系，如果发起事务的client挂了，根据事务进度，其它client既可能帮它abort，也可能帮它commit。

以上很多特点都是源于Percolator没有中心节点，也导致了它的2PC延时偏高（尤其是失败时），但优点是能适应巨大的规模。这也是Google系产品的一个特点，可以不那么快，但一定要支持巨大的规模。

Google系产品的第二个特点是很积极地使用已有产品来构建新系统，这里Percolator选择了基于BigTable来做，就体现了这一点。

这篇文章实际讲了Percolator的两块内容，一个是2PC，另一个是observer，一种可级联的触发器，但后者似乎没有太多关注。

原文：Dremel: a decade of interactive SQL analysis at web scale

TL;DR

这篇文章主要讲Dremel的核心思想和架构原则（参考2010年的paper），包括这些年Dremel的演进（作为BigQuery的后端），以及这些思想在同领域的其它系统中的异同。

在The Seattle Report on Database Research中提到了当前AP系统的若干发展趋势，其中本文重点提到的有：

• SQL：大家都开始用SQL作为查询接口了。
• 计算存储分离。
• 原地分析：数据湖（Data Lake）越来越流行了，同一份数据可以由不同的计算引擎使用，结果再存回数据湖中，而不需要为了不同引擎反复转换数据。
• Serverless计算：提供on-demand方式，用时分配资源，按使用量计费，而不是传统的预留资源。
• 列存：Dremel对嵌套结构的列存处理方式启发了许多后来者。