数据库精选论文解读，透视未来技术趋势原创

好，各位同学下午好，嗯，那我们今天的下午的这个直播活动就正式开始，我是中国人民大学信息学院的柴云鹏，很感谢腾讯的邀请和组织哈，我们今天下午来进行呃，DB洞见系列的直播，第一期数据库精选论文解读，呃，然后今天呢，我们主要是邀请到两位嘉宾，一个我来介绍呢，就是NVM原生数据库相关的一些呃主题，然后第二位嘉宾是来自腾讯的朱月岸老师，他分享的主题是h tap系统的问题与主义之争，然后我们重点是以这个VLDB2021的一系列的优秀论文的解读作为主要的线索哈，来讨论一下现在数据库领域正比较活跃的一些技术，也透视一下未来技术发展的趋势，讨嗯，首先简单介绍一下自己，是我叫柴云鹏，是现在是在中国人民大学信息学院工作，呃，然后这些年一直都是做计算机系统方面的研究。

就呃，现在主要是关注像这种分布式的数据库系统啊，还有存储系统，云计算的系统，尤其是像这种软硬件协同的一些优化的工作，这跟我今天分享的题目也比较相关，主要是现在比较呃，新的这种NVM设备出来之后，然后在数据库系统当中会有哪些的变化。这是我今天的主题，就叫NVM原生数据库技术。嗯，今天我的分享呢，主要就分这三个大的部分吧，首先就是简单的介绍一下NVM原生数据库整体的情况，呃，然后包括还有一篇很很好的一个论文，就是这样，硬件特征，包括现在的和未来的发展的情况做了一定的分析和预测，然后第二部分呢，是重点的就是说现在，呃，NVM原生数据库现在确实还很少有这个产品，目前的研究呢，还是针对它的一些核心技术的方便面展开的一些研究，呃，我正好是找了这个VDB2021的四篇论文吧，是正好是在这三个方面，一个是索引啊，一个是日志和恢复，还有一个是混合内存，这三个方面也是他现在最主流研究最活跃的三个方面进行一定的分享。

最后呢，进行总结和思考。然后今天讲的这个论文呢，主要涉及到LDB2021的这五篇论文，一会儿后面都会详细的来阐述。首先第一个就是呃，整体上NVM数据库它到底发展现在是个什么情况，有什么优势？呃，我们可以先从现有的这个数据库系统的情况来简单的分类讨论一下，就数据库大家都知道，就是你可以分成啊，T pap啊，现在包括流行的这个HP啊也是比较活跃的，那从TP来看呢，传统上一直都是磁盘数据库，包括到现在是SSD，很多地方都是SSD为主的，但还是磁盘数据库的软件技术，然后从早期的这种单机的架构发展到分布式，一开始的主从到现在存算分离的这样的很多的，呃，优秀的数据库产品发展的都是非是最快的这么一个领域。然后另外一个分支呢，就是比较高端的内存数据库，或者像一体机这样，典型的就是哈拿的这种系统。

嗯，但这种呢，就是呃磁盘和内存数据库它的产品的两条线，实际上呃分裂的是比较厉害的，定位的场景，价格，容量各方面差距是很大的，然后像NVM的出现呢，实际是正好是在介于内存和磁盘中间，所以他对这现有的这些数据库系统本身就有很大的影响，然后甚至也能酝酿出来新的这种产品的形式啊，所以确实是可能会对未来呃若干年内这个数据库产品形态影响比较大的一种技术。然后AP的方面也是类似的，就是传统一般因为大数据分析的量比较大，还是基于这种磁盘呃为主，然后少量的内存或者GPU的这种数据库呢，速度特别快，但是它的数据规模特别小，所以实际它的使用的范围也并不是特别的大。然后h tap数据库也是类似的哈，就是传统都是磁盘和呃内存两两种介质，然后现在新兴的这种非师内存，那volatile memory它是什么样的一个情况呢？就是说过去实际很多年发展的是比较快的。

然后像这个PCM啊，相变存储器，这个可能是发展最快的，现在英特尔出的这个产品呢，就是它自己叫做3DS point，但实际上呢，一般大家也推测，基本上都是属于PCM相对比较储，然后另外还有一些像STTMRAM，利用电子自学来存储的，还有一些RRAM1组器啊等等，也都在发展当中，可能在过一些年会陆续的去问世。所以NVM实际上它严格来讲，它不是指的是一种介质，它是一系列的介质，那这些戒指实际上它们之间有很大的差别，但是在真正量产值之前呢，实际大家很难去说，因为在小规模验证的时候性能都很好，像PCM小规模的时候说可以达到DM的性能，但实际现在是远远低于DM，是在这个他们俩之间的这样的一个中间层，STMRAM自己，呃，现在说的是定位在这个，呃SRAM定位在缓存的这一级，但是真正量产之后，是不是还会下降到这个DRAM这一层，也还是挺有可能的。然后这个产品呢，在。

一九年的时候才真正推出这个，呃，内存接口就是DM接口的这种NVM的产品是英特尔推出来的，呃，这个，但是在这个之前的几年，实际上有一些研究，就拿内存去做模拟啊，这个研究上是有很多，但真正大家重视呢，还是从一九年这个真正的产品量化以后才会好一些，呃，然后现在呢，这个后来也有第二代的产品，但是第二代实际是有一些问题，所以呢，一直出来了原型，在英特尔也做了一定范围内的试用，但是一直还没有正式的去推，现在目前市面上还是第一代。然后它呢，从性质上来看呢，确实是介于两者之间，性能，成本，容量，存储密度，然后它的另外一个很大的一个好处就是接近于DMM是按位访问的啊，当然实际上是按照catchline的力度来去访问的，但是这个一会后面会讲，它这个PCM内部还是有一个写放大，最小的力度一般还是256B。

所以呢，就是NVM的这种介质，如果逐渐的成熟，成本甚至再降低一些，它对整个数据库产品还是有很大的意义的。首先呢，就是说我们可以基于呃，现在的内存数据库，或者是在重新去定制这种NVM原生的数据库，它可以达到接近呃，或者达到内存数据库性能，这样内存数据库这样的性能，而且可以扩展内存空间达到一个数量级左右，然后降低成本，然后像以前olaptp或者HTP当中，传统用内存的这部分，它的成本可能确实很高，现在就可以明显的降下来，数据规模也可以上的去，就做的更实用，所以大家就是给予厚望啊。但是这个也带来了很多挑战，就是因为它是一种全新的东西，它既向内存又向外存，呃，你可以当成内存去用，但是呢，这个现在又不能直接去保证持久化，还要加一些额外的汇编指令才能真正保证持久化，也把不能把它完全当成外存，又好像浪费了它的一些属性。所以这种情况下怎么。

去用它，而且它的这个硬件特性，实际上从SSD开始，这些年新出的各种存储性硬件，它的特性都是很强的，换句话说就是有很多的缺点，不是一个很完美的，像内存或者磁盘这样，比如说读写都是对称的，它的特性比较规范，比较简单，现在新的介质，它的访问力度啊，它的并发度啊，然后各个方面都会有很多的限制，你只有符合它的限制，性能才能比较好，所以这个怎么去用也是比以前要复杂很多。然后数据库传统当中各个核心的模块是研究了几十年，也有很多产品，但是到了NVM是不是还要有很多模块是要重新设计，影响会很大。所以这个都是呃它的一个问题，然后目前现在他的研究还是属于一个模块化的阶段，还没有一个真正说比较大规模，比较实用的产品，有少量的一些论文里边会做一些原型，但是实际上是原型的原型，就是还不算是一个很完整的一个数据库的原型，它还是一些呃研究性的一些东西在逐渐的拓展吧，但是应该还是会呃未来的几年就很快会有一些呃相对规范完整的一些数据库的NM系统。

呃，目前的研究主要集中在这么几个方面，就是研究最火的实际就是索引，这个是在NVM设备出来之前，实际就开始在做这个索引里边呢，就是几几大类吧，就是比较快速的基于哈希索引，呃，这个一会后面有一篇论文，正好会做一个详细的测评，还是挺有意思的，然后但是他不支持范围查询，所以数据库里边一般还是这种有序所引，呃呃，用B数基于B数变形的这种比较多，这个是很很经典的，从大概一四年左右就开始有很多好的论文，这方这几些论文都是很经典的文章。然后还有一些呢，就是呃，基于前缀数来做，前缀数也有自己的一些优势，跟B数还不太一样。然后另外就是SML，就是日志合并数，这个也确实在存储KV这个领域用的很火，包括现在RODB呃，很多的数据库系统底层也都用，呃，但是传统一般大家都从原理上讲它不是很适合NVM，呃所以像这种B数啊，这种前缀数啊，这种还是更主流，但是因为SM Mo确实有它的优势，比如说它的写操作比较好啊的连续性啊，然后是NVM的特性又没有想象当中那么接近于内存，它的连续和随机写之间差别也很大，所以慢慢的就是很多人也开始在做SL tree的NVM化啊，或者说混合存储，就是把呃，SSDNVM可能都加到这个里面，做成一个，呃，更大容量的，但是呢，性能又比SID的那种引擎要好很多的这样的一些索引，当然这个可能很多是偏存储的研究，还有一种就是混合索引，就是我用DRAM加上NVM，它们之间怎么去配合可能。

是多个索引，也可能是一种拼接索引啊，这个现在不是特别主流，但还是也有一些工作，主要的原因就是因为DM还是性能远远好于NVM，没有NVM没有想象的好，所以这个混合还是有意义的，有一定的意义的。然后第二个呢，就是像这个空间的分配啊，因为NVM它跟一会后面讲的时候会详细阐述吧，它跟DM有很大差别，它会多了一个空间分配的开销。再一个就是日志和恢复，因为本身就是关于这个持久化的，所以这方面NVM它的访问啊，它的这种一种介质，既可以持久化，可以非持久化，然后它会带来很大差别，所以像这里面有一些经典的论文，像WBL，还有一会今天分享的这个Z都是这方面的文章，然后再就是缓冲区，也有一些关于这种混合缓冲区的，就既可以当日志，又可以账号缓存，呃，有一些少量的研究吧，呃，不是特别主流，所以这个关于这个方面数据库NVM数据库的这个研究主要是这么几。

