TiDB 最初是作为一个分布式 OLTP 数据库开发的，但随着越来越多的用户将其用于 AP 环境，并且给了我们很多积极的反馈，让我们决定，将 TiDB 打造成一个支持 OLTP + OLAP 的 HTAP 数据库。为了达到这个目标，我也在思考，如何让 TiKV 更好的支持行列混存。刚好最近一段时间研究了一些相关的知识，这里简单总结归纳一下，先看看业界的一些方案，然后在想想后续我们会如何去做。
PAX
将 PAX 放在第一个主要是因为 Spanner 在最新的论文里面提到了这种方案，貌似他们也采用了。PAX 融合了 NSM 和 DSM 的优点，在一个 page 里面，使用 mini page 来存放不同的 attributes。关于 PAX，详细可以我之前的一篇文章。
使用 PAX 好处在于更好的利用 CPU 以及缓存，对于不同的 attribute 可以使用不同的压缩方式，另外，对于现有的 NSM 系统，可以非常方便的使用 PAX 改写。
但 PAX 也并不是万能的，因为是一个 page 读取，所以有时候不相关的 attribute 数据还是会读出来。虽然 PAX 相比 NSM 对于缓存的利用更加高效，但还是不能做到 DSM 那种程度。另外，一些 DSM 的 vectorized processing 等特性，仍然不能很好的用在 PAX 上面。
PAX 虽然是十几年前就提出的一套方案，但现在主流的 HTAP 系统真的很少用到，除了 Spanner 公开之外（话说我对它是否已经大规模用在 Spanner 上面，以及性能怎样是存疑的），业界还猜测 Oracle 也有用到，这个如果有人清楚，麻烦确认一下。
Fractured Mirrors
Fractured Mirrors 的理念主要源于 paper A Case for Fractured Mirrors，这篇 paper 虽然看起来很复杂，但核心理念就是写数据的时候，写两份，一份 NSM，一份 DSM，根据不同的查询语句路由到不同的 storage 上面。
通常，服务器都会做 raid，所以其实写两份的开销并不会很大，对于 TiKV 来说，因为天生的三副本，没准 Fractured Mirrors 是一个比较合适的方案，譬如我们可以用一个副本作为 NSM，两个作为 DSM，然后查询的时候路由到不同的副本上面去。这套机制看起来是很美好的，但其实难度也很大，毕竟要维护两套高性能的 storage 方案，这已经不是一般的 team 能 hold 住的。
FSM
FSM 将一个 table，分成了不同的 Tile，每个 Tile 聚合了相关的 attributes，Tile 可以认为是 DSM，然后 Tile 里面则是使用 DSM 存储。不同于 PAX 只有一种特定的 page 格式，FSM 会根据实际的查询等统计信息，动态的进行变更底层结构的。关于 FSM，详细可以参考我之前写的一篇文章。
对于 FSM 来说，如果我们预先就能很好的设计出一个 Tile 到底包含哪些 attributes，那么就能非常高效的处理了。但大家知道，这在现实中是不可能的，毕竟我们的业务也可能会不断变化。我们需要很好的设计一套系统，实际根据外面的查询请求变化，动态的去调整底层的 Tile 结构，这个难度是非常大的。我觉得唯一可行的就是引入机器学习，毕竟已经有 paper 说了如何根据机器学习来优化 SQL 的查询计划了。
小结
上面就是最近一些关于行列混存的总结，这里并没有提及 Kudu，因为我觉得 Kudu 后面还需要更深入的研究一下。后续到底 TiKV 如何去支持 HTAP，我们还会持续在考察业界方案一段时间，然后在思考如何去做，也非常欢迎在这方面有经验的同学加入，一起将 TiDB 做成全球顶级的 HTAP 系统。
