由这篇报告整理而来10.11CCF数据库专委会走进高校报告-李国良 李飞飞 报告_哔哩哔哩 (゜-゜)つロ 干杯~-bilibili​www.bilibili.com

很多人觉得数据库发展这么久，理论如此成熟，科研里面可以做的东西少了。其实不然，在当下数据越来越爆炸的时代，挑战与机会是并存的。本文是对Guoliang Li老师在CCF走进校园的报告总结后的一份水文，供个人娱乐。

先回顾一下数据库的架构。从单体数据库，到主备来做高可用，再到Oracle RAC的多写，再到完全分布式架构的数据库。RAC有一个共享存储层，支持多写，但是却在存储容量上受限。Spanner系的Share-Nothing架构，网络交互比较多，所以比较依赖事务模型的优化。

Guoliang有讲一个RAC架构比较难设计的点：cache一致性。cache一致性是指，更新操作一般是WAL+内存来避免同步随机写，A可能把更新数据存在内存里了，还没来得及写入磁盘，但是B这时候收到一个读相关数据的请求，要怎么样保证能读到最新的数据(最新的数据在A的内存里)？

分布式数据库的挑战

分片(28:18)

分布式数据库，一个很重要的关键点就是数据怎么分的问题。行存还是列存？这个比较好选择。有更多问题等着研究，比如如何保证你选的partition key在数据增长的时候依然保持均匀分布？

如何选择Partition的列？是不是应该在Query的比较多的列上做Partition？

Join的比较频繁的2个Region，是不是一般放到一个节点比较好？(跨Region查询)

这里有人在SIGMOD上用学习的办法去学partition应该怎么做。同样还有Graph Key Partition。这里没听的特别明白，不过我觉得确实也大有可为，比如你本身就是Graph Database，那么用Graph Key Partition也就很符合数据特性。或者说你用图的办法建模，例如每个节点表示一列，这样可以把频繁Join或者做事务的2个Region放到一个节点上。

以及还有一个研究关键点，partiton完了之后，怎么Evaluate我的partition方法好不好？因为很有可能分片的方案非常多，不可能做到每一种新的Partition都完整跑SQL Query来评测。因此有没有一种Evaluate Model，我给出一个分片方案，就能以比较数学的方式来评估方案的表现？我觉得如果有了这么一个优秀模型，对于Automatically Partition领域应该是一个非常好的助推剂。

事务(34:20)

分布式的事务支持，是Newsql和传统分库分表方案的最重要区分点。有很多业务至今没有使用Newsql，就是因为它们的事务模型比较简单，分库分表就能解决。而传统分布式数据库由于2PC本身的瑕疵，会带来一定的性能抖动。因此，这个模块怎么设计也是一大难题。

业界普遍使用的比较多的模型是2PC。2PC有很多种实现方式，比如各种优化。事务模型涉及到的概念比较多，比如怎么做并发控制，怎么控制写写冲突(一般通过锁)，读写冲突(MVCC)。同时，数据库要支持哪些隔离级别也非常影响相关的设计。比较传统的方案，应该是通过统一发号器，每次查询前/事务开始前拿到一致性视图，比如MySQL就是这么做的。但是TiDB因为想要避免单点，没有实现类似的方案。PG在08年的论文，提出了新的隔离级别SSI，并且应用在系统中，使用的是图检测的方式。

分布式事务纷繁复杂，但是这里我主要讲发号器，它是整个事务的灵魂。一个准确，HA的发号器对于事务是非常有用的，无论是判断数据可见性，一致性，化解数据冲突等等。而分布式架构带来新的难点，因为每台机器时间不一样，会有time drift的现象。因此这鼓励学术界提出更好的发号器。

目前比较好的应用有TSO，逻辑时钟，HLC，True Time etc.。HLC既能通过逻辑时钟部分的设计来减少对中心化授时的需求，也能对所有的时间戳进行排序，目前几乎所有的时钟设计都是逻辑+物理。True Time是从硬件层面做到误差控制。

总的来说事务这个领域理论的创新还是非常难，上面说的都是已有的方案，并没有什么新鲜东西。原子钟上云之后，是否能为业界提供更好的架构思路？值得探讨。

优化(39:49)

我一直觉得优化器是整个数据库工程难度最大的部分之一。在分布式架构下，这种查询优化变得更加难了，分布式查询器有了无限的改进空间。

根据Guoliang老师的说法，在分布式的环境下了，传统单机的分析方法很可能不适用了：不同节点数据交互要考虑网络因素，A,B上２个表要join，是A传给B好呢，还是B传给A好？越复杂的分析，网络交互就越多，也越难以分析。

高可用(41:18)

这一部分主要是业界研究的比较多，学术界因为没有相关场景所以比较难做。 数据库做高可用主要有这么几种办法：硬件冗余(多台机器，比如主备)

软件冗余(多副本，两地三中心，异地多活，数据复制)

自动诊断，预测(用机器学习的办法来监控数据库应用的情况，及时做调整)