类，呃，还不是特别的完完善，目前还是属于一个不是很成熟的阶段。

然后我们第二点呢，主要就是先借着这篇VLDB2021的这个论文，他实际是想介绍一下现在的这种NVM产品，还有畅想一下呃，未来的NVM或者是其他类型的NVM，如果出来或者发展几年之后，它的特性有哪些，哪些实际上是共性的，哪些实际上是现在英特尔这个产品独有的，哪些是因为什么机制带来的，会长期存在还是短期存在啊，这个还是挺有意思的一个论文，还是值得一看，呃这个呃里边首先是列了一些NVM的硬件的特性，这个很多论文，包括我们自己也去做过一些测试，就是大家的结果大同小异，所以还是挺呃挺广泛认可的这样的一个一些结论吧。比如说第一个就是读写它的性能，包括延迟和带宽都是非对称的，这个实际上就是从呃，前面说从flash开始就一直都是这样。

然后这个跟内存还是有很大的差别，然后它的这个可能差别会更大一些，呃，然后小力度IO的这个访问带宽比较差啊，这个也是传统上一般小力度都不是很好，它这个里边更明显一些，就是有一个256B的限制，就是小于256B的呢，因为有读写的放大，所以性能是比较差的，所以不推荐。呃，比这个小的一些力度的访问，主要是因为在访问的时候，就是我们虽然是按照64B的力度，但是它的这个硬件里边，控制器下面实际它是有一个叫SP buffer，这个大小是256B，然后它所有的东西都会对齐到256B，所以这里边小力度会有一个放大。第三个呢，就是顺序访问比随机访问快啊，这个倒是大家都是差不多的，呃，第四个就是new马的影响更大，这个确实是比想象的大，这个我们自己也做过一些测试，影响非常的大，就是D的码访问会下降性能，但是没有那么明显，但是NVM的访问实际上性能下降是非常明显的。然后第五点呢，是有一点反常识了，就是我正常去往这个CPU里边去写数据，做store指令的时候啊，实际上是一般来说是比你要去去这个做flash要快，Flash指的就是你从缓存里边要清出来，还要再写到内存里边，这样你还多了一步，因为正常到可能你写到缓存那边就行了，所以正常我们都是理解stop比较快，但是这里边他发现有的时候实际上是加上flash会更快，这个后面会解释是有一点反常是。

最后一点呢，就是它的并发度实际上是有一个比较大的限制的，就是内存它能够支持的最好的，最佳的并发度的数量是比较大的，你用更多的并发，它的性能会更好，但是像NVM它就不是这样，就是嗯，读和写它的最佳并发度实际不太一样。然后呃，这里边呢，这篇论文总结了这么七个特征，然后呢是简单的介绍了一下它的这个特征，以及它的主要的原因，还有就是适应哪几类，呃，NVM的类型，这里边我们可以先看一下，这里的C4实际上指的就是现在这个实际的产品，英特尔的这个产品，然后C1指的是比较早的一个，就是上面去接电池的，但是它的存储介质实际还是DMM的这种，然后二和三实际是假想的，就是假设有一些产品，它一直是用了一些catch，还有一些预取器，然后C3呢，就是假设跟C4类似，也是有一种这个访问力度的，呃，不匹配，然后假设这种情情况下，看一下各个特征是不是对每一类都适用，第一类就是刚才说的第一，前两类实际就是读写的呃，不平衡呃，Load和stop，这个stop指的就是持久化的p store，他们的延迟和带宽都不匹配，但这个原因实际上主要是介质的原因，就是最大的原因是介质，介质原因就我们现在用的3DS point或者PCM，实际上。

他就是读快写慢的。第二个就是呃，它这个延迟跟CPU的缓存有很大的影响，所以它对这一类实际上都是有影响的，然后第二个带宽的话呢，就是除了这个介质的原因之外呢，实际上它的这个控制器相关的这些征用啊，它有一些资源实际还是会也有一些影响。

大家可以看一下这个数据，像DM的话，读的带宽是能到76G，呃，这个写的带宽是42G，是有一定差别，但是不是很大，然后到了NVM的话，读就是30G，写大概是8G，然后所以这个差别就会很大，是2.5倍和5.2倍的差别，所以这个它的读写的差异的放大，呃是到了这个NVM上比内存要放大了很多。第三个就是这个小力度的这个访问，随机访问不是很好，连随机访问那个连续访问比较好，然后以及大块访问比较好，这个就是前面说的这个SP buffer，它这个大小实际上呃，256B会导致解放大，另外一个就是它也有预取器，所以连续访问会比较好。然后这是这几方面，另外还有一个我们测试，还有之前的论文也提到，就是说你恰好是做4KB的访问，实际也不是很好，就是它大概的访问力度就从小到大，到性能带宽应该是逐渐提高的，到256B之后基本就比较稳定，但是到4K呢，一般会有一个下滑，然后在后面是基本上比较稳定，就到4K，比较差的原因实际是它内部，它还有一个就是多条，这一般是一个CPU和一个CPU实际对应这边是六条，可以放六条NVM，然后它会做一个类似像RA的那种并行化啊，一个inter，然后这个力度是4K，如果你都是4K，可能很多会负载不均衡，很多访问会在某一个通道上，而其他通道上会显，所以可能会有更多的负载不均衡，性能会有一些下滑。

呃，然后第四点就是newma比较差，这两个图就是这篇论文里做的测试，上面是内存的newma访问和普通访问之间的性能的差异，下面是NVM的这个颜色，绿色的表示的就是差异不大，越深越蓝，呃，这个差异越大说明newma访问越差，你可以看到这个颜色明显看到DM的差异没有那么大，到到了new马的NVM上面，这个newma访问实际变得就会非常的差，那这个原因呢，前面也说了，就是说主要就是呃这个它之间的这个连接实际上比URA要差，所以它的这个new码访问限制会更差一点，当然也有可能是它一些，呃，硬件第一代产品不是很成熟的，这个原因也许后面会做一些修复，但目前看确实是非常的明显。然后还有一个就是跟预取器相关，就是你在本地访问，这种取还是起到很大作用，但是越往后呃，女马的话就越不行，而且这类是基本上比较普适，呃，这类都是有这个影响。

然后再一个第五点呢，就是前面说的反常识的，就是有的时候store的带宽实际上是比p store比那种持久化的store还要再小，因正常来讲都是store要快一点，这是它的测试结果，实际上这个稍微我觉得结论有点夸张，就这里边的呃值，这个值正负实际指的是store性能减pto的性能，呃，所以呢，就是实际上这个负数的部分，实际上指的就是负数的部分，实际上就是store指能比较差，然后但是实际上可以看到只有少量的情况下才会有这个负数，大部分情况下实际还是P到会更差一点，它只是说一个比较小的范围，所以我感觉可能不是特别大的一个影响大范围的一个特性。

再一个第六点就是连续快比随机快，这个是比较容易理解的，第七点呢，就是它的目前现在的实现，这篇论文认为实现的还就是这个硬件做的不是很好，就是他的pto，实际上是RMW的这种transaction，就是他每一次呢，都是要写到这个中间，利用中间的那个buff分嘛，256B，而且这个buff分实际不需要满，它只要你去填充数据，要往下写了，它就会先把数据读上来，然后修改了之后就写下去，所以中间这个过程实际上呃，策略上没有做什么太多的优化，所以这个可能将来以后的产品可能会有一些改进，就目前只有C4，也就是当前这一代可能影响会比较大，在这个实际很难，就是你去预测硬件的趋势，这篇做的也不能说是非常的非常的完备，但是确实还是提了几个点，也把它整理的很好，所以还是如果要做这方面的研究，还是值得去看，他也给了一些建议，比如说像你怎么要避免一些呃，持久化的。

且尽量普通的stop，实际还是要更快一些，然后你不要太多的并发，要适度的并发，按照硬件的特征去并发，然后要避免特别小的，还有然后牛马访问要限制。啊，然后这个是就不太详细说了，这个这个可能范围不是很大，然后尽量避免随机IO，然后这个硬件的设计上，还有就是尽量避免一些transaction之类的，这个说实话都是比较容易理解的，但是实际的软件系统最难的一会儿看到后面的一些，呃，系统设计可以看到是最难的还是在实际系统当中怎么去用好这些特性。

不是特别的容易。然后第二个方面我们来讲一下这三方面的核心技术，呃，第一个呢是索引方面，索引方面前面说了，实际这方面的研究是最多的，而且最主流的是基于像呃B加树B术，或者是像前椎术这样树形结构有序索引的，这个对数据库来说也可能会更重要一些。呃，然后VLDB2021呢，这方面可能没有太合适的文章，因为这个工作确实现在不是很活跃了，就是前几年做的比较多，他们大体的研究基本都是呃思路就是树形结构里边，比如说最下面一层我放到NVM里边，然后前面的这些我中间结构，中间节点放在DM里边，这样的话减少一些NM的写入，恢复的时候呢，我可以通过最下面一层再把上面恢复出来，所以很多都是用到了这样的一些呃技巧，然后还有一些小的一些一些一些技巧吧，后面也有总结，就是利用这些能够减少写来提升性能，但是这方面的研究现在可能不是特别特别的多了，特别活跃。

然后哈希呢，这两年做的人还是蛮多，所以这篇实际也是做了一个呃，NVM上面的持久所内存上面哈希索引的一个比较全面的一个测评，他选了六种比较常见的，比较新的一些结构，这个level哈西clever，呃，Clever，然后CC eh DA PC HT，还有soft这样的六个索引，我们先来把这六种的技术简单的介绍一下哈，这方面我不是特别关注哈希，因为它可能没法支持范围查询，所以我们之前可能呃基本上都是关注内容有序索引多一些，这边我们简单给大家介绍一下，首先这个level哈希和这个clever哈希，他们实际上是一系列的工作，应该都是华科的那个华语老师他们团队呃做的，然后他最大的这个特征，实际上就是解决哈希冲突的方法，减少这个冲突，它就是说最上面这个top这一层是正常的去放通，然后呢，我每两个后面可以加一个bottom这一层的。

