开发者学堂课程【高校精品课-西安交通大学-数据库理论与技术：阿里工程师讲座】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/12/detail/15865
阿里工程师讲座（三）
内容介绍：
一． 传统数据库架构和云的本质
二． 云原生数据库
三． 下一代云原生数据库
三．下一代云原生数据库
所以刚才介绍的云原生数据库架构其实主要是在共享存储这个架构，因为现在共享存储就是云原生数据库的主流架构，在共享存储上原来做的一些工作以及单独做了一些优化的工作，那下一代远程数据库应该是怎么样的，也有一些思考，以及已经做了一些前置的部署。
在这里可以看到数据库的核心还是要做更好的 US status，所以 US status 为什么很有价值，就是传统数据库架构,就是一个 resource 需求,要根据你的峰值需求来确定资源量，就像之前提到的买一个机器，哪怕峰值一下1000台机器，平时只要一台机器也得买1000台，并且不能减少。
那在云原生数据库这个阶段就是会有 scale 做的比较好的时候，就跟现有这个阶段就可以做分时段的弹性，就是在某个时间段需求比较大时可以去把资源 scaleup 起来。如果某个阶段需求比较小，那要付的钱其实只要付蓝色的积分部分，所以这个成本就会下降的比较多。
那中泰的云原生数据库应该怎么样，应该是不需要用户 care 这些，要买什么规格要买多少的机器，要买多少内存的数据库，这种都不用关心，就是用多少就给多少，最后按用的量来计费，那这才是理论上最完美的数据库了，所以现在的云原生数据库就是以这个目标来做一个演进了。
技术上怎么做呢？其学术界已经有很多的探索，应该去怎么做这个事情，这里有一些比较新的这几年的论文，一个就是说架构网络演进，整个架构应该演进，包括 SIGMOD 提出了关键数据库应该可以用远程内存 RDMA 来做加速，第三篇就开始提了，第三篇是普通大学一篇论文，它的内容是说可以用高效的内存的分离来实现数据库的这部分弹性。第四篇是比较有名的是 OSDI18年的 best paper，它就是用内存存储整体的分离做了一个操作系统。最后一篇是在这个操作系统上运行数据库，来检验这个架构的可行性。整个学术界基本上也是在存储分离的基础上做内存分离这个架构来做下一代云原生数据库的探索。
就是说传统的没有任何共享数据库，它弹性可能是小时级的，那么在存储计算分离以后它的弹性是分钟级，那到内存分离以后因为整个大部分的非意识状态，意识状态之下都是共享的。弹性时只要分配一个更大的 cpu 就行，那cpu本身是无状态的，所以可以把整个弹性做到秒级，那这样就可以实现了。再按用户的需求来做弹性就可以了。
那么在一八年就开始立项做下一代云原生数据库，因为那时候 PolarDB 就是共享存储的原生数据库，基本上已经成熟了，分了一部分力量来做这个事情，就是在做这个共享内存的数据库。共享数据库最大的特点，就这个共享内存架构，共享内存架构最大的优势就是它的 cpu 跟内存就可以不再对等，因为经常出现的情况是一个数据库节点cpu平时其实运行量是非常低的，但是因为内存缓存了大量的数据，内存使用量又特别高，那这部分不闲置下来的cpu其实是不能被使用起来的，因为内存跟存储一定要在一台机器上。
现在构建了一个分布式的内存池以后这些问题就不存在了，因为闲下来的这些 cpu 完全可以共享给别人来用。那这样自己的成本就会有大量的下降，那另外一个就是多个cpu可以共享一份内存。那么成本就会分担比较厉害，比如本来扩展15个只读节点，那每个只读节点都要有一份独立的内存，那这个内存里面缓存的数据其实都是差不多的。现在它们可以共享一份数据一份内存，这份内存里面缓存的数据就可以缓存的更多了。
第二个就是内存弹性，内存可以不再有什么限制，因为它是个跨节点的分布式的内存池，那这对于一些分析型块的性能其实是非常重要的。第三个就是通过共享内存就可以实现这个秒级弹性。因为 cpu 节点上的数据都可以刷到内存上来，那么弹性就只要去重新分配这个 cpu 就可以。这份结果在工业界或者学术界都是比较新的工作，所以把这份结果放到了6月份开的 SIGMOD 21，SIG MOD 21是一个鼎会，是现在相对来说是数据库业界最好的一个会议。
以下这是一个指标，刚才介绍了共享存储架构挑战，那共享内存架构的挑战就更大了。比如原来的 cpu 跟内存的通信都是通过 QPI 总线，基本都是百纳秒这个级别，那现在即使通过 RDMA 来做，那也是几个 u 秒这个级别，这个通信成本需要通过大量的架构的优化以及实现的优化来减少这部分额外通信对性能带来的影响。现在看到的就是在local有一个非常小的缓存的情况下，肯定需要的就跟L2缓存一样，但是缓存量非常小，可能只要原来的百分之十百分之五，这个力度，性能还可以达到原来的90%左右的水平。
sysbench 就是工业上用的比较多的一个测试机，包括 TPCC 也测了。整个进程损失大概只有10%几，这样基本上是处于的可用的形态。前面一些学术界的论文也提到，它基本上要损失一个数量级。只能到百分之五十或者百分之三四十这个成本内那个挑战，所以这块还是重要的。包括这里就是不单是说做了这个架构实践优化，也更深度的去结合这些软硬件相关的工作来实现性能的提升。所以第三部分的下一代数据库架构基本就分享到这。
最后也是呼应一下前面提到的就是以前学术界跟工业界还是有比较大的 GAP，就是学术界在研究自己方向，工业界也在研究自己方向，互相交流比较少。但是现在这几年这个情况有很大的改善，包括工业界也会跟学校合作做一些研究，来做一些宣讲，来讲一些现在在做的事情，老师也会把自己的一些研究成果，看看能不能放到一个现实的系统中，这样互相的交流会特别多，这个是比较重要的一个事情。
今天就分享到这里，欢迎以后毕业了加入。
问：serverless 怎么理解？
答：因为 serverles s 这个词用的比较多，它其实也是类比于传统的架构，就是传统架构时去买一个 server，那云传统时说的 server，就是买一台物理机，后来云时代出现以后，Server 基本上是买一个虚机，那么现在 serverless越多，就是说虚机的概念也不需要虚机，也算是 infrastructure，那 serverless 以后，比如 functio 方这种功能都认为是一个比较 serverless 的一个形态，不需要去 care 这个程序到底是运行在哪台机器上，因为有机器就有这个框框，有这个框框再去设计就很难去做就更高层面的弹性或者相关工作，那就是它只是给一个执行的容器，不需要去care真的执行，在每台机器上需要时，把这个函数孵化出来来调用逻辑，调用完就释放掉。
那对于数据库来说 serverless 也是这个含义，这里提了就是在共享存储上也在做 serverless，这个 serverless意思就是这个机器也不局限于给多少个盒，比如8个和32个G 的内存，而是根据需求，流量高了给一个更高的规格更大的资源，流量少了再给输回来。其实认为是个 ondemand 过程，那就是不再需要 server 的概念，跨越这个server，就是一个分布式。所以数据库的 serverless 就是按需的去给一个资源，现在基本上业界在提 serverless 的时候都是可以做自适应的弹性。
后面提的 PolarDB serverless 目的也还是一样，还是按需的给一个资源的供给,但是它的实现就不一样，它不再是去自动的做升降配，而是它水平方向直接把资源全部给裁剪开来了，完全是在一个大的资源池里面做弹性，而不是规格的一个柔性的升降配。但它的目标是一样的。
问：云数据库跟阿里数据中台是什么关系？
答：数据中台，以个人的理解，它这个大层的服务，它是个 service，它会提供更上层的一些功能。云数据库其实是个Pass，那它只是提供一个数据库的能力。在数据库上面再做一些数据的集成数据的筛减，数据化的一些服务，架在这个云数据库上那才是提供一个数据中台的能力。所以基本认为这中间还有一层。