感觉这个领域也没有什么新东西。比较新的概念就是SDDB(Self-Driving Database)，大概就是收集数据库当前运行的性能指标，然后做一些自动化的参数调整之类的东西，比如阿里在VLDB发的这篇，就是根据当前workload调整buffer size:http://www.vldb.org/pvldb/vol12/p1221-tan.pdf​www.vldb.org

以前这玩意是DBA手动调的。

硬件对数据库系统设计的影响

硬件一直在影响着数据库的设计。想想我们为什么会有WAL？是为了把随机写开销化成顺序写。

为什么会有buffer pool？为了写操作和读操作更加迅速。

为什么我们要用Page作为B+ Tree的节点单位？为了简化磁盘读取方式。

为什么Wisckey火了？因为SSD的大规模使用，使得LSM的架构可以有更好的设计。

新的硬件出现，势必会影响数据库的设计，而这带来了新的研究热点。

CPU(44:03)

目前由于硬件的限制，机器单核能力提升不大，不过数量越来越多。以后的时代，我们要面对的计算环境，很有可能是几千个CPU。多核CPU反而带来性能下降，因为不同的核会争抢相同数据资源。比如NUMA架构下如何管理多核对同一块内存区域的访问是一个重要问题，因此如何控制对同一块数据资源的并发问题，或者说设计一个在重核情况下的新的并发控制的算法，就显得尤为重要。

NVM(49:08)插播相关硬件科普：闪存分很多种，其中一种叫做NAND闪存。NAND闪存在U盘，存储卡，固态硬盘上都可以看到。U盘和SSD=控制器+闪存，而影响闪存速度的主要是是控制器的性能。比如同为闪存存储，SSD性能高于U盘，主要靠的不是材料方面的优越性而是控制器的实现。

3D Xpoint就是一种NVM技术，Intel基于这个技术提出了Optane，美光科技提出了QuantX。而且是ByteAddressable的。ByteAddressable这个概念+ NVM和普通NAND的读写差异，给了数据库研究人员很多想象空间。比如之前我往磁盘上读写的时候用的是Page，现在有了和内存一样的ByteAddressable功能，那我可不可以换成Record？降低数据粒度。

而且因为NVM的出现，我们也可以思考存储器的架构，比如Memory -> NVM -> Disk这样新的存储架构，就会带来新的思考点：Log要不要放NVM？RTO会不会快很多？

Index要不要放NVM？索引会不会快很多？

传统的Write Ahead Log是不是要换成Write Back Log?

Network(55:49)

RDMA，直接访问对方内存(Bypass CPU)。这项技术是分布式领域非常关键的技术，它又会带来哪些新研究方向呢？事务。2PC避免不了网络交互，RDMA能极快提升事务处理能力，也给了新的事务处理模型想象空间。

Offloading。把某些计算任务扔给其他硬件完成，解放CPU，不被频繁中断。

Programmable。网卡上直接通过编程的方法做条件过滤(不需要CPU参与，提高处理速度)

Protocol。替换传统的，比较笨重的TCP/IP协议。

云原生数据库新趋势

云原生数据库里面曾经最火的明星产品可以说是Amazon的Aurora。它的细节这里不讲，有兴趣可以看看另一篇文章。它的主要设计理念是降低I/O，异步写Page，并且把这个task offload到内部存储系统。存储计算解耦，可以做到分层扩容。比如说计算节点增加500个，存储节点只增加100个，按需分配。

云原生数据库有几个研究点:Near Data Processing。既然存储计算完全分离，这会加重一些新的问题，比如查询得到的大量数据，如果不在存储层进行处理，而是全部传输给计算节点，这会极大地浪费网络I/O。因此，现在计算分离的架构里面，通常都会有模块做算子的下推。TiKV里负责下推的是Coprocessor模块。这方面的难点是，底层的KV存储没有完整的关系表信息，因此在做一些优化的时候无能为力。

支持多写。在云原生数据库里支持多写是比较难的一件事情，比如Aurora就不支持(更新：是一开始的架构不支持，现在支持)。新的PolarDB是支持的。

内存虚拟化。把内存做高可用，通过RDMA连接。这个可以联想到PolarDB 1.0。背后的大理念是资源池化。以前单体的时候，所有数据库kernel都在一台机器上，现在抽离每个部分并且做成一个资源池，方便上云。资源池的优势是封装了low level的细节，通过相关资源调度算法达到高效率的利用率。

这些也不是比较新鲜的研究问题了，业界已经开始大规模做了。个人思考，数据库+k8s是不是一个研究方向呢？虽然说k8s的设计初衷是运行无状态运用，但是如果能管理状态的话，那么可以说就是使得云上应用更加规范化了。这个方向还是比较有争议的，大多数难点还是工程上的，从学术的角度发文章可能比较难。

总结

这份报告还是比较有研究价值的。我只不过截取了一些我自己听得懂的点，多听几遍就会觉得讲的还是比较泛，需要自己去深挖各个方向。