桶，那这个的好处就是一开始下面这个桶是空的，但你上面这两个桶一开始往里面去放，但是你们一旦去冲突了，就可以利用下面的这个桶往里放，然后因为冲突的情况不是特别的频繁，所以它的容量就是比上面正常top层的要少一半，所以而且呢，关键就是两边左右两个分支都可以来共用这样的一个结构，所以它从空间利用上，还有这个呃，减小哈希冲突的开销上，起到了一个trade off的作用，这还是挺有特点的一个设计，后面的clever好像应该是层次更多，可能还有更深的层次和动态的决定的，这种多层的结构是属于类似的，然后上面它也用了这种布谷，布谷鸟哈希有两个哈希减少这个，尽可能的减少去冲突，然后还设计了一些比如说像lock free，还有呃呃这种slot级别的锁之类的，来去优化它的性能。

然后第二个呢，CC eh这个是FAST19的一个工作啊，是跟这个catchline相关的，这样的一个可扩展的索引，就是传统的这种历史上这种tenable的哈希呢，实际上是有一些，呃，已有的工作，它的架构都是这种，这个有目录，然后再连到下面的数据，但传统的这种结构呢，就是它的指针比较多，但指针这个东西呢，在这个NVM上面实际不是很友好，就是它指针的更新是比较小力度的，然后随机写，然后可能数据量不大，但是对NM的开销比较大，所以这个传统的结构不是太适合NM，所以它做了一个比较大的改进，就是改了，改成一个实际上是更简单的结构。就是三层的结构，Directory，然后到了segment到bucket，就这里边的这个大的这个就是segment，然后里边再一行一行的，就是一个个的bucket。然后呢，它每一个key里边，它通过最前面的这部分来去确定是哪一个segment，通过后面来去确定这个bucket，大概是这么一个很简单的一个结构，然后他去解决哈希冲突呢，实际最原始的版本就是当你冲突的时候，我把segment只要再翻倍，再扩大一个，呃，这个segment，这样的话就是第二个冲突的就可以写到这个后面新的这个segment里面，然后所以这种来去叫extendable，就是它可以很灵活的去扩展哈希表的这个空间，但是如果你直接去用也有个问题，就是你呃，就为了一个bucket的冲突，你去扩展segment，那这个segment上下有很多是空置的，你平均算下来这个空间利用率是很低的，所以它这里边也做了一些改进，就是先去做这种线性的探测，尽可能提高segment里边的这个空间利用率，实在不行的话再去做扩展，然后也有一些lazy的策略来减少它的开销，所以这也是一个比较有代表性的一个工作。

然后但是呢，这个是VDB20的一个工作，他跟这个CCH是比较接近的，但是他觉得CCH的这个空间利用率不行，就还是有点有点低，所以他做了一个改进，它主要是提了三个技术，第一个叫balance的insert，第二个是ment，第三个是呃，Stash，这个第一个呢，它指的就是说我每次插入的位置实际上是有多个位置，有点像布谷哈希一样，就是我可以有多个选择，这样的话我冲突的概率就低了。然后第二个呢，就是说如果我这两个都满了，那其他的人是不是可以，因为每个人都有两个选择，他就可以做调整，这个跟布谷哈西是很像的，所以这样就减少一些冲突。然后第三个就是他最后还有两个隐藏的这样的空间，然后如果你这一个segment里边实在是没有地方调不开了，那我就可以利用这个隐藏的空间来去存，所以这个在一定程度上也可以减少这个segment再扩展的这种频率，这样每个segment可以压的相对更实一点，提高它的这个。

空间利用率后面的实验结果我也可以看出来，确实它这方面是比CC要强，呃，然后后两种我就没有特别仔细了解，就是这两个实际上都是这种链式的哈希表，然后这个是链式的并发的哈希，然后他原来也有这个呃，DM的版本，然后后面去做了一个NVM的改进，包括对这个catch的友好原子性的访问等等，然后这边soft也有一个特点，就是它实际上是比较特殊的一个，就是它际上有VM的部分，也有这个呃，NNVM的部分，Pno的，就是它的数据实际是在这两边都会存，呃，然后如果是需要持久化的时候再更新到pno的，所以这个比较特殊的这样一个下面有些特性的总结，这个时间关系我就不详细说了，看一下它的这个测评的结果。

就是这个图可以看左边是uniform分布，右边是这种倾斜分布，看倾斜的就可以了，然后这中间的这两个是读的情况，这边是insert，可以看成写的情况，就正常来讲这个呃，读的操作实际还是这个链式的，这个pch它的性能是相对比较好的，这里面比较突出，然后这里面是多个索引都不错，就包括这两个链式的，再加上这个CCH，相对性能都比较好。然后写的方面呢，是这个呃，Soft c ch比较好。写的性能的影响呢，就是一个是际上是PM的写放大，就是一会后面可以看到这个每一个索引，实际上它跟原始的写写操作比起来，写放大都很多，当然有的会好很多，然后这个写放大的多少直接影响到它的性能啊，包括REC，当你的空间不够的时候，怎么来去放大这个空间啊，然后这是下面是一些多线程的操作，就是整体来看还是这个会是各种情况下相对比较好的。

然后像CCH啊，还有啊，这些也确实都是比较优秀的。然后这个值是内存利用率的，可以看到这个，但前面我们说它也是基于CCH做了一个空间的改进，确实是最优的啊，大概是这样的一个情况，然后这个图中间这个图是它的PM写放大，这个比较有意思，就是这个最下面这个灰色的是它原始的写入，然后其他的都是放大出来的，所以很清楚看到谁放大的比较多，放大的少的话，那你的性能像这个soft，刚才说的还有CCH这两个写放大比较少，所以它的性能也确实是比较好，然后这个是恢复时间，就大家差不了太多，就只有像这个soft是有点差，就这方面是它典型的这个劣势，而且soft没法扩展，所以这个现在目前看还不是特别实用，但是还是有几个索引是很好。

但总的来说呢，就是这篇文章也总结了几些一些经验，虽然不一定都是，呃，就是大家不一定都做哈希，但是它有些还是更广泛的范围内都是有效的。第一个就是小力度随机写肯定是影响它的主要因素。第二个就是不同的，这个他也试过不同的硬件的指令，比如说有CL WB CL flash op BT等等，还有SSMS这些指令，呃，实际你去选择不同的指令，影响不是特别大，不是特别重要。然后再一个就是经常，所以你用的fingerpri的技术还是挺有效的，呃，然后这个对并行度是有影响的，所以会影响性能，然后像这些索引会这种动态扩展会比较好。再一个就是说内存，内存的分配器同步远于它的写放大，影响也比较大。再就是混合内存比较重要，就是这里面的DM实际上还是实际产品当中是远远比NVM要快的，所以怎么用好内存实际上是非常重要的，这也是我们的观点，包括后面Z也是这样的一个观点，就是尽量去多用DM。

才能得到一个比较满意的性能。再一个就是有一些，所以它的扩展性不是很好，随着这个硬件带宽的这个通道的增加，它并没有很好的利用起来，还有就是认为NVM现在的微观设计还是有问题，将来实际这一块还是应该要改改掉。呃，这是第一个大的部分，第二个部分呢，我们来介绍一下这个日志部分，日志大家都熟悉，就传统的都是WW，实际它的好处还是很多，第一个就是更好的利用这个buffer，第二个就是我们写入设备，实际是一个主要是一个连续写，呃，所以性能还是不错的，但主要的缺点就是数据和日志要写两遍，所以这个会有一定的开销。

然后这方面之前比较经典的一个工作就是VLDB16做的这个WBL。它跟waal是很相反的，两两种很典型的技术，它最大的一个诉求实际上就是我写一遍，我不要写两遍，那怎么写一遍呢？就是我日志缩的很小，日志只有一些很原原信息，一些时间戳的信息，而数据不用放在日志里面了，那数据怎么办呢？就是数据我多版本，我直接写到下面的持久化的设备里面，就这里边是上面是volaile，下面是durable的位置，这个是日志，这个是它的数据，所以他实际上是写完buffer之后，先写这个数据，当然是MVCC的方式去去写，然后当这个数据写完了，就是当一个数要提交的时候，他保证是一定是写到数据表里面去，然后这时候事务才能提交，当然也要补充一些额外的一些日志，所以他做的还是挺有特点的，就是写放大是明显减少了。

嗯，然后带来更大的一个好处，就是因为数据一直都不是在日志里边，是在这个表里边，所以它的恢复极其的快，他不用扫这个数据，也不用去重构，所以它的恢复时间是基本上甚至忽略不计，就是速度是上百倍的，这个提升实际上是很好的一个方案。然后我们今天介绍的这两篇论文，尤其是第一篇Z重点介绍的，它实际上在事务这个日志和恢复这方面，实际是沿着WBL的思，但是还是会有一些新的东西，那这个Z这篇文章是呃，计算所的陈世明老师他们团队做的，呃，还是挺水平非常高的一篇论文，它主要针对的就是我们假设用NVM来构建LOLTP数据库，实际是面临了三个大的性能的挑战，也就是这三方面会带来性能的问题，第一个方面呢，就是原数据，Couple的原数据要频繁的进行修改，尤其是在事物之间的过程当中，为了进行并发控制，实际上有很多的这种原数据的修改，那传统一般我们把原数据要呃持久化保存到这个。

