脑洞分布式关系型数据库的几个技术优化点
在传统数据库的世界里，或许
Oracle已经是一个终极形态。但在分布式关系型数据库的世界里，一切才刚开始。
前言
分布式关系型数据库集分布式技术和数据库技术为一体，像Paxos/Raft和2PC已经是基础能力，不再赘述，这里主要是记录下一些较为脑洞的想法。为了简化，后面简称为分布式数据库。
方向
HTAP
HTAP(Hybrid Transactional/Analytical Processing)混合事务 / 分析处理
1. OLTP，强一致性，快速响应。
2. OLAP，弱一致性，大规模并行。
3. HTAP，取TP和AP二者的平衡点。
传统的逻辑通常是使用ETL将OLTP的增量数据同步到OLAP中进行计算。HTAP本质上依然是这个逻辑，只是在实现上比传统更为紧凑了。
Serverless
一种云上流行的服务形势，相比传统的实例售卖，资源调配上粒度更细。 从技术角度来看，其实是数据库的多租户能力。
脑洞
可扩展的计算模块
有的数据库是存储计算分离设计，像TiDB,CockroachDB等，但对于HTAP的需求而言，存在一定算力瓶颈，毕竟在数仓中，这都是多个节点并行计算的。
这部分如果直接丢SQL层，会使得SQL层变得臃肿，如果下沉到存储层，会带来扩展的问题。
比如TiDB的TiFlash，就是存储和计算耦合的。
因此，我觉得单独设计具备并行计算能力的模块来承接AP的计算或许是个不错的选择。
多种存储引擎
类似MySQL那样的插件式存储引擎。分布式数据库可以使用多种存储引擎实现更灵活的结构。
和传统数据库不同，分布式数据库的底层通常是KV层，简单说就是一切皆索引。数据会被分片存放到各个节点中，对于计算层而言，底层用的是什么存储方式是不需要关心的，它可以是Btree,LSM行存或LSM列存。
三副本
分布式数据库通常会保证数据有3个副本，这三个副本就可以是不同的引擎。当然，这带来的问题也不少，比如磁盘容量的不均匀等，或许并不真的可行。
历史数据归档
按照时间归档，比如热数据存放在行存，冷数据迁移到列存。
批量数据传输优化
曾在一个讲座中，听到这样一个概念。分布式共识未来主要应用于同步控制信息，而不是传输数据。
因为写入的延迟主要来自于共识模块的网络延迟，毕竟要把数据同步给Follower。一般OLTP场景，数据库修改的量不大。但如果是大量数据导入的场景，共识模块的压力就很大了。
因此，我们看TiDB-Lightning工具的物理导入模式，就是直接将数据编译成SST文件，ingest给每个TiKV节点。
于是，我们发现，为什么不能先把SST文件分发到三个节点中，然后通过共识事件将数据ingest导入呢？这就体现了让分布式共识用于控制的理念。因为数据是客户端直接传输到各个节点的，相比先传输给Leader再通过共识模块同步，延迟上会小很多，也降低了leader的压力。