Pebble

https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/

https://github.com/golang/leveldb

一下 TiDB 的架构和设计，对 TiDB 有兴趣的同学推荐完整看下，会对理解架构有很大帮助。不过既然重点是 HTAP，那么在我看来比较重要的地方是这三点：

实时更新的列存
Multi-Raft 的复制体系
根据业务 SQL 智能选择行/列存储
后面我也会着重说一下这三部分。

先说存储
TP 和 AP 传统来说仰赖不同的存储格式：行存对应 OLTP，列存对应 OLAP。然而这两者的优劣差异在内存中会显得不那么明显，因此 SAP Hana 的作者 Hasso Plattner 提出使用 In-Memory + 列存技术同时处理 OLTP 和 OLAP。随后 2014 年 Gartner 提出的 HTAP 概念，也主要是针对内存计算。 这里有个关键信息，列存不合适 TP 类场景。这也许已经是很多人的常识，不过也许并不是所有人都想过为何列存不合适 TP。

数据快速访问需要仰赖 Locality，简单说就是希望根据你的访问模式，要读写的数据尽量放在一起。并不在一起的数据需要额外的 Seek 并且 Cache 效率更低。行存和列存，去除 encoding 和压缩这些因素，本质上是针对不同的访问模式提供了不同的数据 Locality。行存让同一行的数据放在一起，这样类似一次访问一整行数据就会得到很好的速度；列存将同一列的数据放在一起，那么每次只获取一部分列的读取就会得到加速；另一方面，列存在传统印象里更新很慢也部分是因为如果使用 Naive 的方式去将一行拆开成多列写入到应有的位置，将带来灾难性的写入速度。这些效应在磁盘上很明显，但是在内存中就会得以削弱，因此这些年以来我们提起 HTAP，首先想到的是内存数据库。

虽然内存价格在不断下降，但是仍然成本高企。虽说分析机构宣传 HTAP 带来的架构简化可以降低总成本，但实际上内存数据库仍然只是在一些特殊领域得到应用：若非那些无可辩驳的超低延迟场景，架构师仍然需要说服老板，HTAP 带来的好处是否真的值得使用内存数据库。这样， HTAP 的使用领域就受到很大的限制。

所以，我们还是以磁盘而非内存为设计前提。

之前并不是没有人尝试使用行列混合的设计。这种行列混合可以是一种折中格式如 PAX，也可以是在同一存储引擎中通过聪明的算法糅合两种形态。但无论如何，上面说的 Locality 问题是无法绕过的，哪怕通过超强的工程能力去压榨性能，也很难同时逼近两侧的最优解，更不用提技术上这将会比单纯考虑单一场景复杂数倍。

TiDB 并不想放弃 TP 和 AP 任何一侧，因此虽然也知道 Spanner 使用 PAX 格式做 HTAP，却没有贸然跟进。也许有更好的办法呢？

TiDB 整体一直更相信以模块化来化解工程问题，包括 TiDB 和 TiKV 的分层和模块切割都体现了这种设计倾向。这次 HTAP 的构思也不例外。经过各种前期的的 Prototype 实验，包括并不限于通过类似 Binlog 之类的 CDC 方案将 TP 的更新同步到易构的 AP 侧，但是这些效果都不尽如人意，我们最终选了通过 Raft 来剥离 / 融合行存和列存，而非在同一套引擎中紧耦合两种格式。这种方式让我们能单独思考两个场景，也无需对现有的引擎做太大的改变，让产品成型和稳定周期大大缩短。另一方面，模块化也使得我们可以更 好借助其他开源产品（ClickHouse）的力量，因为复杂的细节无需被封印在同一个盒子。

市面上有其他设计采用了更紧密的耦合，例如 MemSQL 节点同时运行 TP 和 AP 两种业务，Spanner 选择 PAX 兼顾不同的读取模式，甚至传统数据库大多也在同一个引擎中添加了不同数据组织的支持。这样的架构会引入过于复杂的设计，也未必能在 TP 和 AP 任意一端取得好的收益。

由于选择了松耦合的设计，我们只需要专心解决一个问题就可以搞定存储：如何设计一个可根据主键实时更新的列存系统。事实上，列存多少都支持更新，只是这种更新往往是通过整体覆盖一大段数据来达到的，这也就是为什么多数传统的 OLAP 数据库只能支持批量的数据更新，。如果无需考虑实时主键更新，那么存储可以完全无需考虑数据的去重和排序：存储按照主键顺序整理不止是为了快速读取定位，也是为了写入更新加速。如果需要更新一笔数据，引擎至少需要让同一笔数据的新老版本能以某种方式快速去重，无论是读时去重还是直接写入覆盖。传统意义上分析型数据库或者 Hadoop 列存都抛弃了实时更新能力，因此无需在读或者写的时候负担这个代价，这也是它们得以支持非常高速批量加载和读取的原因之一。但这样的设计无法满足我们场景。要达到 HTAP 的目标，TiDB 的列存引擎必须能够支持实时更新，而且这个更新的速率不能低于行存。

事实上，我们肯定不是第一个在业界尝试实现列存更新的产品。业界对于列存更新，无论是何种变体，一个很通用的做法叫做 Delta Main。既然做列存更新效率不佳，那么我们何不使用写优化方式存储变更数据，然后逐步将更新部分归并到读优化的主列存区？只要我们保持足够的归并频率，那么整个数据的大部分比例都将以读优化的列存形态存在以保持性能。这是一个几乎从列存诞生起就有被想到的设计：你可以认为列存鼻祖 C-Store 就是某种意义上的 Delta Main 设计，它使用一个行存引擎做为写区，并不断将写区数据归并为列存。

https://gocn.vip/topics/11006
http://www.vldb.org/pvldb/vol13/p3072-huang.pdf
https://github.com/tinygo-org/bluetooth
https://github.com/pixie-labs/pixie/blob/main/demos/simple-gotracing/app.go