那这个持久化设备，比如像NVM里面，那你就要频繁的去修改NVM啊，这个带来的随机写，小丽的随机写是很多的，这个是很大的一个性能开销，第二个就刚才说的W的数据日志写两边的问题，第三个就是NVM的空间分配是有它特殊的问题。这个在这里稍微解释一下，就是DM的空间分配，实际为什么简单呢？就是当你DMM真正宕机之后，你去恢复的时候，实际你系统是从空的开始，然后从呃维度日志，你从日志里面去构建这个内存里的东西就可以了，所以它只需要去初始化，空的初始化就行了，但NVM里边它的这个数据是是非意识的，所以当它重启之后，实际上上面的数据还是要直接去用的，而不是要去播放一遍日志去重建的，所以这个时候你每一个分配出来的空间到底用没用，这些一定要把原数据搞清楚，要不然就会空间的泄露或者是出现不一致，所以它的实际上n vm space管理，你可以看到做K的，做存储的，做数据库的，做这方面的，他都要去关注这个问题，后面几篇文章很多都是要去自己去设计啊，这方面的空间管理，因为它带来的代价是有点大，然后这样就针对这三个问题提出来了三个策略或者三个系统的模块来分别去解决。

然后这篇文章还有一个比较好，就是他把这个NVM的数据库的架构实际上分成了这么，总归成这么几种啊，第一种就是基于传统的内存数据库，我给它扩展，比如说我有一部分NM空间去扩展这些内存的空间来当成NVM，因为可以当成这个意识的模式，还有一部分NVM的用来当成非译式的，它用来存checkpoint啊，存这个日志，这是一个挺典型的思路。然后再就刚才介绍的WBL，它基本上没有什么日志，主要都是在数据里边。然后第三个呢，是一会后面会再介绍一下，然后第四类就是他们这篇自己去提出来的，跟WBL是架构上还是有一些呃接近的。然后第一种它的这个思路实际挺简单，也能基于现有的内存数据库的代码进行继承和修改，还是挺好的，但是它有几个缺点，第一个缺点就是它有三份重复写，也就是除了传统wal还有写checkpoint的写数据这两个部分以外，然后volatile的NVM它也充当DM的角色。但是它的写。

实际上是比DM要慢的，所以一个数据可能先要写到这里边，然后再写到日志里边再去裁，就这个总的来说它的写放大会更严重，第二个就是说你的数据规模在增大的时候，实际上DMM起的作用是越来越小，主要还是NVM来起作用，所以它的性能实际上是也会下降，随着使用在下降，由NVM来去制约，呃，然后WBL，实际上是刚才介绍实际还是很好的一个方案，解决了写放大的这个作用，但是他没有解决这个像原数据啊这样的一些问题，还有一些其他的问题，然后第三个呢，这个实际上它还是WL，它就是。稍微的变了一下，就是每一个数据它有两个指针，一个指向了内存里的page catch，一个是指向了NVM当中的一个快照，然后数据看catch里有的就从这读，没有的就从快照里读，然后后面再定期清理，但是从日志的角度还是WL，后面的实验也可以看到，就是它的性能实际相对是比较差的，呃，这是Z的架构啊，我就直接来介绍他的几个技术哈，呃，第一个实际上就是他怎么来去，很很重要的一个思想，就是它做了一个叫ma catch in dmm，就是要怎么尽可能的把DMM的性能用好。DMM你可以看到它的索引首先就是不持久化的，全在DMM里边的，然后它的很多原数据也都是在这里边的，包括一些分配器的原数据啊等等，然后还有一个很大的内存缓存，然后尽量把内存的空间用嘛，全都用到做缓存NVM里面只存少量的原数据，还有我们正常的这个表是用它的这样的形式来存的，所以第一个叫ma catch，实际它就是尽量充分的去缓存，而且。

前面说的就是一些原，呃，他的一些原数据，在并发控制过程当中用到的一些原数据的修改，实际上都可以在这个内存里面进行，所以这样性能就会好很多，减少很多NVM的写入。然后第二点就是这个它设计了每一条NVM的记录里面都有一个lp bit，它可能是零还是一，它的作用很重要，就是当你一个事物在提交的时候，实际你有多条记录，但是呢，我前面的每一条都是零，然后只有到最后一条的时候，它的LPP的才是一。这样的话，一个好处就是当你中间突然宕机的时候，然后如果我的最后一个事物发现，因为它这里面都有数号，然后你发现这个号只有零的，没有一的，说明这个数没有完成，那这条数据就干脆就当垃圾数据忽略不计就好了，但如果你发现这条事物有一的结束的，那说明前面的都写完了，那这时候自然就这个事物就是一个已经完成的事物，他就恢复的时候，就可以把这个当成一个提交的事物来做，所以这是他很大的一个呃特点怎么来去，所以。

通过这样的一个机制，就做成了一个log free的这样的一个结构，就这里面会说的时间关系，我就不不详细举这个例子了，大家感兴趣可以看论文。然后空间管理呢，这个我就不详细说了，就是它是分了两层，就是一个是配置级别的，按照固定大小来分，一个是给每一个tale来去分的，而且这个tale的实际上是不需要在NVM里面去保存原数据的，用DMM就行，也是尽量的原则都是怎么能尽量的用DM，然后其他的东西都是恢复来去做。

啊，但是实际上这个呃，Z的设计的思路是什么呢？就是他本质上就有点像，也是一种交换，就是他在恢复的时候做的事情比较多，他一定要扫整个的数据，而且扫一遍还不行，还要扫一遍多，优化之后要一遍多，然后但是像呃，WBL技术，实际上他可以做到基本上不用扫数据，所以它实际上也是一种交换，就是平时的性能，Runtime性能做到非常的接近极致，但是恢复性能按理说是会有一些影响，但是实际测试的结果一会儿看有点奇怪，不太一样，然后这里边绿色的实际是Z，可以看到它的性能确实是基本都是最好的，然后比较意外的实际就是这个红色的就是基于内存数据库的，它反而是第二位的，就比这个WBL和这个还是要性能要好一点，这个还是挺有意思的一个结论。

然后呢，这个是恢复的性能，你可以看到这个第一个方案确实恢复比较差，因为他要去做这个日志读取，然后再去做锐度，它有80多秒，而后两个方案都是个位数的秒，然后这里边的WBL实际按照它的原则是不需要去扫描的话，那就基本上呃是零点几秒，可能就是非常快的就能恢复，但是这里面因为它的索引也是要恢复的，也要扫一遍数据。所以呢，还是呃也是这样的，几秒的，其实然后then呢，是因为它的呃恢复更复杂一些，它除了扫一遍数据，确定哪些数已经提交之后，有一些还要再扫一些，再扫一部分数据，所以它的性能稍慢一点，但这里边呢，我觉得是有一个小小疑问，就是说它的数据规模实际还比较小，如果数据规模在更大，它的恢复性能，因为他把所有的开销基本都推到恢复了，那恢复是不是呃能做到还是这样的快，所以这个还是比较重要的一个问题。

然后第二篇呢，实际上也是日志方面的这个工作，呃，但是他做的实际不是数据库这个像Z那样数据库层面的，他实际上是在SML tree的这个层度去做这个日志，呃，这个我就简单的说一下，就是SML tree，大家如果了解就知道，就是它实际上在写的时候呢，也有一个日志，也有这个内存里的buffer，它为了提高性能，尽可能的数据先写到内存里边，然后慢慢的综合compion，再去持久化，再去写到下面，但是你为了保证安全性，你必须先写这个日志，那写日志的这个开销实际就是整个性能的瓶颈，所以它这里边就是把NVM加进去之后，首先最重要的就是把这个改成log free的结构，所以它对整个n v msml tree做了一个很大的改动，就变成一个log free的结构，性能就比较好，它大体的思路是什么呢？就是我把这个数据写到一开始这个chainlo里边，然后后面再经过这个SML trade的多层次的这个转移的时候，只是逻辑上去做，但是物理上这个。

这个数据写一次在NVM上只写一遍就可以了。然后后面的话就呃，不需要再去写，然后这里边跟日志相关，最相关的实际上是它下面的这个技术，就是它首先是数据库上面可能这个SM去上面可能是很多的transaction并行的在提交，那我们怎么做并发控制，他是不关心的，他关心的就是已经提交的时候怎么去持久化，那这时候有并行的大量的东西持久化呢，他为了让这个力度更大，所以他就会把它变成批次来写，这里边就分成一批一批的来写，那他每一批怎么能够保证log做到log free呢？实际上就是它记两个值，呃两个叫GIDX，就是全局的这个一个ID，然后一呢就是一号版本，22号版，33号版本，然后这个前面这个指呢，指的就是之前已经提交的一个正确的版本，后面这个就表示当前正在提交的版本，所以假设我们现在可以看这个例子，当前就是一二的状态，也就是前两个批次已经都提交了，现在正在提交第三个批次，第三个批次呢，前两个节点，前两个部分已经都第一个已经提交完了，第二。

和第三个还没提交完，但是后面这个节点就挂掉了，挂掉了之后在恢复的时候，实际上他就因为前面的这个这个地方是持久化的，他知道我正自己正在做二的过程当中出问题了，我只要回滚到这个，呃，这个上一个二就行了，然后前面这个因为失败了，我再回滚到前面这个二就可以了，前面这个就不用管了，所以它如有一部分更新到三，最后也可以回滚到二，所以不会保证不会出问题，而且整个过程中是不需要去呃写日志的。然后，而且这个它的结构上也是用了这种半持久化，就是中间的索引的部分，呃，是意识意识的，下面的部分是非非意式的，这样来减少NVM的一些操作，呃，细节我就不介绍了。然后呃，第三个方面就是混合内存的技术，我们在介绍一篇论文叫wiper啊，它也是做的这个KV的引擎啊，不是数据库的，但是也还是很优秀的一个论文，值得参考。这个就是我们前面说的，就是现在的NVM没有想象的快，之前的很多研究都是假设它跟内存是比较接近的，所以以前的一个观点就是我们尽量要去呃用NVM，然后呃就直接去写写，不要去做那种呃写放大，就是我先写DM，再写NVM，这样重复的写就会浪费，但实际上发现性能差别很大，所以还是要用好NVM，但最重要的问题就是呃，你也不是简单的把DM当成一个catch，那样也不够好，所以怎么去让这两者去分工，各做什么东西，实际上是一个很重要的一个问题，Per就是按照这样的一个思路来去做的，就是他的motivation是发现，呃，NVM的连续写还行，跟随跟这个D的差别没有那么大，而随机写差别就比较大，所以他就说呃，NVM咱不要，尽量不要随机。

写尽量要去连续写，所以它怎么个思呢，就是DMM里边呢，我放索引，因为索引有很多小力度的随机的更新啊，随机的这个主要是更新在NVM放肯定是效果不是很好，所以它DM索引我干脆就放弃了，我就直接放在这个DM里边，然后NPPMPM里面，里面主要就是把一些数据持久化的进行写入，而且尽量的是把它组织好之后连续的去写。

然后他把数据组织成4K对齐，用这样的一个形式，下面这个图就是呃，横着最大的这个是一个v block，它叫v block，然后小的4K的是微配置，然后对齐之后呢，数据是整个这样去写的，这样除了数据规整以外，它还有一个好处就是并行度的控制，就是我们前面说了，它的并行实际上不是特别的呃友好，就是你需要精心的设计才行，所以呢，就是它用的一个结构叫一个方法，叫uniform threat to deem distribution，就是尽量把线程用户线程均匀的分到各个M上，然后它的这个v block就直接对应到了下面的不同的六个dim口啊dem通道，所以呢，就是每一个呃，每一个用户直接写进去之后，他会尽量的都均匀在每一个通道上，拿到的这个并行度是差不多的，但是他没有做一个很好的控制，但是它尽可能的做到的均衡，从并行的角度也有一定的这个优化啊，然后里边也支持变长和定长的结构，那这里边还有一个值得呃。

呃，学习的一个小技巧，就是说也是很通用的一个东西，就是你怎么让NVM的这个原数据持久化的开销，尽量的带来的开销小呢？就是你一定要先写数据，再写原数据，而且保证你的原数据是最好是呃八字节之内的原子写，这样的话你就不需要WL了，就像他这个例子里边，我先去把数据写进去，这个写可能很大，没关系，你慢慢写，当你都写完了之后，我最后再把这个原数据，比如这里的一个bit从零改成一，那这个小bit肯定是呃原子写的，那如果你前面这个过程挂掉了，那你这个数据因为bit还没有set，所以大家知道这个数据是没写成功的，就甚至这个空间都没有分配出去，那我就可以直接下下次再用，如果我已经写完了一，那就说明上面的这个已经肯定是完成的，那通过这个技巧就可以减少很多这个开销，类似这种它会用很多这样的方式来去减少，所以viper的性能可以看到也还是非常非常优秀的。

嗯，那最后呢，我们就简单做一下总结哈，就是第一个呢，就是说我们觉得NVM的这个数据库，实际上可能因为这个硬件的一些特性，还是给未来的数据库发展可能还是带来很大的一个机会，那如果我们一定要去跟内存和磁盘数据库去对比的话，实际上它还是更接近于内存数据库，而不是磁盘数据库，就比如说你基于内存数据库去改实接比基于磁盘数据库要改很要好很多，当然也可以是像原生的，就是重新设计，可能会效果会更好，但这方面确实还没有一个很系统完善的系统级别的这样的一个实践，可能未来几年还是会有不同思路的这样的系统的出现，比如有的是拿现有系统改的，有的是完全重新来去构造的，第二个就是在很长的时间内的NVM的介质还是明显弱于DM的，起码现在目前因为只有英特尔在做这个NVM的产品，它的发展不会特别的快，还是一家来去决定迭代的收期你发现也会很长。所以。

这个可能是长期存在的一个特征，就像前面的z wiper，实际是很好的参考，怎么尽可能的把它内存用好，比如说很多索引研究，像之前说的B加数的索引，它都是把最下面去做持久化，上面去放在DM里边，但是实际上可能更好的方式是不是就是像他们前面用到的就是我就是用的DM来纯的DM来去做索引，那我现在只要只需要去在恢复的层面怎么去优化，尽可能的减少恢复的开销就可以了。然后再一个就是NVM数据库和内存数据库虽然接近，但还是有很大的差别，比如说这个，而且会带来很大的这个新的机会，比如说内存数据库很多空间是有限太受限的，它的场景和成本都是它的问题，NVM数据库它的存储密度成本要有有很大的优势，所以在很多的场合应该将来会有它的这个产品的这个位置的。第二个呢，就是内存数据库，实际它的日志持久化部分也是带来很大的性能的开销，NVM在这方面也还是能带来很大的提升，就即使是从内存数据库的优化角度，也能让内存数据库的性能会更好。

嗯。然后再一个就是在系统设计的角度，如果我们去做NVM的原生数据库，它跟内存数据库的设计还有很大的差别。第一个就是空间管理，前面说了它比DM要复杂，所以你必须要去考虑到空间管理，而且可能空间管理还要跟数据库的其他的部分去充分的去结合，可能效率才更高。第二个就是前面说的索引，就是索引到底是怎么来存，现在没有定论，但是我个人的观点实际是更倾向于呃，就是要用好DM就不一定都是唯一的，像Z他们那种形式，就是完全放在DMM里边，但是一定是呃，尽量的去以DMM为主，才有可能达到一个比较好的性能。然后日志和恢复方面呢，就是一般来说，现在前面也有一些比较成熟的，参考这几篇论文都不错，这种lock free的技术还是很多的，但是实际上这里面没有展开讲，就是像WBLZ，还有这些工作，它都是trade off，就是在读性能、写性能，还有恢复速度，这三者之间选择不同的平衡点，可能也没有说哪个就一定优于个知。

是大家的平衡点选的不太一样，再一个就是数据库，其他的一些模块，现在跟VM交叉的研究还不是很多，而且整体的系统的研究还不是很多，所以这方面还是挺需要我们在未来几年尽快的去能做出来比较好的工作。也是有很大的机会。好，那我今天的这个分享就到这结束，呃，然后下面我们第二部分请朱月岸老师来分享h tap系统的问题与主义之争。

好，我来退出一下。好，朱老师，请请共享一下屏幕。大师看到吗？啊，可以看到，呃，现在还是还是那个桌面，就是您PPT还没出来。好像是桌面嘛。哦。老师可以看到吗？啊，好像可以，您您往下播放一下，我看一下，我来共享一下，先新的共享一下。嗯。就是可以了吗？嗯，好像还不行吗。对。我看一下啊，你再重新共享一次试试。

但是可以看到吗？对，可以看到就是那个整个活动的那个蓝色的那个背景啊，这样可以了吧，啊可以了可以了，OK了OK，你们开始吧，谢谢啊，欢迎大家来到腾讯T口呃滴系列，那我今天给大家带来的这个分享是这个S系统的问题与主力之争，那么这个问题与主力之争其实是呃呃上世纪初关于。嗯。中国。的一个方法。

的问题，就是以改革的方式，以比较激进的方式去解决，那就他认为啊，只有解决了这个方式以后，那其他的方式才能解决，那么就代表着两两个不同的路线，那其实呃围绕着h tap系统也是有这两条路线，一个是改改良的，一个是呃通过改革的方式去做一个全新的系统来去适应h tap，那我们今天这个分享主要是围绕这个主题来去来去那个呃来去阐述的。那今天呃分成四个部分呢，这个分享就是第一部分，我们先来看一下什么是s tap s tap的这个产生的定义，产生的背景和需求是什么，以及那这个实现step这个系统面临着什么样一个挑战呢？

那第二个是这个，呃列举，我们会列举主流的这个at一个实现，那主要是主流的一些厂商，比如all，呃，这个serve啊，或者hana之类的一些at type的一些实现，那我们会把这个相关的细节，相关的一些有比较有鲜明的技术特点的这个技术摘出来看一下。那第三部分是我个人的一个见解啊，就是说云延伸数据库，云延伸架构，那对于CS那有什么样的启发，有什么样一个帮助呢？哎，这这个是第三部分，来去跟大家一起去去探索一下，讨论一下，那第四部分是总结，同时换了一下在3106，我也预定了3106的会议室，可以跟他们说一。那首先我们来看一下呢，什么样是一个H的一个定义啊挑战呢。啊啊，这是一个经典的这个数据处理框架，那我们这个现实的业务系统也好了，科学研究也也罢，就是我们会把系统分成一个事物型的数据库啊，分成一个事物型的这个这个。

分成一个事物型的系统，然后然后分事务型的系统，呃，这是数据的源头产生的地方，那么另外一个呢，是这个分析型的系统，那么这个是我们所谓的这个数仓，那数据呢啊，就是定期的从这个呃，TP型交易型数据库，那么通过ETL的方式啊，ETL的方式，那么导入到这个数仓，导入到数仓，然后在数仓里面去做分析，去做处理，那么产生呃相应的这个报表，呃呃这个呃一些一些报告。那么呃，企业的经营决策者呢，能够从通过这些呃这个分析报告和决策呃这些报表去看，去观察这个企业的这个经营行为，以及观察到这个发展趋势和一些总体的一个细节，那么数据库，那么这个数据的这个呃呃数据的这个价值是很重要的，那么也有一些这个研究机构表明，就是说它这个右上右上角这个图，就是说每一个公司，大概一个公司里面，它每13美金的这个投入，就有一美金投入到这个数据分析上面去，那么74%的公司呢，他想成为一个数据驱的驱动型的公司。

如果一个公司呃，采用了更为先进的这个数据分析处理技术以后呢，那么那么它有就具备这个两倍的可能性去超越他的竞争对手。那么数据的分析价值是巨大的。但是写。但是现在这个数据分析处。这样把这个TP和AP割裂开来呢，然后通过ETL去做这个数据的这个，把这个数据从这个呃交入型数据库导入到这个呃，导入到这个分支型数据库，那么这个TP，那么这个ETL带来的这个呃时延是相当大的，那么它可以从这个数十分钟到几小时，甚至这几天，那这个图大概给出了这个。数据的这个商业价值，随着时间的流逝，呃呃这个呃呃降低的这么一个趋势，那么数据产生，然后再经过ETL导入到这个数仓，然后在数仓里面执行分析，然后做决策，然后执行相应的分析，那么这时候呢，数据的这个商业价值就会一个大打折扣。

那么这种情况下，那么最理想的情。情况就是能够在这个数据源头去做分析，那么数据产生以后，我就能迅速的对这个数据。做分析，那么是最理想的情况。当然这也是H的一个初衷。那就为了这个解决这个问题。来提出来的，那他他就是，呃，总体来看这个最初最初的初心呢，他就说我要去打破。这个。事故处理啊，分析处理这个，呃，这个界限，那么使得这个应用应用程序啊，或者这个某个行业的这个呃，企业啊，那能够通过这个更好的这个情景发现和改进的这个市场反应程度，去获得更好的一个创新。

那么现在这个说现在这个已有的这个呃厂商啊，就是说呃，像hana or和那个IBM也在这方面去做了很多的努力，然后产生了很优秀的一些系统。呃，这时候我们其实这个大家可以看一下，其实对于这么先进的这个分析处理技术，其实应该从一开始它就应该是存在的。那为什么到现在这个到现在。他才登上历史舞台呢，为什么到最近一些年，他才频频的拿出来被人们说，说这个技术实在很好，或者是我们要我们，或者我们需要现在这样的产品。那其实呃我个人呃的观点，和和和那个就是我个人的这个看法，就是说总体来看还是说得益于现代这个列存储技术的发展，那才能使得h tap成为一个可能。为什么这么说呢？我们举个简单例子，那以前这个s server去做这个查询处理，那么他经常一个跑一个分析处理啊，那有十多个小时以上，那就是我们经常呃所说的这个叫做晚上做分析，隔一天看报表，那么在这种呃技术氛围和技术技术能力之下，那是没有办法去呃做h tap的，那后来这个s server去呃去采用了这个列存储技术。

以后呢，他从十几小时的这个分析，那么可以降到几分钟，它甚着这是秒秒级的这个这个呃就可以把这个结果返回回来了，OK，那正就是说正就是因为呃链存储技术，以及其背后的这个呃查询向那个呃向量查询之间引擎的这个发展，那才使得S啊登上了历史的舞台。那么其实s tap这个实现的难处在哪里呢？嗯，S tap这么好，能够给这个能够在这个数据产生以后，那么我们就可以做进做做实时分析，那么其实type最大的一个问题就是说把这个TP和AP2类工作负载放到一起的时候啊，它经常就是说这两类工作负载其实是是互斥的。

为什么这么说呢？那这个像呃，TB型的这个交易型的这个事物，它通常是个短事物，以写为主，那么这个分类型的这个事物呢，经常是长事物。你读为主，他需要经常的需要去做全表扫描，然后在这扫描的基础上去做，呃这个呃，统计去做汇总去做这个呃聚集聚集操作，汇总操作啊，那么这种情况下呢，这个。A pap的事物啊，经常会把这个系统啊，这个带宽，这个资源给打满，那么会使得这个呃，这个交易型的事物啊，这个吞吐量下降下降的相当厉害，那有人做过一个分析，就是说把这个TP和AP。放到一个系统里面去调度，那么它这个TP的这个吞吐量有可能是下降这个三到五倍。那么呃，怎么样使得TP和AP在系统里面互相互不干扰，或者干扰最小的这个去去运行，那么这是s tabs这个系统设计的一个难题，也一直围绕着这个主题，呃进行这个系统的设计，系统的优化。

那么总体来看，那么就摆在两总体来看这个，呃，从这个十多年的这个发展来看，那么摆在面前的就两种方案，一种是啊，我们所谓的这个走，就是刚才的那个问题，就是改良的方式。在现有的系统上去延，去延伸，在现有的业务系统上去延伸，去扩展，然后去满足这个所谓的这个呃，业务的需要，做一个类似这么一个系统，那么这是一个所谓的问题导向。那么另外一个就是说，我们从头开始设计一个系统，一个具有这个颠覆性的彻底的这个系统，那么这个，当然这种方式会产生更多有价值的技术，就是从这里这个通过这个。

这个途径来产生的，但是它也有可能呃去呃涉及到比较多的这个业务改造，数据搬迁之类的，那么可能从现在来看。呃呃，很难说哪一种比较更好，那我们呃，这个分享也也不去做回答哪一哪一条线更好，那我们会在这两条线下，我们会挑选几个典型的业务系统，那么具有鲜明技术特色的系统拿出来给大家分享一下，那么同时我们也会在这个最后给出最近十年来h type系统这个技术的演变过程，眼见趋势，那么呃，希望这个大家能够从这里获取一点，能够洞察到一点这个。技术发展的趋势。那么我们呃，第二节来看一下这个H系统的这个架构的一个实践。那么呃，总体来看，这个刚才所说的这个s step系统分成两类，一类是这个我们的这个所谓的这个改革的一个所谓的改良的，那总体来看就对应就是说呃，One second all的策略，就是我用一个大全的系统。

同时去满足t pap的这个需求。那么。另外一种就是说我用one side't就说我把这个，也就是通常所说的这个松of和lose couple的这个方式啊，TPAP2种系统把它融合起来，通过这种CPC的方式啊，把这个数据，把这个TP上产生的数据定量的导入到这个A那个数仓，然后去做分析。那么这两个大类下面有两个词的一个是。单系统单拷贝就类似这个就是它在一个系统里面用一个数据格式来去满足两种业务需求，那么通常而言是采用P存储。就是这个，呃，把这个数据。

从整体上看它是行存的，但是把它打包到一个页面的时候呢，在某个页面它是列存储的，就是叫做P存储，那么呃，近近些年来也有趋势是往这个单纯以列存储来满足这个TPAP的需求，就是。另外一个是单系统双拷贝。就是我一个系统里面同时存在行存储和列存储，那么这个行存储呢，就是我行存储上的更新呢，会定期的导入到这个列存储里面来，那么然后在列存储上去做分析啊，行存储上去做更新。那么使得他们这个竞争呢？呃呃，在某种程度上可以降低或减少，另外就是lose cup的方式就是one on，那one on就是一个是。T型的数据库，一个是AB型数据库，那这两个数据库呢，把这个数据的更新呢，在TB型型的数据库上进行，那么定期的把这个德尔塔更新导入到这个AB型数据库，然后把它转换成列存储。

那么右上角这个图就给出了这四种类型的这个系统实现s tab这个这个类别的这这个特征，我们从两个维度来刻画，一个是数据的一个新鲜度。另外一个是那个干扰程度，那个这个t pap的这个干扰程度，那么其可以看到那个呃，Once I all的这种策略呢，这个因为把这个TPAPA2种工作，两种工作复杂的这个都放到一个系统上调度，那么t pap当然是干扰的是最强烈的，那次之呢，就是。就是那个呃呃单系统双拷贝的方式，那这两种方式，这个缺点就是说他们这个呃t pap的这个影响干扰会比较大，但是的优点就是它数据可见度高，因为它不需要做这个数据的这个同步导入导出和CDC的这个一个一个呃同步。那那once那个松耦合的模型呢，就是呃有两个模型，一个是共享存储的上的这个松耦合型，呃这个类型的存储目前上看，目前的这个调研来看，目前的这个，呃，各大厂商啊，呃这个学术研究啊，其实呃从这个paper的发表来看，还没有发现这种所谓的这个商业化的产品，那么总总体来看，这个IBM出了一个DEMO。

呃，这两个系统。这两个类型的系统，那么它可以把干扰降低到最小，就是TP和AP2种干扰，因为它是得在两个不同的这个这个这个独立的系统上进行的啊，那所以他刚才会最讲，但是它这个数据要同步TP那个交互型数据库上的更新的数据，要通过这个CDC的方式，通过呃呃同步到背机或同步到其他的这个所谓的扔的节点上，呃，那么这可能这个数据的延迟就比较大，那么呃这这里给也给出了这个几个典型的ste这个呃呃这个工作负载对于这个实验的需求，像欺诈检测啊啊这个系统这个监控啊，那么它的延迟大概是20毫秒，那么在线游戏啊，个性化这个呃，个性化的这个广告推荐啊，然后一些呃，商品那个股票价格的监控啊，那么它可能会到100~200之间。

那么总体来看那个，呃，我们就会从这这四个。从从这呃四大小类的这个呃呃系统事件当中挑选几个代表性的系统，然后去看一下这个s tap是呃各大这个s tap的这个大的这个技术是怎么实现的。那么我们首先来看一下hyper。拍这个系统其实是一个呃很典型的系统，也很具有代表性的系统，它其实也是具有一个比较呃传奇色材的，那怎么样一个传奇色彩呢？他其实是一个呃一个一开始是一个academic，就是学术化的这个产品，但后来呢，这个这个托斯这个叫托斯教授就说呃他把这个系统。

做好了做的这个，然后卖给了templo，就说美国一个这个BI的这个公司，然后就说他从从做一个学术型的这个这个产品，然后变成一个呃商业化的这个呃呃产品，那么相当具有这个呃技术的代表性，那么它的查询执行模式也是很有那个技巧的，那么TP呢，是创新的去执行。TP创新的执行。不需要加锁，因为因为它这个取决于就是说呃呃原来这个O尔TP的数据库啊，把大部分时间消耗在加锁缓冲去管理日志管理上，那么大家并发去执行，那么需要复彻，那么它就消耗了系统80%左右的这个资源，他说我不需要加锁了，我只需要让让这个呃呃事物去创新的执行，那么一个事物创新执行也就一微秒左右时间是这就也就微秒级别左右，那呃这个。开销是可以接受的，那么跟它相类似的系统叫h store。

H store也是这么来做的，就是我我我不需要这个我我我我不需要这个加锁，我直接这个让这个创新执行就行了，那么这个AP的这个执行呢，通过通过FO1个子进程来询进执行这个a pap的这个查询，在这个事物一致性的拷贝上去运行这个AP查询，那么呃，更新的时候呢，再把这个相关的配置页拷贝出来。去在让AP去更新，让另外一个这个呃，这个不同的这个呃呃。不同的这个配置页上去进行，那么OATP呢，通过无无锁的方式去进行执行，TP呢，它通过把数据化成多个数据块，那个多个数据块呢，这个呃，不同的这个TP达到这个并行执行的效果，此外它这个通过呃。啊，通过区分冷热数据的方式啊，把数据分成热数据和冷数据啊，还有一个所谓的这个温数据。这是通过这个硬件的方式，这个MMU的内存管理单元，拿去区分这个数据的这个访问的热度。

那么这个日页面呢，是放在这个正常页面。小页面上，那这个冷数据呢。是压缩存储。放在这个大页面上，这个4KB的大四四兆的大页面上，那么它这种好处，它这种做法的好处就是我我去做这个，我去做这个更新copy online的时候，我这个代价是比较小的，但是我这个做，嗯A这个查询的时候，那在这个大页面上压缩的大面上，那我这个性能是能够达到比较好的效果，大页面就TLB也就是比较好的一个一个一个一个行为的，此外这个hi的这个。呃，查询资金引擎。也是相当相当优秀的，他利用这个向量化的查询引擎，利用这个LLVM生成这个。可执行的这个机器嘛。那他这个技术，呃，说起来就很有呃代表性的，为什么这么说呢？那后面大明领的Spark。

都是参考它这个代码生成技术，那后面的这个我们呃耳熟能详的这个click house啊，PG它的代码生成技术都是从hyper这边呃呃借鉴过去的，那么所以说hyper这个paperper hyper这个系统啊，相当具有这个代表性。那么啊哈na呢，也是这个A哈呢，它也是一个定位在这个呃单系统单拷贝这个这个呃这个界线上，它它的目的是呃不是一个数据库了，它是很像一个平台呃数据库管理平台，那么它支持多引擎多类，工作复杂，呃哈拿这个呃这个系统的这个分层结构做的相当好，像字顶向下，它分成总体来看它分成一个编译层和执行层，那么上下呢就又可以分成这个查询的这个解析。生成LT去，然后再映射到这个呃这个计算图模型，计算图模型呢，然后呃又做一个呃这个物理优化，物理优化呢在这个，然后呃分布式这个执行框架去构建这个实际的数据流，将这个呃呃物理执行算子分发到特定的引擎去，因为这个哈纳是支持这种呃多引擎多类工作复杂，像比如它这个关系数据库引擎。

然后这个数仓的这个查询这些引擎，然后这个像图啊，然后文本啊图啊，那么它向上提供了，呃，针对这些特定引擎的物理算子，就比如啊啊。关系，关系操作的算子，然后图图计算的算子。那么这个图直径引擎下面又有个统一的这个表模型。那统一的表模型，它向上提供一个统一的接口，那呃，很类似那个MYS的这个handle的接口，那只要下面这个存储引擎实现了这下面的这个这个handle的接口，那么它就可以对接到这个系统里面去，此外它这个也它这个理念也分成这个三级存储，一个就是L1德塔，那它对应的是叫做hot，叫做这个日数据，那么再往过来这个是这个是无压缩的行存储，那么对应这个L2德塔，它是一个呃，轻量级压缩的列存储，比如字典压缩，那么在。

往这个main store这个主存储上呢，它是一个呃呃，一个主要主要的一个存储区，那么数据呢，通过定量的这个合并到这个main store里面去。啊，这也是这个，这个是独友好，这个是写友好的啊，那这两个是独友好的，那么通过这种方式来去满足所谓的这个h ta的一个需求，但是他会定期的去执行这个默制操作，把这个数据定期的呃默制到这个name store里面来，呃，那这个是默者的一个具体的这个流程，一开始呢，在呃在在这在这个内衣和德塔一上去执行。那在合并操作的过程中呢，它会它会生成这个Mayo。和德塔。那么这个读操作呢，就在这个内一呃一得尔塔一和呃德尔塔二项进行，那那那那这个拷贝完以后呢，数据的这个内一和和德尔塔一，它最终会合并到MAY2里面去，那么那么到最后就是把它这个切换过来，在MAY2上这个读读操作，然后这个写操作，那数据的这个枷锁的行为啊。

只是发生在这个呃，这个缓冲区切换阶段，那么这个这个技术，呃，其实缓冲区切换这个技术，我们这个在国内也有相关的厂商友商呃也在用这个技术去做这个，以前做这个呃，Mexico in the DB lock store的这个优化也很类似，是这种呃buffer的这个切换的模式。那么L1呢，它L1德塔那采用这个呃Yin去保证这个持久性，那这个main store呢，它采用个影子页技术来去减少这个日志的写入。来保证一致性与持久性。机构server，它的这个，呃，它的这个定位，机构server的定位就是把这个列存储，它叫一个index，它叫column store index，其实它虽然叫index，但但是它是一个数据的物理拷贝，那么它这个怎么做法呢？他把这个数据按行切分每100万条数据。

做一个，然后去做切分，切分以后呢，再按每个列去做，去做转换，每个列去做这个生成一个列存储，每个列存储呢，也是做单独的压缩，比如有些适合用字典去，有些适适合用这个字数值压缩，就是每一个列采用不同的这个压缩算法，然后转换后的这个这个列存储在这个字典表。存储在这个block类型中，那么外面的这个directly去去追踪啊，Segment的这个存放位置。那这个server，呃也针对这些呃列存储提供了一个批量执行的算子，就加速这个呃分析操作，那以前这个我们这个这个分析执行操作是once couple的方式去做，那这个现在是once adapt，就是依次一个向量来去加速这个呃这个分析执行，减少这个函数的这个切换和调用。

而Oracle也是这种，呃Oracle是双拷贝了，单单就是说它每个系统里面去呃呃同时针对某些有需要的这个表，那它会同时存在一份呃行存储和存在一份列存储，那么在列存储上去做这个呃分析操作，那在这个数据更新呢，也是这个呃进入到这个TP里面，然后定期的这个导入到这个列存储里面来。这个呃，这个特性是可以灵活的指定的，也可以在系统的运行时刻去更改自己的特性。呃，此外这个Oracle也提供了这个RA的方式，针对这个特性去做横向扩展。呃，Or给出了两个例子，就是说它怎么样来利用这个列存储来提供它的这个，来来呃，加速它的这个分析操作，那我们也可以来看一下这个，它是怎么样利用这个列存储来提供这个，来加速这个分析操作，假如我们去呃呃查找这个这个outlet这个这个这个这个这个商品这个这个。

这个商店类型，这个outlet，这个商店类型的所有这个销售额，那么他会先去扫描这个所谓的这个我们的这个。呃，维表，维表以后呢，根据这个type等于outlet这个这个。这个商品的这个ID拿出来。满足这个outlet这个上面ID拿出来，拿出来以后呢，在里面去去去查找，查找这个，如果满足这个条件的，那么就可以去去做这个，把这个amount去加起来，就是说它通过这种只是扫描某些特定的列，生成相关的bitmap，那么它就可以把这个数据。要要要访问的数据，要涉及的数据，或者这个呃呃，甚至把有些要去做做的一些这个操作简化成简简单单简化成一个表扫描操作，就比如这可能要去做做的操作，那么它简单的扫描这个这个store这个维表，然后在这个大框表上去取，取到这个相应的两个列，那么他就可以把这个所需要的这个呃查找也找出来了，那么另外一个比较复杂例子也是他只要扫描这个。

两个这个维表，然后呢，再这生成两个vector，针对这两个vector，就这两个vector，两个vect那里里面再去。找相关的这个那个叫做外键，它就可以直接定位到，定位到这个，定位到这个呃，相关的这个next里面来，把这个如果它符合这个条件，让他把它呃写到相应的表格里，写到相应的这个呃生成的这个聚集表里面去，所以说他就可以把这个。表表聚集操作转换成扫描操作。而且只需要。只需要去查找，只需要去访问很少数的这个查询中涉及到的这个相关的列就可以了。

那这个呃这个呃松耦合的这个呃系统呢呃目前从目前的这个松耦合共享存储这个这个这个这个架构，从目前来看，这个还没有这个呃商业化的产品，但是IBM呃开发的一个原型叫wild wildfire wildfire呢，它发表在这个，它相关的技术细节发表在这个CID2017年西格莫的。2016年。那这两个，那这个呃，这个产品呢，根据IBM的这个这个说法，他后来演演变成他的even store这个产品架构，这个这个产品，那么我们这个总体来看呢，它的技术细节是像这个是总体技术细节。那他把这个系统分成这个两类，这个节点一类是这个叫做有状态的节点，一类是这个无状态的节点，那有状态的节点就处理这个事务型的请求。

但无状态的节点是处理这个AB型的请求。这个AP的请求呢，可以容忍一定的延迟，那么就我可以，呃，讲十秒钟再去倒过来。那么TP型的这个数据呢，啊不不会直接写到这个共享文件系统里面来，那么它会直接自己就组成一个集群，按照这个数那个表分片的模式在这里去去做这个快数据快速的写入，那么定期的呢，导要导入到这个共享文件系统里面来，然后然后这个呃共这个分析型查询去执行，那分析型查询呢。他自己去这个，呃，定制了一个这个引擎，定制的这个引擎去对接Spark的，那么这个引擎呢。呃，是无状态的，那它可以是呃。呃，自己去。定制修改的比较针对这个数据分析领域比较强悍的型，就比如这可以用click house来替代，或者是来替代都行的，所以说它这总体来看分成两个集群，这个集群一个是TP的，一个AP的，那么事物型的快速流入，那么从这个观点来看，那么可能。

大家觉得是不是比较眼熟呀？对，我们国内有些呃厂商也是，呃可能跟这个技术也是比较类似的，就是说他利用这个Spark的这个能力生态去做这个，呃这个分机型查询，比如利用Spark的这个查询优化器啊，它的机器学习能力去做，呃这个所谓的这个AP，这个AP的能力，那么其他的这个自己这个TP的能力呢，自己去构建，然后。然后这样子就把这个数据啊，这两套系统在某种程度上去做一定的融合，那么就做成了这个所谓的这个呃，H。那这个松耦合的这个呃，独立存储，那最近一些年这个倒是比较比较那个比较流行，那那这个总体来看这个呃是分成两类那个。

就是两个比较有典型代表的，我们会我会拿出来在这里去跟大家讲一讲，一个是谷歌的f lightning f lightning呢，其实它把这个系统呃分成三个模块，一个是呃，TPTP的数据库。一个是lightning。一个是查询这些引擎，那么这个呃，这个lightning呃，通过这个change pump change pump把这个数据呃，这个数据的更新，TP数据库的更新呃导入到这个，或者通通过订阅的方式，通过订阅这个pump把数据呃捕获到这个呃LA里面来，Laing在里面内部开开发了一个适配器，将这种这个CDC的模式转换成它的内部统一的格式。那么这个lightning有两级存储，一个是memory memory存储，一个是呃，这个呃，Disc存储，那memory存储里面的是行存储的模式存在的，以这个BB去的方式去做索引，那么它这个自售函是没有转换成列存储，它只有在数据写入的时候。

去写盘的时候，他才把这个行存储转换成列存储。那么底层的这个快里，那上层的F1里呃呃，通过这个呃呃快照隔离的机制去读取它这个呃，可见范围的这个呃呃相关的这个数据，那总体来看呢，这个这个呃。谷歌FLA的这个方式就很像这个，呃，这个CDC啊，很像一个database的方式，我们这个顶音的这个database，把这数据的同步啊，跟那个拉过来，拉过来到这个到呃AB群的数据库上去做分析，去做相关的这个报表。啊，这个这种方式，呃，大家的一个问题就是说总体来看还是查询延迟啊，是可能是一个呃需要去考虑的问题，那从谷歌的这个呃呃测试来看，它这个查询的延迟大概在八分钟到十分钟之间。

到八分钟到十分钟之间，这是因为它这种CC的方式，要把这个呃TP的数据库转换成呃CDC内部统一的格式，然后再批量的去提交，那么这种方式呃延迟是比较大的，那那IBM的这个IBM的这个方式就是说IBM就argue就是说呃。这个方式延迟太大了，他一开始IBM也是就是说他。类似这种开发了一个呃，松耦合的这个s tab，那左边这个是DB two，那右边的这个是这个呃，它的这个b Lu的，或者是个叫做这个data warehouse的这个DB DB house warehouse。挂，挂载到这个事物型引擎啊，然后这个事物型引擎的更新定期的同步到这里来，但是这个做CDC啊，这个方案需要大量的这个背景知识，大量花费大量的时间来维护这个额外的进程，而且延迟是比较大的，那它这个通过怎样的改进呢？他说是通过这个轻量级的集成同步方案来规避这个上述问题，将这个延迟减少了180倍左右。

那他这个具体的做法是怎么样呢？我们来看一下，就是。他说CDC的方案需要在原端经历这个六个步骤，一是把数据读出来，然后解密，然后过滤这个无关的日志，然后再按SMLSM排序，那这两个，这两个步骤大家都是需要的，但是但是但是CDC呢，它要对数据进行这个行列转换，然后把数据，把数据掌存起来，掌存起来，接着呢，呃，要把它转换成这个呃，CDC统一内部的格式，然后呃，批量的去等到事物结束符，比如commit或low，在然后呢，呃在在发送之前还要去做一个呃。把这个数据去做一个去除。那么这种情况呃，对于这个呃，原端的这个呃，压力或者是这个呃延迟是比较大的，那么。

Di Di DA呢，就说我不需要这个这几个步骤了，我把这几个步骤都挪掉，挪到这个目的端去执行，目的端呢，能够人声的识别。这个呃，从DB two里面过来的数据，当然这个是比较比较呃定制化的方案，它这个通用性就没有那么好，但是但是它这个延迟可以降低很降低这个。它是比较可观的，这个延迟的降低，他说这个能够降低180倍左右，那现在这个延迟大概只有三到一到两秒，三秒左右，好像就能把这个数据可以看到这个最新这个数据。那么总体来看那个我们呃呃呃，对这个s ta的这个发展的脉络，最近十年来这个发展的脉络，我们呃做了一个大概的一个整理。这个这个曲线表示它的这个前驱技术，或者是从这个产品演变过来的，那么从这个图上我们可以看到。

H ta技术在1516年之前，那主要是以one all为主，那么在1516年以后，那么以松耦合的，这个以松耦合的架构为主。那么看像这几年的这个，呃，这个f fe，拉尼啊，IBM啊，对，它都是采用这种松耦的方式来去做的，现在甚在哈娜他也类似这种，也有这个松或的技术方案去做这个S。那么从这个，从这个one all的这个这个演变的这个趋势来看，大多的从这个双耦合。双双拷贝转换成单拷贝，那么从行存储转换成单一的列存储来去应应对这个，呃，TP和AP的这个请求，那么从M啊，他从原先的这个，呃，这个。在磁盘上，而是用呃这个列存储的，放到内存里面是从行存储的。那他现在全部改改改成。

统一的改成列存储性格，是的，他现在产品改名叫做。新。对，这就是，呃呃。最近十是十年来这个H这个技术的一个演变的一个趋势。希望大家能够从这里能看出一点什么端倪来。当然各家的这个实现的方案和技术，技术能力供给不一样，那可能采用的技术方案也是不一样的。那我们啊，大概来看一看。这个云延伸架构对于S系统呃，有什么样实现，有什么样一个帮助呢？那总体来看这个，呃，云原生架构的这个，这个我们的这个。呃，存算分离架构能否为这个S这个设计带来这个。这个便利呢，是能否去解决这个呃扩缩容难的问题，能否去解决这个系统资源征用的问题呢，我们可以看到，在不论就这两个类别的这个系统上，在这个资资源竞争扩绰容和成本的数据可见度上，这个表现呢，呃都并不是说哪种产品的表现是呃呃。

最优的或者哪种表现在某某种都是在某个地方，某个全能数据延迟和资源的资用上，它做一个取舍。那么我们的这个存算分离架构和这个弹性算力能否去满缓解这个资源竞争呢？啊那我想呃各位从事这个云延生架构开发的那个呃工程师或这个专家对这一块肯定也是有自己的看法和见解，那么这个此外这个丰富的这个资源池和存储池，能否针对不同的这个计算，不同的这个业务特征去划分，去定制，来降低用户的成本呢？那这也是呃值得大家去思考的一个问题，那我这里就给出了大概的一个叫做呃呃这个一个愿景图吧，就是我们我们可以大概的理解就是说呃从总体来看，呃理想的一个情况就是说我们这个云原生架构里面，能够在这个CS利者呃呃跨processing做一个呃分层，然后上面做一个呃查询的一个呃多租户的一个设计，然后然后在这里去做这个查询的解析，呃查询的这个优化，然后把查询的执行呢，放到这个呃查询。

查询执行层啊执行，那么查询执行层呢，又分成这种所谓的这个有状态和无状态两类节点，分别处理TP和AP相关的请求，那么在这个呃共享存储层呢，我们可以针对这个CS多利者这个这个工作模式，工作负载，那么我们在这个AP这个存储领域，我AP这个纵上，我们可以主打这个性价比。利用这个所谓的对象存储啊，Ecq啊，这个编码模式去去降低这个成本，那么因为呃，从呃，Awsw shift的这个团队的这个调研，和和和这个呃。呃，观察来看，就说这个AP型的用户呢，更多的这个精力也可能是聚焦在这个成本上，所以我们这个CSCS类的这个AP的作用呢，能否去做一个呃性价比的一个取衡，而TP型的这个存储呢，呃，能否去做一个不同的，比如高性能的存储，在事物提交的关键路径上，我们去做一个呃更好，用户体验更优的这个，呃呃呃呃呃，这个定制相关的存储呢，就比如我们高性能MD1或者是这个非低3D叉破的一个一个高高性能这个性价比去提，去提升这个啊啊。

事物加快事物的提交速度，然后这个，然后定期的把数据从这个T型的数据导入到AB型的数据呢，那或许呃，在未来不久的这个，嗯。呃，场景或者这个未来不久的这个时间，我们能看到应该有相关的厂商或相关的这个，呃。呃，数据库开发这个社区，或者提出这么一个方案，或者这个技术技术技术那个特征。

呃呃，总体来看这个呃已有的问题就是说t pap这种呃复斥的这个属性，那怎么样去围绕这个t pap复制的属性，让它这个在一个系统，在一个大的模块里面去呃去满足这个呃呃h tab的需求呢？那总体来看现在这个呃存在这两种这个架构实践，一种是这个one off，我就用一个系统，一个数据库来去满足这个呃，TP也好，AP也好，然后C口no c口也好，就是满足这种呃，满足这种多样性的工作复杂的需求。那么就一个系统，然后去去做相关的这个，呃，架构革新，针对这个两种工作复杂的特性做更好的去优化，那另外一种就是松耦合的方式。他们两，他们两类系统，两类系统。

去通过这个呃，CDC把它联合起来，CDC联合起来，然后呃，然后在上面去架成一个架构，一个类似proxy的东西。给用户呈现出一个系统的表象，那用户呢，是感知不到这个呃呃这个AB型的这个系统的存在的啊，所以他通过这种方式啊，来去给用户呈现一个啊一个系统的表象，那么就是拿来用两个系统把它联合起来，对外加一个加一个proxy或者是加一个这个呃路由器，那么能够给用户呈现这么一个所谓的这个呃s tab的一个一个一个模式，那这种方案呢，能够更好的去降低啊这个。两类工作复杂对资源的竞争，那前面一种呢，虽然资源竞争比较大，但是这个。但是这个呃，它这个数据的延迟比较小，数据能见度高，新鲜度高，能够或许能够这个满足这个click的这个就是任务紧急型的一些task的这个需求。

那么我我们个人认为这个就是说这个潜在的机遇，就是说云延伸的这个弹性的算力啊，可能天生的就对于这个h tap这类系统具有比较好的一个适应性，那么以后我我我们认为在这个云原生上，它会诞生一个更优秀的，那更好的这个h ta的系统。OK，好，嗯，谢谢大家。呃，那今天的这个分享就到这里，那我们期待后续我们有更多的这个机会来交流去做这个啊，重见直播的系列的这个再次讲解啊。谢谢大家。